Investigate multiple users requesting Zenodo DOI

Is your feature request related to a problem? Please describe. When working on #4293, I discovered that multiple users can’t request a Zenodo DOI for a workflow.

The following scenario doesn’t work:

• User A and User B belong to the same GitHub organization, so they’re both able to edit Workflow Z on Dockstore. Workflow Z has Version 1 and Version 2.
• User A requests a DOI for Version 1 and it’s created successfully.
• User B requests a DOI for Version 2 and it fails with a permission error You don't have the permission to access the requested resource. It is either read-protected or not readable by the server.

Describe the solution you’d like Our current Zenodo/DOI implementation assumes one user. We should investigate a multiple users implementation. One thing to note is that if multiple users were able to request a DOI, there might be multiple concept DOIs for a single workflow.

Additional context This relates to multiple users exporting to ORCID because a DOI is required before a workflow can be exported.

┆Issue is synchronized with this Jira Story ┆fixVersions: Dockstore 2.X ┆friendlyId: DOCK-1922 ┆sprint: SEAB 79- Gary (the snail) ┆taskType: Story

[denis-yuen]

I think it makes sense to wait and let people know about the workaround.

[unito-bot]

➤ Kathy Tran commented:

It looks like there’s no feature that we can take advantage of currently. Our problem is that if User A requests a DOI for version 1, User B cannot request a DOI for version 2 because we try to create a new version DOI from User A’s DOI, but User B doesn’t not have edit/write permissions to User A’s DOI.

Zenodo communities look like a promising solution. Zenodo communities are a way to group uploads and a curator must approve or reject an upload to the community. From my testing, only the person that owns the upload can edit it or create a new version for it. The creator cannot edit or create a new version for uploads that are part of the community unless they own the upload. Right now, there’s only one curator per community.

https://github.com/zenodo/zenodo/issues/810#issuecomment-753917462 ( https://github.com/zenodo/zenodo/issues/810#issuecomment-753917462|smart-link ) doesn’t seem to be ready yet from my testing. Their roadmap ( https://inveniosoftware.org/products/rdm/roadmap/ ) indicates that it’s currently being worked on (communities REST API and UI) and I can see work being done in this repo https://github.com/inveniosoftware/invenio-communities ( https://github.com/inveniosoftware/invenio-communities|smart-link ) . Their next production-ready release is scheduled for April 15 and the multiple curators support might be in there, it might not. I’m somewhat uncertain if multiple community curators would fix our problem. It really depends on whether the curator can create new versions for the uploads in the community.

A related issue is https://github.com/zenodo/zenodo/issues/151 ( https://github.com/zenodo/zenodo/issues/151|smart-link ) which could potentially solve our problem. It was supposed to be released in summer 2020 ( https://github.com/zenodo/zenodo/issues/151#issuecomment-585738162 ), but I think it’s been delayed. This comment in particular would be ideal for us: https://github.com/zenodo/zenodo/issues/151#issuecomment-380534686 ( https://github.com/zenodo/zenodo/issues/151#issuecomment-380534686 ):

{quote}Alternatively, this could be tied to Zenodo communities. Once community curation ( https://github.com/zenodo/zenodo/issues/35 ) is enabled, perhaps a deposit could just be given to the community, so that anyone who can curate the community can alter any deposit within that community.{quote}

Without hacking together our own solution, the workaround would be that only one person of the organization would be responsible for requesting DOIs. Other organization members would use the created DOIs to export to ORCID. As mentioned before, this wouldn’t be a huge deal since the organization members will likely know each other.

Denis Yuen Thoughts on whether to wait and settle with the workaround for now or create our own solution?