[MGNLTEST-63] Provide users, groups and roles used for functional tests (phase-1) Created: 15/Aug/19  Updated: 07/Jul/20  Resolved: 03/Sep/19

Status: Closed
Project: Magnolia Test Framework
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Neutral
Reporter: Christoph Meier Assignee: Christoph Meier
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MGNLDEMO-361 Eric can edit & publish while Peter i... Closed
relation
is related to MAGNOLIA-8156 Sane security defaults to onboard use... Selected
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Epic Link: core-TF-features-bugs-improvements

 Description   

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

persona main function
armin Basically a user with with all the permissions of the superuser.
paige Content editor, can edit content on (all?) content apps.
pablo Can publish
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)


 Comments   
Comment by Christoph Meier [ 20/Aug/19 ]

Results for the refined scope 

Comment by Christoph Meier [ 03/Sep/19 ]

comments provided by Mika in slack:

... try to simplify the bootstraps (unquoting, lots of useless metadata, especially on sub-nodes), you can compare with Armin on the PR.

I will do this on the follow-up ticket. This one only creates armin, where the bootstrap already has been cleaned-up.

 

Maybe another open question is how far do you want to go in personifying/describing our Personas? !https://a.slack-edge.com/production-standard-emoji-assets/10.2/apple-medium/1f642.png!e.g. the atlassian way or a simpler variation of it (they even print them out and hang them to the walls iirc):
• https://www.slideshare.net/svenpeters/coding-culture/58-PERSONA_CARDS
• https://atlassian.design/guidelines/voiceAndTone/personas

I will check this, and provide an appropriate description of the next personas to define (paige, pablo, etc. pp)

 

Generated at Mon Feb 12 07:45:12 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.