ACL Database Models, Permissions system

[shivamMg]

Child of the parent issue: #623

We first need to define correct relationships between models to make them work.

• Event-User-Role relationship
• Role-Service-Mode relationship (Permissions)

Here's a simple representation: https://wireframe.cc/azBwUN

EventUserRoles defines user-roles for Events. So it can contain e.g.:

Event	User	Role
OTS16	Walter	Track Organizer
OTS17	Walter	Organizer
OTS16	Jessie	Organizer

Services include Tracks, Microlocations, Speakers, etc. The Permissions table will have Role-Service modes. e.g.

Role	Service	Mode
Track Organizer	Tracks	1110 (14)
Organizer	Sessions	1111 (15)
Organizer	Microlocations	0010 (2)
Super Admin	Sessions	1111
Super Admin	Tracks	1111

Mode is a 4 bit value (like unix modes) for CRUD (create, read, update, delete). 1110 meaning permission to create, read, update, but not delete.

This system is extendable, since new roles and their set of permissions on Services can be defined in the database, so there doesn't have to be just a Track Organizer, an Organizer, a Super Admin, etc. More roles can be added.

In the end we can create has_perm property for user. e.g.

user.has_perm("create", Track, event_id)
user.has_perm("delete", Session, event_id)

I've thought of implementing this.

@rafalkowalski @aditya1702 @mariobehling
What do you guys think?

Also, this is in regard to how @juslee thought of implementing it: Any user can create an event. He will automatically be the Owner (the main organizer) of the event. He can specify user roles and then associate users with them.

[rafalkowalski]

@shivamMg sounds good but How can we implement track organizers? track organizer can be responsible for few tracs

[shivamMg]

@rafalkowalski This is something that I wanted to ask. Will the organizer (of an event) first specify what user role to assign (e.g. Track Organizer) and then specify what tracks the user must manage. If this is the case then there really doesn't seem the use of roles, since this can be managed in a simple permissions table, like so:

User	Service	Service ID	Permission (modes)	Can do (not part of table)
Walter	Track	3	1100	Can create, read /events/1/tracks/3
Walter	Track	4	1100	Can create, read /events/1/tracks/4
Walter	Level	1	1111	Can do anything /events/1/levels/1

And to check for permission one can use user.has_perm(operation, service, service_id).

e.g. user.has_perm("create", Track, 3).

[rafalkowalski]

Looks great!

[mariobehling]

Yes, there are two kind of permissions. Both need to be implemented.

1. Roles that are related to events as outlined in Implement Database, Architecture and Permission System #623
2. Roles that are systemwide: At the moment Super Admin, and probably more in future
   The Super Admin can do anything in any event and access /admin/ area. He/she can change any role and upgrade/downgrade anyone in any event. He/she can create and change user profiles and sessions. In future when more features get added, e.g. payments, this role can also do anything then.