More roles

[hennevogel]

Currently we have the roles

Admin
Organizer
Participant

But there are other roles for events too, like

Speaker
Volunteer
Press

These roles are also not configurable from the app (only from the seeds file). An Admin should be able to setup more roles from the UI. Roles also don't have a description. What is the difference between Admins and Organizers? This should be clear. Also roles are global and not per event.

[differentreality]

ROLES

1. Global Admin: Can do everything anywhere (can create a new conference, can create an admin for a conference)
2. Conference Admin: Can do everything and anything for a specific conference
3. Conference Organizer: Same as Conference Admin but with restricted executive abilities (for example can vote on a proposal, but cannot accept it. Can create a new registration, but cannot delete a registration.)
4. CfP: a role for the Program Committee members, this role allows users access to the cfp options and events' related options (see and edit events, vote, accept/reject events, scheduling)
5. Info Desk: a role for the team at the Info/Registration desk
6. Some other roles that will be more like labels:
   Attendee, Volunteer, Speaker, Sponsor, Press

WORKFLOW

First user (possibly the sys admin that setups osem on server) becomes Global Admin, with access to everything (incl. full access to all future conferences).

Global Admin creates a new conference and assigns the role of 'Conference Admin'.
[Global Admin must spend time with the conference creation and get the required information from organizers - exact dates of the conference, title, short title, social tag]

Conference Admin administers the conference, has access to everything within the conference and can assign conference-specific-roles to users.
('Global Admin' already has 'Conference Admin' abilities, without being assigned the 'Conference Admin' role.)

• There is a fixed set of roles defined in seeds.rb, these roles are available for all conferences and cannot be deleted.
• Creation of new roles will be allowed from admin panel by 'Global Admin' or 'Conference Admin' or 'Conference Organizer'

[differentreality]

Conference-specific roles can be defined:

1. either by adding an extra field conference_id in the roles_users table
2. or by simply associating roles with registrations
   • Advantages
     1. easy access for Conference Admins from an existing page (Registrations)
   • Disadvantages
     1. More time-consuming for Global Admin who must create a conference, create manually a new registration, then assign role to that registration
     2. If a user unregisters for some reason, their roles are gone and would need to be re-assigned if needed, after they re-register
     3. For very small-scale events that expect very few people and make arrangements for every single one of them, the slightest discrepancy between registrations and actual number of people intending to attend the conference is of importance.

