Page tree
Skip to end of metadata
Go to start of metadata
DescriptionAdvanced role management
Typeadministration
Status
DRAFT
OwnerTIB
LanguageJava
Team
Locationtba
License

Goals

  • Develop frontend elements to create and administrate custom roles in VIVO

Description

Phase I: Discrete display / edit assertions to replace “and below” permissions for fields (Haken)

We want to have discrete assertions for saying that a role is able to display and/or edit a field, rather than the current hiddenFromDisplayBelowRoleLevelAnnot / prohibitedFromUpdateBelowRoleLevelAnnot. This will also involve changing admin screens that provide a display level / update level to allow for a checkbox based assertion of multiple roles, rather than a drop-down / radio button.

In changing over the assertions, it will still support modelling the same restrictions, but rather than saying – for example -  “:hiddenFromDisplayBelowRoleLevelAnnot :EDITOR”, it would require “:displayFor :EDITOR”, “:displayFor :CURATOR”, “:displayFor :DB_ADMIN”, and “:displayFor :NOBODY”.

Phase II: Create an upgrade script to replace the existing “and below” permissions (Haken)

In order to push these changes to existing triple stores, we will create a script process that will rewrite existing “DisplayBelow / UpdateBelow” assertions into the equivalent granting of rights to the existing roles. We will also update the default definitions in the home folder for creating a new Vitro / VIVO instance.

Phase III: Remove hardcoded references to role levels from the Java code (Haken)

Now, there shouldn’t be anything left that assumes the inherited model of role authorisation. Once that is confirmed, we can externalise the role level definitions from the BaseResourceBean (and the PermissionSets uris?), and have the available roles defined entirely by configuration.

This would open up the possibility for defining more roles in the system (and giving them discrete permissions! – so one group of users might only edit publications, and another only grants). At this stage, new roles would be established in the configuration files, and become available on restart, although the field permissions could be updated within Vitro / VIVO.

Once the above is implemented, we would likely to be looking at making the changes available for Vitro (and the configuration for VIVO), subject to evaluation.  Further developments then possibly include:

Phase IV: Role-oriented control panel for enabling/disabling permissions (Haken)

Simple control panel(s) for setting the permissions for roles across multiple fields, in addition to editing permissions on a field-by-field basis (a grid of checkboxes, fields on one axis, roles on the other.)

  • Ontology editor (Haken)
  • Page management (tbd.)

Phase V: Control panel for creating new roles

Ultimately, we may need to have a means for creating new roles within the application directly, not just establishing them in the configuration files to be reloaded on restarting VIVO, which would involve resolving issues around how PermissionSets are loaded.

Features (tbd.)

  • Clone roles
  • Edit roles
  • Delete non-default roles (not self-editor, editor, curator etc.)
  • import and export of roles, including set of rights

Documentation

Ticket: VIVO-1436 - Getting issue details... STATUS

Where do roles appear in VIVO?

User Account Management

  • Generate dynamic list of all existing roles
  • Test, if multiple roles are shown in the user account table

image2017-10-26_16-36-59.png

Ontology editor (tick)

  • Develop a matrix / table view to allow to administrate the set of rights belonging to a property or class in the ontology editor.
  • Checkboxes for each role for all the three permissions (display, update, publish)

SiteAdmin

  • New menu item: Role management

image2017-10-26_16-40-26.png

Page Management

Control the permission to display web pages. Menu similar to Ontology Editor integration.

image2017-12-1_10-31-24.png

Notes