| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new user permission system to control the allowed operations
accessible from each account.
Add a permission matrix editable through the user/add and user/edit
views. The permission matrix has client, center, room, folder, image
and repository as permission targets and add, update and delete as
permission types.
Restrict each view based on the user permissions, hide all actions
from not autheticated users.
permissions defined in the class UserForm.
Serialize each user permissions into ogcp.json as:
{
...
"USERS" [
{
"USER": "admin"
...
"PERMISSIONS": {
"CLIENT": {
"ADD": true,
"UPDATE": true,
"DELETE": true,
},
... <- same structure for "CENTER", "ROOM", "FOLDER", "IMAGE"
and "REPOSITORY"
}
},
...
],
...
}
Grant all the permissions to old user configuration to not disrupt their
workflow. The administrator will need to assign the permissions for each
user.
Ignore scope and permission restrictions for admin users.
Save permissions and scopes even if the user is admin to account for the
case of a temporal admin promotion without losing the previous
configuration.
Use template inheritance for add_user.html and edit_user.html to prevent
big code duplication with the new HTML code to render the permission
matrix.
Make user administration an admin only feature.
Define methods get_permission and target_is_disabled to improve readability
in template conditionals that disable features based on user permissions.
|
