Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow users to have multiple roles #421

Closed
Tracked by #386
taesungh opened this issue Dec 5, 2024 · 1 comment · Fixed by #429
Closed
Tracked by #386

Allow users to have multiple roles #421

taesungh opened this issue Dec 5, 2024 · 1 comment · Fixed by #429
Assignees
Labels
2025 For IrvineHacks 2025 backend

Comments

@taesungh
Copy link
Member

taesungh commented Dec 5, 2024

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.

@taesungh taesungh added backend 2025 For IrvineHacks 2025 labels Dec 5, 2024
@taesungh taesungh self-assigned this Dec 6, 2024
@taesungh
Copy link
Member Author

taesungh commented Dec 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2025 For IrvineHacks 2025 backend
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant