FOSUserBundle Override Roles – свойства «роли» в «Acme \ DemoBundle \ Entity \ User» уже были объявлены, но должны быть объявлены только один раз

У меня была такая же проблема, что и Аннотации.

Примечание. Поскольку у некоторых читателей были проблемы, связанные со мной, я создал репозиторий gitHub с моим UserBundle . Если вы обнаружите, что в этом HowTo чего-то не хватает, дайте мне знать, поэтому я добавляю его.

Это сообщение охватывает три аспекта: роль базы данных на основе базы данных с реализацией структуры дерева, конфигурацию структуры, также поддерживающую RoleHierarchy (getReachableRoles) для ролей БД. Без чего было бы бесполезно иметь роли в БД в конце концов. А Подписчики Doctrine для создания Ролей на определенной Сущности сохраняются.

Изменения, которые должен был сделать FOS, были глубокими и хорошо документированы, но я должен сказать, что один пример кода примера HowTo Use не позволил бы мне много читать (не жалуясь, по крайней мере, я немного знаю о передачах компилятора).

Роли в DB

Я использую Sf 2.4, но это должно работать с 2.3. Вот файлы, связанные с моим решением, рассмотрите один шаг на файл:

 ./: composer.json src/Application/UsuarioBundle/: ApplicationUsuarioBundle.php src/Application/UsuarioBundle/Resources/config/doctrine/model/: User.orm.xml src/Application/UsuarioBundle/Entity/: Role.php Usuario.php 

В copmoser.json я обновил доктрину-пакет, поэтому он включает в себя необходимые файлы:

 "require": { ... "doctrine/doctrine-bundle": "~1.3@dev", ... } 

