This allows for the many-to-many relationships, so that any given user can potentially have many roles.
The roles_lookup affords us the following benefits:
For the nerds: normalization.
For the rest of us:
Increased organization: To quickly see what roles/departments exist, this table is our go-to.
No duplication: Rather than having repeats of role and department names, we put these into a table of their own and reference them by id.
Ease of adding new roles/departments: roles_lookup provides a centralized spot for adding new roles/departments.
Database size efficiency: our users_roles table will stay relatively compact because it only contains numeric values (IDs).
Created routes for api gets/posts:
Route to show all users; /access-report.
Route to show all users and their roles; /users-roles.
Route to create role(s)/dept(s); /create-roles.
Route to assign role(s) to user(s); /assign-roles. Note: Any number of users can be assigned any number of role/dept combinations.
Route to delete a user.
How to use
See README.md or README-Windows.md for all the bash or Powershell API requests, respectively.
Needs fulfilled
Efficiency: With a quick API call, we can handle many oft-used functions.
Ease: See above :-)
Duplicate aware: For example, these functions won't allow you to add the same role/dept combo or give a user the same role/dept twice.
Issue: https://github.com/ScotterMonk/scottswain/issues/5
Modified database to have two extra tables:
Needs fulfilled
This allows for the many-to-many relationships, so that any given user can potentially have many roles. The roles_lookup affords us the following benefits:
Created routes for api gets/posts:
How to use
See README.md or README-Windows.md for all the bash or Powershell API requests, respectively.
Needs fulfilled