[magnolia-dev] [JIRA] (SUGGEST-65) Generally: Re-concept app (and Action) permissions settings -> with Yamls it doesn't work at all in System Administration scope.

[JIRA (on behalf of Christian Ringele)]

Title: Message Title

Christian Ringele updated an issue   Suggestion Box / SUGGEST-65 Generally: Re-concept app (and Action) permissions settings -> with Yamls it doesn't work at all in System Administration scope. Change By: Christian Ringele While creating a System Administration training we realized some problems with Magnolia in the scope if Administrating the System from within Magnolia. Meaning a Magnolia System Administrator does work like - Creating roles & groups & users - Anything  within  being  logged in Magnolia which is more then normal Author work/need more rights and knowledge. Problem generally: The app sets on its configuration itself the permissions who can open the app. I think this is the wrong place, and with Yaml it leads to a lot of problems. How it should be: As "Web Access; & "Content Security" is set on a role, it should also be defined on the role "Apps allowed to open". And not that the app defines which roles are allowed to open it. Problem with Yaml: Before the Yaml world, one could argue that a System Administrator was still able to do it, just in a not so nice way: Open "Configurations" app, and set the permission on the app config (and hopefully inform the dev team). *But* this doesn't work with Yaml based app configuration... So in the end only the light module developer can do it on the FS... Hotfixing its not an option, or the light module developer can not change the app via FS anymore at all. And when removing the hot fix the permissions would be gone... I think its very silly, and hard to justify, why a Sys Admin has to call a LM developer after creation a new role, just to manage the permissions on an app using this role.  And that in the end the permissions on who can open an app is in some file of a light module. Suggested Solution: Decouplde Decouple  all configurations from any permission setting. Define all  thiese permisions  these permissions  based on the role/within the role/within the security app. Always  form  from  roles -> target config and not the other way around. SO So  basically decouple all configs from the permissions on them, as its done with the content and its ACLs. Which would also solve the following problem: In Test Systems & QA Systems the roles are often different. So the same configs (after load of production  contnent  content  & configs) won't work out of the box in a Test Systems & QA Systems,  ass  and all  permissions have to be changes . !  Which can be really hard to achieve if you even think about Actions with Permissions or configurations based on Yaml. If its decoupled, one set of permissions/roles could be provided per system/instance, and it would just work OTB. This would be a bigger refining in the product. But currently the reality is that: - We never have set a proper focus on Sys Administrators and what they have to be able to achieve and how. - We have never thought about the problem of defining permissions in configurations in scope of yaml - We have never thought about the problem of defining permissions when interchanging the content between test and QA system which often have a different set of roles. Add Comment   This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) ---------------------------------------------------------------- For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <dev-list-unsubscr...@magnolia-cms.com> ----------------------------------------------------------------