В файле Bundle.php вы должны зарегистрировать пропуск компилятора

 namespace Application\UsuarioBundle; use Symfony\Component\DependencyInjection\ContainerBuilder; use Symfony\Component\HttpKernel\Bundle\Bundle; use Doctrine\Bundle\DoctrineBundle\DependencyInjection\Compiler\DoctrineOrmMappingsPass; class ApplicationUsuarioBundle extends Bundle { public function build(ContainerBuilder $container) { parent::build($container); $mappings = array( realpath(__DIR__ . '/Resources/config/doctrine/model') => 'FOS\UserBundle\Model', realpath(__DIR__ . '/Resources/config/doctrine/model') => 'FOS\UserBundle\Entity', ); $container->addCompilerPass( DoctrineOrmMappingsPass::createXmlMappingDriver( $mappings, array('fos_user.model_manager_name'), false ) ); } 

Это зависимость, импортируемая новой версией набора doctrine:

 `\Doctrine\Bundle\DoctrineBundle\DependencyInjection\Compiler\DoctrineOrmMappingsPass`. 

Я предполагаю, что эта информация о сопоставлении добавляется позже, чем FOSUSerBundle, потому что я просто повторил этот процесс (упрощенный для ORM), который я видел в FOSUerBundle.php, надеясь, что это будет иметь приоритет, и это произошло.

Отображения в User.orm.xml – это точная копия ./vendor/friendsofsymfony/user-bundle/FOS/UserBundle/Resources/config/doctrine/model/User.orm.xml с номером 35, закомментированным. Это удаляет конфликтующее сопоставление ролей в отображаемом суперклассе.

 <!--<field name="roles" column="roles" type="array" />--> 

Отныне вы просто делаете то, что хотите сделать на 1-м месте, реализуете свою идею о Ролях. Вот мой: Пользовательский класс, который расширяет FOS \ UserBundle \ Model \ User, но теперь с сопоставлениями, которые вы использовали в своем комплекте.

SRC / Application / UsuarioBundle / Entity / Role.php

И класс ролей:

SRC / Application / UsuarioBundle / Entity / Usuario.php

После этого вы можете видеть, что правильные изменения SQL сбрасываются обновлением схемы –dump-sql.

 $ php app/console doctrine:schema:update --dump-sql --complete CREATE TABLE fos_usuario_role (usuario_id INT NOT NULL, role_id INT NOT NULL, INDEX IDX_6DEF6B87DB38439E (usuario_id), INDEX IDX_6DEF6B87D60322AC (role_id), PRIMARY KEY(usuario_id, role_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE fos_role (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(30) NOT NULL, role VARCHAR(20) NOT NULL, UNIQUE INDEX UNIQ_4F80385A57698A6A (role), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; ALTER TABLE fos_usuario_role ADD CONSTRAINT FK_6DEF6B87DB38439E FOREIGN KEY (usuario_id) REFERENCES fos_user (id) ON DELETE CASCADE; ALTER TABLE fos_usuario_role ADD CONSTRAINT FK_6DEF6B87D60322AC FOREIGN KEY (role_id) REFERENCES fos_role (id) ON DELETE CASCADE; ALTER TABLE fos_user DROP roles; 

Тем не менее, я не представляю иерархии роли, которые мне нужны.

Надеюсь, это полезно для кого-то. Я уверен, что вы уже решили это или потеряли работу: p.

Документация I последовала:

 https://github.com/symfony/symfony/pull/7599 https://github.com/FriendsOfSymfony/FOSUserBundle/pull/1081 http://symfony.com/doc/2.4/cookbook/doctrine/mapping_model_classes.html http://symfony.com/doc/current/cookbook/service_container/compiler_passes.html 

Реализация RoleHierarchy

Файлы, участвующие в решении:

 // The Magician, for I just re-instantiated RoleHierarchyVoter & ExpressionVoter // classes as ApplicationUsuarioBundle services; passing my RoleHierarchy // implementation. src/Application/UsuarioBundle/Role/RoleHierarchy.php // duplicating security.access.expression_voter && // application_usuario.access.role_hierarchy_voter BUT WITH NEW // RoleHierarchy ARGUMENT src/Application/UsuarioBundle/Resources/config/services.xml // Entities, important methods are collection related src/Application/UsuarioBundle/Entity/Role.php src/Application/UsuarioBundle/Entity/Usuario.php // Edited, commented out regular hardcoded roleHierarchy app/config/security.yml // CRUD related, sample files will add dependencies to lexik/form-filter-bundle; // docdigital/filter-type-guesser; white-october/pagerfanta-bundle src/Application/UsuarioBundle/Controller/RoleController.php src/Application/UsuarioBundle/Form/RoleType.php src/Application/UsuarioBundle/Resources/views/Role/edit.html.twig src/Application/UsuarioBundle/Resources/views/Role/index.html.twig src/Application/UsuarioBundle/Resources/views/Role/new.html.twig src/Application/UsuarioBundle/Resources/views/Role/show.html.twig 

вы можете видеть файлы в этом

Или напрямую обращайтесь к каждому файлу (поскольку Gist не сохраняет заказ листинга).

SRC / Application / UsuarioBundle / Роль / RoleHierarchy.php

SRC / Application / UsuarioBundle / Ресурсы / конфигурации / services.xml

SRC / Application / UsuarioBundle / Entity / Role.php

SRC / Application / UsuarioBundle / Entity / Usuario.php

приложение / Config / security.yml

SRC / Application / UsuarioBundle / Controller / RoleController.php

SRC / Application / UsuarioBundle / Форма / RoleType.php

SRC / Application / UsuarioBundle / Ресурсы / мнение / Роль / edit.html.twig

Документация:

поваренная книга: избиратели безопасности

Компоненты: безопасность

ссылка: приоритеты тегов служб

Souce: RoleHierarchyInterface

Подписчики Doctrine

Вы доберетесь до этого, чтобы понять, что чего-то не хватает …

Основная причина, по которой я портировал Роли в БД, – это то, что я имею дело с динамическим (с точки зрения структуры) Приложением, которое позволяет пользователю настраивать рабочий процесс. Когда я добавляю новую область с новым Процессом с новым действием (или обновляю либо имя, либо родительский-дочерний элемент, либо удаляем любые), мне нужны новые Роли, которые будут сгенерированы automatically .

Затем вы думаете о подписчиках Doctrine для LyfeCycleEvents, но добавление новых сущностей в PrePersist / PreUpdate потребует вложенного флеша, что в моем случае бесполезно, это просто, когда вам просто нужно обновить некоторые поля на уже вычисленных объектах «computedChanges».

Так что я использовал для перехвата и создания / редактирования / удаления ролей, это onFlush, после чего computChangeSet () отлично работает для добавления новых объектов.

Я приведу пример ProcessRolesSubscriber Gist .