-
Notifications
You must be signed in to change notification settings - Fork 0
Merging User Types
A thought we had quite late into the project was to simplify the backend by merging all user types and relying on a permissions model instead. This page outlines this idea in more detail.
- Author: Alex Wilkes <adw4236@rit.edu>
Our current system differentiates Job Seekers, Employers, and Educators based on the type of profile they have attached to their account. This presents some limitations.
What if an individual is part of both an educational organization and an employer organization? In this case, they would need two accounts which many individuals may choose, but some may prefer to have one account to manage both.
The alternative to our current system is to only have one type of user account that can be given permissions to add courses or job postings for any organization. Any user will be able to create a new organization and would be assigned as an administrator of that organization by default with all permissions. They could then go on to add other users to that organization and give them permissions to add, edit, or delete job postings or courses as well.
A permissions model will likely be needed at some point in the future anyways, for example if an organization wants recruiters to be able to view job postings and applications, but not create, edit, or delete them. This could be a good oppertunity to get the application ready for that.
It may be prevalent to have organizations conform to a type (educational or employer) if this solution is adopted, but that should be a conversation with the product owner.
One major drawback of this approach is that any user would have the option to create a new organization. There are ways around this, but it will often be to the detriment of UX. Although an argument could be made about any user being able to sign up as an employer in the current version anyways.
Ultimately this was a bigger conversation that our team did not want to have since it came up a bit too close to the end, and we didn't want to make sweeping changes like this at that time. As such, we have left it up to a future team to decide.
- Requirements Gathering
- Templates
- Functional Requirements
- Non-Functional Requirements