Introduce roles alongside permissions

[jace]

Permissions are assigned to users against apps. Roles, OTOH, are assigned to teams within organizations.

Roles potentially replace the hardcoded "Owners" role that exists at the database level.

[jace]

"Owners" is problematic because it determines access rights within Lastuser, while the role will be defined in the database. This means Lastuser will need to be configured to recognise roles specified in the database.

[jace]

Today's discussion with @rudimk and @shreyas-satish brought up another issue: there is still no way to assign roles at a context more specific than "Organization", so this can't be used to grant access rights within an event in Funnel.

Thought: Maybe augment the role assignment with an optional context, a buid string that is relevant to the client alone. This similar to the context in #114 and could perhaps be the same model.

[rudimk]

Essentially, this means one can't assign a role that only gives a user access to event A, but not event B, in Funnel. So your idea of augmenting roles with a context, makes sense. But this means the client will have to create these contexts, which is like the problem with creating roles for event A and event B - users probably don't want to be burdened with that sort of thing, unless contexts can be manipulated with an API - then it would work just fine.

[jace]

Contexts are entirely API driven. There's no UI to them.

[rudimk]

Okay. Then I reckon it works out.

[jace]

Needs scenario analysis. The permission split between Lastuser and client apps has already made it difficult to build decent UI. This shouldn't make it worse.

[jace]

As discussed in #128 (context objects), app-level roles shouldn't be mixed up with Lastuser roles. We should drop that entirely from the scope of this ticket.

This leaves us with a fairly simple role definition:

class ROLE(LabeledEnum):
    OWNER = (0, 'owner', __("Owner"))
    ADMIN = (1, 'admin', __("Admin"))
    MEMBER = (2, 'member', __("Member"))

role is now a status column on the relationship that makes users part of a team or organization.

[jace]

Role definitions:

1. Users can have a role in an organization (per De-link organizations and teams #151). Being an "owner" gives them full control of the organization. Being an "admin" gives them control over membership not including owners, and no access to organization settings such as the username and title. Being a "member" grants no privileges.

2. Users can have roles in teams. The same principles apply, but these roles do not extend to the organization.

3. Optional: Teams can have roles in organizations (same set of roles). This has potential complications and can confuse users, so we should consider not supporting this. For example, a user with "Member" role in a Team that in turn has "Owner" role on the Organization is now an owner even though they think they are a member: ownership of the organization trickles down into ownership of the team and a member of the team is now an owner of the team.

[rudimk]

Wow. This was one of the first things we tried to flesh out back in Nov 2014.

[jace]

If we remove the Members and Owners teams, this may break Flask-Lastuser, which expects userids against them, especially when syncing teams in the client app.

[jace]

Example from Telegram of permissions attached to a role. If we use this approach, apps can specify additional permissions to Lastuser, which it can include in the UI.

[jace]

If we remove the Members and Owners teams, this may break Flask-Lastuser, which expects userids against them, especially when syncing teams in the client app.

As discussed in #232:

Temporary workaround: every organization has two uuid columns to represent owners and members, and the API passes these on in place of teams; all other teams will be deleted.

Roles will be limited to Admin or Member and specified as an admin flag on the org membership model. We'll eschew more elaborate role definition for now while we migrate organisations to Funnel as per #232.

[jace]

Following from #232, organizations and roles will move into Funnel via hasgeek/funnel#401. This ticket is no longer necessary. Lastuser's code will remain untouched, only marked as deprecated, until client apps have been reoriented to Funnel and the code can be removed.