Make clear who else has access to a Space

[exalate-issue-sync]

Description

User Stories

• As a Space Manager I want to know who is a member of the space so that I can add or remove members.

• As a Space Member I want to know who has access to a space so that I know with whom I'm collaborating with.

• As a Space Member I want a "at-a-glance" overview on who has access to specific files so that I'm reassured, that I don't share files accidentally with the wrong person.

Value

• improve collaboration within spaces

Acceptance Criteria

• Every member or manager of a space can see the full list of members and managers of the corresponding space
  • in Space root
  • in Space-subfolders
• Managers can edit the roles of members
• Regular members can see with whom else the Space is shared incl. roles, but members can't edit roles.
• Share receiver can't see the list of space members (c.f. regular sharing behaviour)

List-Grouping

If there are shares, the Shared-list is split into 2 groups:

• Shares
• Space Members

Members- and People-Panel

• Space-root only knows 'Members': If the user is in the space root, the "people panel" is called "Members"
  • only editable by managers
  • read-only for regular members
  • no regular sharing possible in space root)
• Subfolders know 'Members' and 'Shares' if the user is in a space subfolder, wording stays the same as is (= People)

Shares-List group

• If the role can be edited, the item is on top of the list (multiple editable items are sorted from A-Z)
• After the editable items, the following items are sorted from A-Z

*Space Members group

• Items with the role "Manager" are on top (multiple "Manger"-items are sorted from A-Z)
• After the "Manager"-items, the following items are sorted from A-Z
• If a Space members role had been changed for a certain folder, that member gets also listed in the "shares-list group" with the deviating role and given inheritance-indicator.

Grouping

relates to "Share List: Add inheritance-indicators": #6528

Definition of done

• Functional requirements
  [ ] functionality described in the user story works
  [ ] acceptance criteria are fulfilled
• Quality
  [ ] codre review happened
  [ ] CI is green
  [ ] critical code received unit tests by the developer
  [ ] automated tests passed (if automated tests are not available, this test needs to be created and passed
• Non-functional requirements
  [ ] no sonar cloud issues

[tbsbdr]

Resource Sharing ui is utilized to list Space Members:

@pmaier1 Suggestion: As a regular member (non-Space-Manager), you should see the roles of the other Members (Role-picker is disabled -> read only for members) do you agree?

[pmaier1]

@pmaier1 Suggestion: As a regular member (non-Space-Manager), you should see the roles of the other Members (Role-picker is disabled -> read only for members) do you agree?

Yes, full agree.

Generally speaking, I'd vote for calling the role Manager, not Space Manager.

[tbsbdr]

updated ACs, added scribbles

[tbsbdr]

update: removed inheritance indicators from space-members. they only add little value and got removed in favor of a more clear ui. cc @JammingBen

[JammingBen]

Closing here all related PRs are finally done 🥳