The goal of this project is to make privilege parameters usable/changeable during runtime. Currently privilege parameters can only be used in Policy.yaml files, and by that changing them needs a deployment. What we want to have though, is assigning parameters to roles via the user interface. One use case would be to grant different tree areas in Neos to different users. This is nothing you want to have to deploy for in the long run.
The solution is to attach parameters to roles, which can be changed during runtime. These parameter values can then be consumed by the privilege targets defined in the Policy.yaml, by creating user specific privilege objects during runtime out of the combined information of parameter values coming from the user’s roles and the available privilege targets defined in the policy.
Flow
Add the concept of parameters to roles
Build up runtime privileges based on role parameters and privilege targets with placeholders
Neos
Add a UI to define values for role parameters while attaching them to users
We need a nice way to export / import those “runtime” configuration. Really helpful for debugging on local machine or testing policy on staging server.
Yes, current I would say these values are stored in some model in the database, that’s where the user-to-role association is already stored. As this information is usually somehow related to the nodes or other content in the system, I’d say it’s mainly about transferring the content. Maybe it should become part of the site import/export? or don’t we want to have editor/permission information in there? As a start you can simply dump the database tables for sure
We have currently multiple discussion to move more and more thing to the CR (like Resource, Asset MetaData, …). In this case I’m not sure if it make sense. If the Parameterized Role (did I say, it’s pretty hard to read/write for non english people) are part of Neos it’s fine. But if this feature is parts of Flow it will couple Flow with the CR …
Both are very valid points. I’d say we should keep it out of the CR scope, as it can be used with Flow only applications. … and well, any good naming proposals are very welcome
IMO The parameters have to go into the model to make sense, but I would suggest just to replace current Account::roles relation to carry (optional) parameters as suggested in https://jira.neos.io/browse/FLOW-386
