-
Task
-
Resolution: Fixed
-
Critical
-
0.5
-
None
-
-
Empty show more show less
-
Empty show more show less
-
Yes
Basic proposal
--------------------
We need to create two user typologies: editor and publisher
- we create three totally independent roles for the single purpose of the travel-demo and thus also prefix them with "travel-demo-"
- travel-demo-editor, travel-demo-tour-editor (can only edit tours and tour categories) and travel-demo-publisher Note: to workaround
MGNLUI-3200the latter role has R/W permissions on website, otherwise s/he can't publish
- travel-demo-editor, travel-demo-tour-editor (can only edit tours and tour categories) and travel-demo-publisher Note: to workaround
- an additional travel-demo-base role is created which can read access tours, dam, categorisation workspaces (this is the role given to anonymous user too so that he can see tours)
- three groups will be created travel-demo-editors, travel-demo-tour-editors and travel-demo-publishers with the needed roles to carry out their work
- if workflow is installed travel-demo-publishers will be added to /modules/workflow-jbpm/tasks/publish/groups so to be able to see workflow tasks
So eventually, we'll end up with
eric (editor) = travel-demo-editors / password = eric
eric-de (German editor) = travel-demo-editors (like eric but with UI language settings in German) / password = eric-de
peter (publisher) = travel-demo-publishers / password = peter
tina (can only operate on tours app and categories) = travel-demo-tour-editors / password = tina
All roles, groups and users created by the travel-demo are bootstrapped as samples
Findings during implementation
------------------------------------------
Some apps grant themselves accessibility to certain actions and roles (e.g. demo-project- from STK or editor and publisher available only with workflow) . E.g. by issuing the following query on the latest 5.4-SNAPSHOT EE-bundle
select * from [nt:base] as t where contains(t., 'demo-project-%') or contains(t., 'editor') or contains(t.*, 'publisher')
one gets the following relevant results
/modules/pages/apps/pages/subApps/browser/actions/activate/availability/access/roles /modules/dam-app/apps/assets/permissions/roles /modules/categorization/apps/categories/permissions/roles /modules/tours/apps/tourCategories/permissions/roles
For the sake of clarity and consistency those should be removed and let projects define roles which can access needed apps and actions. By the same token, I'd add permissions to all app groups under /modules/ui-admincentral/config/appLauncherLayout/groups and grant them by default to superuser only. It will be a project concern to add its roles by giving permissions to the appropriate roles (and we could certainly provide generic Task s to make it easier). In our case, it will be magnolia-travel-demo to create roles and decide which apps they can access.
- is causing
-
MGNLDEMO-73 Move travel-related roles/groups to travel module
- Closed
-
MGNLDEMO-68 Share demo users between STK and travel demo
- Closed
- is related to
-
MGNLDEMO-361 Eric can edit & publish while Peter is powerless on apps without workflow
- Closed
- relates to
-
MAGNOLIA-5975 Versioning does not work if a workspace is not in the same repository as mgnlSystem and mgnlVersion
- Closed
-
MGNLDEMO-42 German translation for "template labels"
- Closed