-
Notifications
You must be signed in to change notification settings - Fork 0
Roadmap
Rachel Fish edited this page Mar 20, 2020
·
3 revisions
The users table stores all of the basic user account information required for logging in. This table does not include optional information like full names and phone numbers.
- id (auto-incrementing, primary key)
- email (unique)
- password
- created_at
- updated_at
- login_at
- reset_time
- reset_token
This table contains all of the user data that may optionally be associated with a user account. All of these fields are nullable except user_id.
- user_id (foreign key, users table)
- full_name
- preferred_name
- phone
- created_at
- updated_at
- id
- name
- created_at
- updated_at
- id
- role_id
- user_id
- assigned_by
- created_at
- updated_at
- deleted_at
- id
- name
- description
- created_at
- updated_at
- id
- role_id
- feature_id
- created_at
- updated_at
- id
- name
- description
- created_at
- updated_at
- id
- user_id
- department_id
- created_at
- updated_at
- id
- phone
- department_id
- service_type
- contact_name
- created_at
- updated_at
- id
- notable_id
- notable_type
- content
- created_at
- updated_at
- id
- name
- template_location
- created_at
- updated_at
- id
- user_id
- sent_by
- notification_id
- html_body
- array of variables that were passed into the template??
- In the volunteer database, all of the user access levels are manually defined. Each role (admin, department lead) has access to different features as defined here: https://github.com/playasoft/volunteers/blob/b279d8c334375974c55b42a53eae3352a895d7e7/laravel/app/Providers/AuthServiceProvider.php
- If all of the user roles in the new event management system are dynamically created, how will we handle what features are available to different access levels?
- My proposal: The creation of an additional table, "features" which is automatically populated at install time via a seeder and "role features" which associates features with specific roles
- Create a swagger spec?