• In option 2 Conference Admins are restricted to see only the users registered to the conference and not all existing users, that could be both be an advantage or a drawback.
  (Think about the scenario where a Conference Admin wants to add a new registration onsite but first wants to confirm that the user already has an account in OSEM, because in that case only the user's email is required in order to create the new registration, instead of additional user details.)

[hennevogel]

Hmmm, I think we can drop the overall admin role. We basically have these data sets to work on:

• Conference
  • Event
  • Registration
  • Volunteers

This makes up nicely for these roles:

• Conference Admin (Overall responsible)
  • Can create and edit conferences
  • Can distribute roles for their conferences
• Program Manager (CFP People)
  • Can modify Events and CallForPaper
• Registration Manager (Info Desk people)
  • Can modify Registration and Questions
• Volunteer Manager
  • Can modify Vposition, Vday etc.
• Attendee, Volunteer, Speaker, Sponsor, Press
  • Can not modify anything

I wouldn't support adding more roles through the UI. That was a stupid idea.

[hennevogel]

Regarding where to store the roles: I would go for something like rolify which simply allows scoped roles plus something like pundit for authorization.

[differentreality]

What I call Global Admin seems to be what you call Conference Admin, because in what you describe Conference Admin is not an admin for a specific conference, he can create and edit any conference.

That person, however, might not always be closely involved with each and every conference, hence we need someone to fully manage a specific conference, without having access to the rest of the conferences.

So you suggest we totally drop cacancan? (cancan is there already, but is not being active anymore, so we would simply switch to cancancan, which is the same as cancan, but is active)

[kalabiyau]

I am for cancancan as it is way flexible

[kalabiyau]

https://github.com/CanCanCommunity/cancancan is way more supported then

https://github.com/elabs/pundit

[hennevogel]

Nope a conference admin can create a conference and edit it, including giving roles to other people. But only in the scope of the conference he created.

We can also use cancancan, I don't mind :)

[differentreality]

Are you suggesting we allow for any user, without any role, to create a new conference?

[hennevogel]

I suggest conference admins can create conferences and assign other users all roles. User1 is the first conference admin.

So I am the first user. I set up oSC15 and assign you the role of conference admin. Now you can edit oSC15 and also create MyConf. If you create MyConf I can't edit it, unless you make me conference admin of this conference.

[differentreality]

OK I am confused. Conference admin will be a conference-specific role, which would mean that for someone to be a conference admin, there would have to be a conference first, for which they are an admin.

[hennevogel]

Conference admin is just a role. It can be scoped or not. The rest is authorization.

Maybe the rolify examples help you to understand why I mean?

[ancorgs]

1. Seems like we all agree to keep using cancancan. Nothing to add here.

2. We should not mix conference-specific roles with system-wide roles. I'm not against the "global admin" concept, but it's not a role. Maybe a flag in the user, maybe a completely different kind of user, but since it's not conference-specific, it's not a role.

3. I don't feel confident with mixing "meaningful" roles (those that have been described and would have some code related to them in the Ability model) with roles that are just labels. It couples the information in the database with the source code. In my experience, that's a time bomb waiting to blow your head. If we have code for those roles in the Ability model, they should be defined in the source code as well (ActiveHash, if you ask me). If we want the users to play freely with the roles, we should provide a way to define the permissions for every role with a completely generic and database-driven code in Ability.

4. About the needed roles. I like the model proposed by @hennevogel except for the conference admin, which looks confusing to me since it seems to mix conference-specific roles with system-wide roles. I would remove the ability to create conferences from the conference admins. The only ones being able to create conferences would be the "superusers" (which, and I'm repeating myself, is not a role but a superpower).

[differentreality]

What I had in mind was to seed the database with the roles we want (just like we do now):
'Organizer' (seems we don't need the whole Conference Admin after all), 'CfP', 'Info Desk', 'Volunteers Coordinator', 'Speaker, 'Attendee', 'Sponsor' etc.

If you want to assign a role you get to choose from these roles.
But with the whole uppercase and spaces in the names, things get more complicated than they should, and rolify doesn't work well with that scenario either.

So for the conference specific roles we should assign the roles in lowercase and substituting spaces with underscore.
Meaning that we will have: 'organizer', 'cfp', 'info_desk' roles assigned to a user for a specific conference.

That would allow us to use the unscoped role (for instance 'Organizer') to allow users with role 'Organizer' to create a new conference too.
(To allow a user to create a conference we would check if user.has_role? :Organizer. To allow a user to administer a conference we would check if user.has_role? :organizer, @conference)

But that's exactly what you are opposed to @ancorgs, right?

[hennevogel]

That's exactly what I proposed yes ;-)

[differentreality]

Should we completely rework the event_users concept and make submitter and speaker 2 roles instead of having the 'event_users' table?

Obviously 'submitter' role will be assigned directly to the user creating a new proposal.
Speaker role can be assigned to the user as soon as the proposal is scheduled.

[differentreality]

So do you think we should try and implement the custom roles as @ancorgs described?

I am in a good place with cancancan and authorization and I would like to rework the role assignment, but it is vital to know if we will simply stick to the pre-selected roles we seed or if we will allow for new roles to be entered (along with their abilities).

[hennevogel]

Regarding the event users. Why do we need roles at all for that? I don't see that we gain anything but complexity from this. An Event has_many Users. That's all we need IMHO. E.g. #332

[hennevogel]

Regarding custom roles: Please don't. OSEM is complex enough. No need to make it even more complex.

[ancorgs]

In fact, I didn't suggest custom roles. I was discouraging mixing custom roles (in case it's decided that they are needed) with non-custom (meaningful and enforced) roles.

I don't think we need custom roles right now, but my opinion is not relevant in that matter because I have not used the tool extensively enough. @differentreality, could you please provide examples in which custom roles are necessary enough to justify its implementation?

[differentreality]

Implemented in #441