You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While general participants (both hackers and non-hackers) should usually have only one role, one inconvenient construct last year was that users could have only one role. This made defining some of the admin authorization more complicated since we had to consider multiple roles that had a common trait.
For example, the isAdminRole function needs to check an array of admin roles and also another for organizer roles. A similar thing happens with require_checkin_associate on the admin API. Both of these could be simplified to anybody with the organizer role, and additional roles can be granted to those who need it.
Allowing multiple roles will make it easier to handle different combinations of roles and also allow for quickly adding roles on the fly (e.g. roles per department if say logistics organizers need special permissions). This will require changes across several places including the UserRecord model, the Participant interface, the user identity, and subsequent usages of the attribute/property.
One possible way to reduce some of the work could be keeping the role field for the user identity as singular but storing a separate property for additional organizer-related roles. This would align with the concept that organizer is equivalent to admin user, but this is just segmenting the problem and may not allow for full flexibility in the future (e.g. if a mentor is also a judge).
Allowing multiple roles could also help simplify managing the applicants collectively given the integration of mentor and volunteer applications to the site (#386): an applicant could have both roles (e.g. applicant and hacker) so checking if somebody is an applicant in general doesn't require tracking the three possible types (or perhaps more in the future).
This change should ideally be made before applications are opened so the database records don't need to be retroactively modified.
The text was updated successfully, but these errors were encountered:
Will proceed with using a single array for multiple possible roles. Thankfully, MongoDB has the same query syntax for checking to query an array for an element.
While general participants (both hackers and non-hackers) should usually have only one role, one inconvenient construct last year was that users could have only one role. This made defining some of the admin authorization more complicated since we had to consider multiple roles that had a common trait.
For example, the
isAdminRole
function needs to check an array of admin roles and also another for organizer roles. A similar thing happens withrequire_checkin_associate
on the admin API. Both of these could be simplified to anybody with the organizer role, and additional roles can be granted to those who need it.Allowing multiple roles will make it easier to handle different combinations of roles and also allow for quickly adding roles on the fly (e.g. roles per department if say logistics organizers need special permissions). This will require changes across several places including the
UserRecord
model, theParticipant
interface, the user identity, and subsequent usages of the attribute/property.One possible way to reduce some of the work could be keeping the role field for the user identity as singular but storing a separate property for additional organizer-related roles. This would align with the concept that organizer is equivalent to admin user, but this is just segmenting the problem and may not allow for full flexibility in the future (e.g. if a mentor is also a judge).
Allowing multiple roles could also help simplify managing the applicants collectively given the integration of mentor and volunteer applications to the site (#386): an applicant could have both roles (e.g. applicant and hacker) so checking if somebody is an applicant in general doesn't require tracking the three possible types (or perhaps more in the future).
This change should ideally be made before applications are opened so the database records don't need to be retroactively modified.
The text was updated successfully, but these errors were encountered: