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-3200 the latter role has R/W permissions on website, otherwise s/he can't publish
• 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.