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

Commencez par examiner les listes de privilèges par rôle et au niveau des champs dans cette issue, y compris le tableau préliminaire et le comportement proposé de l’API kb/user. Résolvez la terminologie, les incohérences dans les noms de rôles, les entrées de privilèges manquantes et les champs utilisateur requis, puis obtenez l’approbation de Bonnie ; l’implémentation fait explicitement l’objet d’une issue distincte.

Rédigé par le modèle d'indexation à partir du texte de l'issue.