Membership based access levels for Team Content

Get Help
1

I’m struggling to make fibery have the following very common team content access requirements, based on team and user specific memberships.
For example: In a FinanceTeam, the financial officer needs editor access to Pages with ‘Editors’ access set, but the secretary needs only viewing access to Pages that have ‘Viewers’ access set. A similar scenario would be a Product development team where the Developers need full editing access to code tagged ‘In Dev’ and the Visitors need only access to code ‘Published’.

Goal:

To allow a team member to have specific level of access to a team page, based on the settings in their Membership entity.

For example:
John has membership entity ‘TeamA Page Editor’, giving him access to all team pages that have AccessLevel set to ‘Editors’
John should not have access to Editors team pages of team B.

Thus, the access propagation should restrict to one Team and one AccessLevel.

Schema

In an attempt to accomplish this, I have set up the following databases:

  • Database: Team
    • Field: Memberships (1:M)
    • Field: Users (M:M)
    • Field: Pages (1:M)
  • Database: Membership
    • Field: Team (M:1)
    • Field: User (M:1)
    • Field: AccessLevel (to db AccessLevel) (M:1)
    • Field: StartDate
  • Database: AccessLevel
    • Field: Viewers (to db Page) (1:M)
    • Field: Editors (to db Page) (1:M)
  • Database: Page
    • Field: AccessLevel (M:1)
    • Field: Team (M:1)

Question: how to solve this?

Likely one or more Custom Access Template (CAT) will need to be created, and user fields in the Team database and/or the Membership database need to be set to automatically assign users to these CATs.

I have to been able to accomplish this, since a Membership CAT can allow by AccessLevel to Pages, but cannot restrict by Team also?
Also, a Team CAT can allow by Accesslevel to Pages, but cannot restrict by Membership?

2

It seems that this stated goal is inconsistent with this:

which implies that you are not only wanting to control access based on a person’s Team membership (including the ‘role’ they play in that team) but also based on some property of the page itself :thinking:

I’m not sure how common this combination of requirements is, if I have understood correctly.

Maybe I’ve misunderstood what you are after (and it does seem that your database definitions are incomplete, given that the AccessLevel database has two relations to the Page database, but the Page database only references a single relation to the AccessLevel database).

For what it’s worth, there is a common model for access that looks something like this:

Teams db
Field: Editor members (m:m relation to User db)
Field: Viewer members (m:m relation to User db)
Field: Pages (1:m relation to Pages db)

User db
Field: Teams as Editor member (m:m relation to Teams db)
Field: Teams as Viewer member (m:m relation to Teams db)

Pages db
Field: Team (m:1 relation to Teams db)
Field: Team Editors (lookup from Teams→Editor members)
Field: Team Viewers (lookups from Teams→Viewer members)

You can then set automatic sharing of pages via these lookup relations:

image
image912×860 33.9 KB

image
image936×880 35.8 KB

Accordingly, if John is linked to Team A via the ‘Editor members’ field, then he will be able to edit any Pages that are linked to Team A.

If you want to have an ‘orthogonal’ form of access control, so that Users can have access to all Pages with their capability determined by some ‘privilege’ level, then you could setup the following:

PrivilegeLevel db
Field: Users (m:1 relation to User db) with Use PrivilegeLevels as User Groups enabled
image
with entities e.g. Management and Employees

Then, once we have released ‘Share database with groups’ feature (in about 2 weeks’ time* :crossed_fingers: ) you will be able to automatically share the Pages db (and thus every page) with Management (getting editor rights) and with Employees (getting viewer rights).

*if you can’t wait, then you can already achieve the same effect with custom access templates, but I shan’t bother explaining how :wink:

1 Like