-
-
Notifications
You must be signed in to change notification settings - Fork 27
How Knowledgebase will use People Depot
- Knowledgebase - KB
- People Depot - PD
- Meta document records - MDR
The KB system maintains meta data about documents in MDRs. There are two ways KB uses PD data:
- User and security is set up in PD.
- A MDR can be associated with users, practice areas, program areas, and tools, all maintained by PD. A MDR can also be associated with a phase and with one or more technologies, both maintained by KB.
When accessing the KB system, users can choose to sign up, sign in, or skip with view only access to PD data.
Users signing themselves up through KB will be directed to SSO. Information provided during sign up will populate both the KB and PD users table. During the sign up, the user will be prompted to select admin, maintainer, approver, or create MDR for requested level of access for PD. Admin, mainter, approver, will generate a request in PD and will be approved by a PD or KB administrator. Once the request is approved, the user will be assigned the appropriate role which is then replicated to KB.
Users who have signed up through other apps must have been granted Hack4LA access (is_staff flag = true) either by an admin when creating an account or when reviewing accounts created through self service.
User sign in will sign in through SSO. Any KB roles associated with the user will be gathered.
Only users with a PD account will have access to KB. These users will be able to view all data used by MDR, create an MDR, associate data with the MDR, and update an MDR they added.
Users with Maintainer role will be able to
- view all data as above,
- create, update, and archive/delete MDRs and associations to the MDRs.
- view and update author info for all users
- create, update, and archive/delete technologies and phases
Approvers will be able to do everything a maintainer can, as well as Admin will be able to do all above as well as maintain requests and roles for users.
The above is detailed in the below table.
Roles | Privilege | Admin | Approver | Maintainer | Default |
---|---|---|---|---|---|
User role assignment | |||||
Admin, Approver, Maintainer | View and update author related info for all users (PD) | X | X | X | |
Admin | View, approve, and disapprove requests for KB role (PD) | X | |||
Admin | Assign and de-assign KB roles (PD) | X | |||
Update App Data | |||||
! Admin, Approver, Maintainer | View author related info for all users (PD) | X | X | X | |
All | View all practice areas, program areas and tools (PD) | X | X | X | |
All | Create MDRs (PD) | X | X | X | X |
All | Update and archive MDR created by self, including assocations with practice areas, program areas, and technologies (KB, PD) | X | X | X | |
Admin, Approver, Maintainer | Update and archive any MDR, including assocations with practice areas, program areas, and technologies (KB, PD) | X | X | X | |
Admin, Approver, Maintainer | Create, update, and archive tools and phases (PD) | X | X | X | |
View Privijlges | |||||
All | View MDRs and associations for the MDRs (KB, PD) | X | X | X | X |
All | View App Data | View MDR and details of associations for the MDRs (KB, PD) | X | X | X |
All | View author info of users associated with an MDR (PD) | X | X | X | X |
All | View practice areas, program areas, and technologies (PD) | X | X | X | X |
All | View phases and tools | X | X | X | X |
Users can change password in the KB app which will change the password in PD. Password will not be stored in PD.
When KB is installed, any data in KB will be replicated to PD. Using Django web hooks, shared PD data will be replicated real time to the KB database. Replicated data will be read only. KB users will be able to maintain or view non-PD data using the Django admin screen.
NOTE: Another option is to create an app that uses the KB API when access to the data is required. The replication option was selected because Django Admin cannot use APIs to access data and it is a very convenient UI. The data replication option also makes it easier to use the app for a standalone system.
KB uses Django Admin to enforce security. The security is currently based on users, groups, and permissions. In the future, security will be based on roles instead of groups. A user will be assigned one or more roles. A role is associated with permissions. A user's security is based on all the permissions for all the user's roles.
Django Roles and Groups work the same. Both roles and groups are associated with permissions and users, so both are good for controlling privilege. The concept of "roles" is based on what role do they have in regards to the database. A group is a more generic concept that applies to the physical world, likes "teachers" or "students".
Groups are enabled out of the box. PD will be configured to disable groups and enable roles.
When signing up for an app, the user will be redirected to the SSO for PD.
When signing into an app, the user will be redirected to the SSO for PD. PD will retrieve the roles which are replicated from KB to PD.
- People Depot roles will include: kb.admin and kb.maintainer, kb.viewer.
- Example privileges: kb.add_article, kb.update_article, kb.delete_article, kb.view_article, and kb.do_something_special
- Example model role privileges:
App Owner | Model | Role | Gransted to | Notes |
---|---|---|---|---|
PD | User | view | kb.admin, kb.maintainer | |
PD | User Role, User Role Assignment | Create, View, Delete |
<app_label> .admin |
|
KB | Article / User Assignment | view | public | |
KB | Article / User Assignment | create, delete | kb.admin, kb.maintainer | Updates are not applicable to this model |
PD | Practice Area | view | public | |
KB | Article / Practice Area assignment | view | public | |
KB | Article / Practice Area assignment | create, delete | kb.admin, kb.maintainer | Updates are not applicable for this model |
Django admin enforces the Django roles and privileges through the UI. For example, if the user does not have privileges to add, no Add option will be displayed. A new view will be created
Any Django Rest API created for KB will need to enforce the functional security.
Click Pages above to see all documentation in alphabetic order. The below list organizes the documentation and excludes some less critical documentation.
Onboarding
- Onboarding & offboarding all non-Product team members☑️
- Onboarding & offboarding Product team members☑️
- Additional technical onboarding for Developers☑️
Guides
Draft
- How-Knowledgebase-will-use-People-Depot
- Auto generating seed data scripts from data - generic, non-people depot specific
- Requirements for People Depot V1☑️
- People Depot Tables and Fields☑️
- Other related data☑️
- Stakeholder's that will use People Depot☑️
Security Requirements, Test Cases, and Technical Design
- Security: Functional Requirements. Derived from Test Cases in Issue #150
- [Test Cases] - pending, see Test Cases in Issue #150
- Security: Field Level Proposal (using Github Copilot