Roles are defined in the database (table security_roles)
New roles have to be added to the database during deploy
Problem 1: not easy for deployments, sometimes deploy command are needed
Problem 2: dynamic roles are impossible, for example a manager role per website
We keep the roles in the database, but only the roles that have been assigned to a group or user (the roles that are in use)
When assigning roles to a user or group (currently only at /admin/group/1) the available roles will be read from the application, in two ways:
XML file per bundle (Resources/config/roles/roles.xml)
Eventlistener (can be used for dynamic roles), like the one for the MenuBundle
Storypoints: 1
For Integrated issues we still can't fill in storypoints. Can you fix this?
wat is het nut van "dynamic roles" en waarom wordt het database gedeelte er niet tussen uit gehaald ?
Two important use cases at this moment:
More flexibility in authorization is requested, so we want to add a number of roles in different bundles. For example: there is a bundle that allows to export content, which needs a role to be able to give access to certain groups. Because every Integrated installation has different bundles its hard to manage the roles in the database manually. --> role definition in XML solves this problem
Separate authorization per channel is requested. For the WebsiteBundle and PageBundle users want to authorize only for certain channels. Channel management / webmaster tasks for the different channels are often the responsibility of different persons and currently it is not possible to give access to (for example) page editing for 1 website only. The changes in this issue allow to add roles with an eventlister, to be able to automatically provide a role for each channel.
Besides that currently the ROLE_ADMIN needs to be added to the database manually when you want to start with an empty Integrated installation without datafixes. We solve this as well with this feature.
About the database: I think it is not bad when the roles that have been assigned in an installation are added to the database. This makes it possible to add instance-specific information to it later. It also makes it easier to clean old roles and preserves backwards compatibility. Although when there are weighty arguments to remove the database table with roles that's an option as well.
Linked the INTERGRMARK-58 issue.