Refined version

While trying to resolve the ticket for the original scope, it turned out, that users, groups and roles are not sufficient to provide acces to the "most prominent content app" (such as pages, assets, contacts, categorization) for paige (a content editor) and pablo (a content publisher). With the current state Magnolia ce and dx-core, there is also the need to decorate the apps on:

1. app/permissions
2. app/browser/actions/$action/availability/access/roles

The group of interest has decided, it must be possible to provide access to content apps by defining users, groups and roles only, and that we should not decorate the apps to provide access for the test personas.
Instead the "core" must make sure that this will be possible in the future. (Follow-up-tickets on this must be created.)

For the functional tests this means, atm, we cannot use paige (the editor) and pablo (the publisher), however, we still can use armin (a superuser enabled guy).

Refined scope

• Describe the personas on a functional level on WIKI

• For CE: Prepare the users armin , paige and pablo - even though paige and pablo cannot be used atm.
  Prepare them as YAML boostraps; plus add a mrkdown file which describes the bootstrappables in detail regarding ACLs.
  -
  (Note:  Since the magnolia-integration-tests-fixture-module is used in all test-webapps on both CE and dx-core, we can have only one set of these bootstraps. In conclusion, the ACLs on the roles must be sufficient for both CE and dx-core users.)

• Create ticket(s) to make sure ce and dx-core enable a user set-up for editors and publisher without the need to decorate app descriptors.

OLD version

Context

For many functional tests (to be implemented as UI tests), we need distinct users (avoiding to run all the tests with superuser or eric). The List of required functional tests already lists such users, however, the list must be refined and properly specified, and finally we need "bootstrappable" content providing these users (groups and roles).

It is worth to mention, that the Magnolia demo modules (travel-demo, etc.) bootstraps a bunch of users, roles and groups (= security items). Since the security items provided by the travel-demo are a bit messy, functional tests should not rely on them.

Scope

Describe and define the users (and groups and roles) - the security items - and produce bootstraps for the following personas

Acceptance criteria

• Describe the personas precisely on a WIKI page; this also includes ACLs regarding JCR and Web access rules (???)
• Define the users, groups and roles which are required
• Do not use groups and roles which are provided by the demo-modules. Only re-use groups and roles coming from the "core".
• When creating new groups and roles, use names which contain "test" (such as test-publisher)
• Provide bootstrappable content ready to be added to the test-module(s)