This may sometimes be referred to as proxy editing.
back up to User Stories: Defining features and functionality VIVO needs - September 2011
to be written
The reality is that many faculty and researchers are too busy to edit, and may not have the information required at their fingertips. Much of this can be addressed by regular ingest procedures, but it may also be necessary to allow other people to edit on behalf of the faculty member or researcher.
VIVO is not recommended as a repository or editing environment for confidential data such as social security numbers. Sites may elect to put information they don't wish to expose publicly in VIVO for data alignment purposes – e.g., local employee or department or grant ids.
Given that the information in VIVO is almost exclusively fully public, we have not built out extensive proxy editing features. At Cornell Ithaca we have trained a number of department administrative assistants to edit on behalf of faculty members in their departments, and trusted them to limit their editing to the appropriate people.
Proxy editing would provide the ability to identify who can edit for another person and provide a set of controls for such editing. Two typical patterns have been identified:
The proxy by list method would at its simplest allow user X with an account in VIVO to perform everything that user Y (also with an account in VIVO) could do as a self editor, just as person Y could do if s/he logged in her/himself.
The proxy by rule could become arbitrarily more complex, but in its simplest form would allow a user X with a relationship with an academic department to act as a self-editor for any person Y who has a faculty appointment in that academic department. This has more appeal because the rules, once established, would not require per-person maintenance. It would be harder to implement and enforce, however.
Bear in mind that we need to consider editing organization profiles, facilities, events, and many other types of individuals in VIVO.
With the new authorization work put in place for version 1.3 and being extended somewhat further for version 1.4, we will have better controls over access to a number of different system functions. Sometimes this involves limiting access to a whole section of the website, such as the Site Admin or Ingest Tools. In more granular cases the new authorization support will provide more control over content editing, and enable implementing proxy editing in two stages.
Will 'proxy by list' be enough, or is the more sophisticated 'proxy by relationship' also essential?
Allowing editing with proxy list would be enough as a start.