Sharing a draft/record doesn't give access to corresponding record requests

[zzacharo]

Package version (if known):

Describe the bug

When a user is sharing their draft/record using the Share functionality, although they can act on the record/draft e.g edit a draft they cannot see act on the subsequent request.

Expected behavior

If a user is granted access to see/edit a record then it is reasonable to also be able to see/act on any associated request.

Proposed Solution

To address the original issue, several changes have been implemented across different architecture layers, summarized below:

Backend

Requests

• The can_read permission now considers the topic of a request. In the case of a record, this is expanded to generate grant_tokens for users with can_preview access, allowing them to access the associated request.

Record

• Whenever the shared access settings of a record are updated, any corresponding review request is reindexed to update its grant_tokens. This ensures that all entities granted access to the record via sharing also gain access to the associated request.

Upload Form

• The ability to manage community selection and record submission has changed. Now, only users with manage access can perform these actions. Users with edit access can modify metadata and publish a record only if it is not associated with a community, submitted to one, or preselected on the upload form. These permissions are correctly enforced for individuals, groups, and links with whom the record has been shared.

Landing Page

• The community inclusion widget is now visible only to users with manage access to the record.

Share of a record or draft

The wording for each permission has been changed to depict the fact that users can have access to the associated request.

Dashboard

Uploads

• A new “shared_with_me” filter has been introduced to distinguish between uploads you can access because you are the owner and those you can access due to granted preview, edit, or manage permissions.
• Since the backend does not provide granular details about a user’s specific access level (e.g., preview or edit), the below change was introduced:
• The Edit button has been removed, and only the “View” button is displayed, following these rules:
• If the upload is published, the “View” button redirects the user to the published record. Depending on their access level, they can edit the record from there to access the draft.
• If the upload is a draft, the “View” button redirects the user to the deposit page of the record. Users with preview access are automatically redirected to the draft’s preview.

Requests

• A new “shared_with_me” filter has been introduced to differentiate between requests that you have access to because you are the creator or recipient and those you can view or comment on due to the request’s topic being a record to which you have preview, edit, or manage access.

New shared or mine filter

Current implementation

Dropdown above the facets on the left

Facet like values

Tab like button above searchbar

Tab like next to search bar

Scoped solution

Uploads

The user will see 2 filters:

• "My uploads": All the uploads created by them
• "Shared with me": All the uploads that were shared with them via the "Share" button either explicitly i.e user sharing or implicitly via group sharing

Screenshots

Requests

The user will see 2 filters:

• "My requests": All the requests created by them or they are the receiver
• "Shared with me": All the requests that were shared with them via the topic of the request i.e when the topic is a record and access was shared via the "Share" button either explicitly i.e user sharing or implicitly via group sharing

Screenshots

Other ideas

• As part of this fix a lot of ideas arised for changing the search display of uploads and requests along with adding the possibility to see uploads and requests across user's communities. We should dump all the ideas on a proper place for future follow-up

[carlinmack]

great write up! thanks