Authorisation Management

When a user joins an organization, a membership record is created.

{
    user,
    org,
    role: "GUEST" | "MEMBER" | "OWNER"
}

The user's role in the org will determine their authorization to perform organizartion-wide actions like adding/removing users, renaming, creating new projects, etc.

When a user joins a team, a team membership is created.

{
    user,
    org,
    team
}

When a user joins a project, a collaboration is created.

{
    org,
    owner,
    ownerType: "USER" | "TEAM"
    project,
    permission: "READ" | "WRITE" | "MANAGE"
}

Authorizing Org Actions

A user has only one relationship with an org: membership.

When a user tries to perform an action on an org, fetch the single membership that associates the user with the org and check the membership.role.

Authorizing Project Actions

A user can have multiple relationships with a project. For instance, a user may be added to a project and, at the same time, a team the user belongs to may also be added to the same project. Each addition may have a different permission. A user may also belong to multiple teams which are simultaneously added to a project with different permissions. These possibilities make authorizing project actions a bit more complex.

When a CURRENT_USER tries to perform an ACTION on a PROJECT which requires a PERMISSION:

Get TEAMS the CURRENT_USER belongs to in this ORG: findTeamMemberships({ user, team, org })
Get all COLLABORATIONS on the PROJECT with permission greater than or equal to the required PERMISSION
For each COLLABORATION in COLLABORATIONS:
- If the COLLABORATION is for a USER AND that USER === CURRENT_USER
- return true
- If the COLLABORATION is for a TEAM AND TEAMS include that TEAM
- return true
return false

[ ] Create user invitations to org (with link generation)
[ ] View user invitations to org
[ ] Update user invitations to org
[ ] Delete user invitations to org
[ ] Accept user invitations to org (using the generated link)
[ ] Ignore user invitations to org (using the generated link)
[ ] Create user invitations to team (with link generation)
[ ] View user invitations to team
[ ] Update user invitations to team
[ ] Delete user invitations to team
[ ] Accept user invitations to team (using the generated link)
[ ] Ignore user invitations to team (using the generated link)
[ ] Request for user invitation to team (the team manager will be notified)
[ ] Accept request for user invitation to team (an invitation, with link, will be generated)
[ ] Ignore request for user invitation to team
[ ] Add user to project
[ ] Remove user from project
[ ] Change user's permission in project
[ ] Add team to project
[ ] Remove team from project
[ ] Change team's permission in project
[x] Add authorization middleware to org routes
[x] Add authorization middleware to project routes

OLD NOTE:

Organisation:

An organisation can be private or public (default).

Viewing an organisation

If the organisation is public then you can view it

If not

If you are a member of the organisation then you can view it

Updating, deleting an organisation (including creating teams and projects)

If you are a member of the organisation and any of the teams you belong to within the organisation has ADMIN privilege then you can view it

Project:

A project can be either private or public.

A project can belong to a user or an organisation.

A project will assume the visibility (private/public) of its parent organisation, if it belongs to an organisation.

A project will be public by default if it belongs to a user.

Behind the scene a default organisation is created for each user. The user is added to a default team within that organisation with ADMIN privilege.

Viewing a project:

If the project is public then you can view it

If the project is private

If the project is a user project

Same as the rules for organisation project because, internally, every project is an organisation project.

If the project is an organisation project

If you are a member of the parent organisation then you can view it

Updating, deleting a project:

If the project is a user project

Same as the rules for organisation project because, internally, every project is an organisation project.

If the project is an organisation project

If you belong to any team that has WRITE privilege on that project or ADMIN privilege then you can update it

Permission:

Team

Privilege (GUEST, READ, WRITE, ADMIN)

Resource

agnos-cloud / agnos-rest-api