We are putting out a request for comments from users around introducing more granular access to items in workgroups.
We have had feedback from some users about the lack of granular controls within workgroups. At the moment, a member of a workgroup depending on their role can either edit or view everything - there is no in-between. For example:
- A workgroup steward can edit all registered content
- A workgroup editor can edit all unregistered content
Administrators are also unable to specify important stakeholders of data, such as owners or approvers of data.
This prevents the following scenarios:
- a user who needs to see things in a workgroup, but is only responsible for maintaining one item.
- A person who has steward access to update one record after its registered, but not all of them.
- A user who needs to see things in a workgroup, but is only responsible for maintaining one item - such as a data asset or classification.
- A user who has delegate authority to give access to a data asset cannot be flagged against an metadata record in the metadata registry
- A user who should be given
All of this could be achieved by having more workgroups, with one item per group. But if there are many items that require restricted access, this would mean there could be many workgroups with only one item. Or broader permissions would need to be provided.
To resolve this, we are seeking feedback on new “access controls” or “assignment types” where workgroup managers could add people on an item by item basis with restricted controls.
Workgroup-Assigned User Access Controls
-
Stewardship Organisation Admins would be able to define “assignment types” for Workgroup managers to use within the Stewardship Organisation.
- These would have:
- title - the name of the assignment type (see examples below)
- description - a brief description of the assignment type
- item permission, ie. what can the user do to the item (submitter/steward/viewer - default:viewer)
- transferable, ie. they can a user give this assignment to another user, default to ‘no’
- who the assignment is visible to (public, authenticated, SO, WG, default: WG) - we don’t need to include this, maybe this is a stretch goal
- Stewardship Organisations would also be able to delete “assignment types”
- These would have:
-
Item Assignment
- A manager in a workgroup could assign (or bulk assign) items to any user in the stewardship organisation
- An assigned user may not need to be a member of the workgroup - so the permission to maintain an item can be kept separate from the “owning” workgroup.
- However, an assigned user must be a member of the Stewardship Organisation. This restriction will ensure that a Workgroup Manager does not override Stewardship Organisation Administrator controls around inviting non-members.
-
Assigned Items
- Users who have been assigned to an item are given a new page in their dashboard metadata listing page of all the items they have been explicitly assigned to.
- Users would gain the appropriate permissions to that item.
- They will see a list of these items, with the workgroup its in. Because they can see the item, they can also open issues or reviews against the item.
-
A user can remove their own assignment - with a notification sent to workgroup managers
Examples of roles could be:
- Data Asset Owner: Someone who has view only access, and is responsible for and holds the actual data asset (the person who controls the database)
- Reviewer: Someone who has view only access to a metadata item
- Access Approver: Someone who has view access to a metadata item, but is the person who can approve access to the data asset
- Data Steward: The person who has write access to a metadata record
Out of scope:
This proposal only covers individual users and items only. We aren’t including the idea of “teams” within a Workgroup, where a team of users could be assigned access to a subset of items in a workgroup, but may consider adding this at a later stage.
We ae not calling these “roles” as we see an additional separate feature for bulk assigning permissions - eg. membership to multiple workgroups as a “role” we are scoping for late in the 2025 roadmap.