Per definition, the guest doesn't have very extensive information about them available in g.identity.
The code along the usual resource/service path for creating comments on requests builds the comment creator/author from the identity.
However, this logic can only really handle "real" users or the "system" user and doesn't support any sort of "guest".
So for now, we've just simply disabled the permissions for guests to create comments on guest access requests.
Since not being able to communicate back-and-forth through the request has a quite negative impact on its usability, we should address this issue.
One potential way would be to add an EmailNeed (or similar) to the guest's identity when they access the request detail page (with the request_access_token), and teach the request events service to handle this sort of identity as well.
This would probably require allowing email entities (keywords: EmailProxy and EmailResolver) as comment creators in the request events service, and somehow encoding the guest's email address in the access_request_token (e.g. by utilizing JWTs like secret links do).
NOTE: During creation of the guest access request, the guest's message will be posted by the system_identity as the first comment to the request (with the prefix "{full_name} ({email}) commented: ").
kpsherva
commented
1 year ago
Per definition, the guest doesn't have very extensive information about them available in
g.identity. The code along the usual resource/service path for creating comments on requests builds the comment creator/author from theidentity. However, this logic can only really handle "real" users or the "system" user and doesn't support any sort of "guest". So for now, we've just simply disabled the permissions for guests to create comments on guest access requests. Since not being able to communicate back-and-forth through the request has a quite negative impact on its usability, we should address this issue.One potential way would be to add an EmailNeed (or similar) to the guest's identity when they access the request detail page (with the request_access_token), and teach the request events service to handle this sort of identity as well. This would probably require allowing email entities (keywords: EmailProxy and EmailResolver) as comment creators in the request events service, and somehow encoding the guest's email address in the access_request_token (e.g. by utilizing JWTs like secret links do).
invenio_requests.resources.events.resource:RequestCommentsResource.create()invenio_requests.services.events.service:RequestEventsService.create()invenio_rdm_records.requests.entity_resolversinvenio_rdm_records.requests.access.models:AccessRequestTokeninvenio_rdm_records.requests.access.permissions:AccessRequestTokenNeedinvenio_rdm_records.secret_links.models:SecretLink.create()NOTE: During creation of the guest access request, the guest's message will be posted by the system_identity as the first comment to the request (with the prefix "{full_name} ({email}) commented: ").
invenio_rdm_records.services.access.service:RecordAccessService.create_guest_access_request()