Draft: Define KB security rules

### Overview
Define roles and security rules so that a user can be assigned appropriate privileges

### Action Items
- [ ] Get approval from Bonnie

### Overview

Define privileges for KB roles for user and groups so that KB users have privileges needed and no unneeded priviliges and no information they don't. Implementation will be a separate issue.

### Action Items
- [ ] Review Detail Section
- [ ] Decide on which user fields are needed by KB users that will be displayed on the documents.

### Details Draft
There will be an API kb/user. The API will enforce user security based on PD roles that start with kb. The roles will be seeded into the existing Django roles table.

Terminology: A contributor is a People Depot user with the kb-contributor role. The API will be secured using Django roles. Below are the Django roles and what a

name
linked in
website
**Row Level Privileges**
- kb-nonpriv: user that can be associated with a document but has no privileges
- no privilege
- kb-viewer: user that can view all information but has no privileges
- PD: can view up to date level 1 fields of a PD user and roles
- can view all KB info
- kb-contributor
- PD: can view up to date level 1 fields of a PD user and roles
- can view all KB info
- can create a document
- can assign themselves to a document
- can update documents to which they are assigned
- kb-docadmin
- PD: can view up to date level 1 fields of a PD user and roles for users with a kb role
- can view all KB info
- can create, read, and update all documents
- can assign and deassign any contributor to a document. Some contributors may be Hack4LA users.
- can update all documents
- kb-admin
- PD: can view up to date level 1 fields of a PD user and roles for users with a kb role
- can view all KB info
- can create, read, and update all documents
- can assign and deassign any contributor to a document. Some contributors may be Hack4LA users.
- can create, read, and update all kb info (e.g.: topic area) that is not sourced from PD (e.g., users, roles, practice areas, and topic areas)
Below this is specified in table format.
Role | Users | Assign Yourself | View All KB Info | Self Assign | Update assigned document | Update all documents and assignments |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| kb-viewer | X | | | |
| kb-contributor | | | | |
| kb-docadmin | X | X | ||
| kb-poweuser | X | X | X |||
| kb-admin | X | X | X | X | X | X | X |

**Field Level Privleges**

- Read: Field level read privileges are the same for all users.
- Update: kb-admin and kb-useradmin can update any non-system fields that can be read except system populated fields.
- Create: kb-admin can specify any non-system field they can read

Comienza revisando las listas de privilegios por rol y a nivel de campo de este issue, incluida la tabla preliminar y el comportamiento propuesto de la API kb/user. Resuelve la terminología, las inconsistencias en los nombres de roles, las entradas de privilegios que faltan y los campos de usuario requeridos; después obtén la aprobación de Bonnie. La implementación es explícitamente un issue separado.

Escrito por el modelo de indexación a partir del texto del issue.