populate Share -> Grants and Links to the inclusion request

[kpsherva]

Use case:

User who receives the access by Access Grant or Secret Link should be able to access also the associated inclusion request of the record:

User who has the edit rights for the draft can see this, and use the link.

Implementation

AccessGrant("edit") and SecretLink("edit") should be added to permissions in

class RDMRequestsPermissionPolicy:

- can_read = RequestPermissionPolicy.can_read + [guest_token]
+ can_read = RequestPermissionPolicy.can_read + [guest_token, SecretLinks("edit")]
    can_update = RequestPermissionPolicy.can_update + [guest_token]
    can_action_submit = RequestPermissionPolicy.can_action_submit + [guest_token]
    can_action_cancel = RequestPermissionPolicy.can_action_cancel + [guest_token]
    can_create_comment = can_read
    can_update_comment = RequestPermissionPolicy.can_update_comment + [guest_token]
    can_delete_comment = RequestPermissionPolicy.can_delete_comment + [guest_token]

The generators should be made aware of request: https://github.com/inveniosoftware/invenio-rdm-records/blob/master/invenio_rdm_records/services/generators.py#L281

Normally the request reaches the generator as record= kwarg, but in case of the requests it is passed down a little bit differently: https://github.com/inveniosoftware/invenio-requests/blob/master/invenio_requests/services/requests/service.py#L141 (as request, not record)

in the end, the generator should be able to read the access from record.parent.access, therefore we need to have the record resolved from the request topic somewhere, and there are 3 options:

1. Request service should pass it down resolved, when checking permissions
2. We could create another Generator with resolves the record from request["topic"]
3. We could improve the existing generator to be aware of the request topic (not preferable, it becomes quite record type specific.

Permissions for requests

We need to make the permissions for requests a bit "tighter" to also take into account the type of request

we have currently:

    # Read/update/delete action deals with requests in **multiple states**, and
    # thus must take the request status into account.
    can_read = [
        Status(["created"], [Creator()]),
        Status(
            ["submitted", "deleted", "cancelled", "expired", "accepted", "declined"],
            [Creator(), Receiver()],
        ),
        SystemProcess(),
    ]

But we only want the community-submission to have SecretLink and AccessGrant access added. We don't want other request types to be accessed in this way.

Views

we need also change the record view to be protected by @secret_link_or_login_required() instead of @login_required decorator, otherwise it will ask for login even if user access it by Secret link

Users

User accessing by Secret link will trigger server error, since we are not correctly resolving the UserEntity for anonymous user resolver. Two solutions for this:

• dedicated request endpoint without user dashboard (still there will problem with commenting by anonymous)
• improve the resolver for users to handle anonymous as well

Links

it becomes impossible to use /me/request/<UUID> as the link for View request (see 2nd screenshot) since the request can be now accessed by SecretLink holders, who will not have a dashboard

[github-actions[bot]]

This issue was automatically marked as stale.