edit: if record already has DOI, UI should reflect that correctly

[tmorrell]

Describe the bug

If you edit the metadata for a record where InvenioRDM has minted a DOI, the "Do you already have a DOI for this upload?" field says No. This doesn't make sense, since the record has a DOI. The deposit form correctly doesn't allow you to change the DOI or answer, so this is purely a UI issue.

Steps to Reproduce

1. Create a record with a DOI
2. Click on Edit
3. Look at the DOI section

Expected behavior

There should not be confusing DOI status information when editing record metadata. The help text is also confusing. It probably makes sense to remove the DOI question entirely and change the help text to something like "This record has been assigned a DOI, which cannot be changed."

Screenshots (if applicable)

[github-actions[bot]]

This issue was automatically marked as stale.

[github-actions[bot]]

This issue was automatically marked as stale.

[github-actions[bot]]

This issue was automatically marked as stale.

[fenekku]

:wave: @tmorrell @chriz-uniba You both seemed to be interested in improvements to the DOI component, so I wanted to share this with you.

I've created a modified version of the current DOI component for us at NU and thought here would be a good place to get your feedback on it. (I didn't really know of a better place to gather feedback from a small group so I am doing it here. If you know a better place let me know - the rapids of Discord would probably drown it).

Our criteria at Northwestern for the component were:

• For draft of unpublished record

  • [x] defaults to No
  • [x] can toggle between Yes and No
  • [x] Yes radio, shows text input and sets it in the form
  • [x] No radio, hides text input and removes it from the form
  • [x] Yes radio + filled text input + click No + click Yes again, re-instate what was filled in the text input

• For draft of published record

  • [x] cannot toggle between Yes and No
  • [x] Yes radio + external (unmanaged), DOI input box is changeable (to fix a typo; this is how InvenioRDM has it)
  • [x] Yes radio + internal (managed), DOI input box is unchangeable (fixes this issue)

• [x] Loading a record, loads its saved values

  • [x] in particular, managed DOI shows up as "already have a DOI"

• When error with DOI input field,

  • [x] hightlight the top DOI label and the input box
  • [x] show error label

• [x] No "Get DOI now button" because it proved confusing overall: it doesn't "get a DOI now" from datacite anyway.

The resulting screenshots look like:

TODO in the future:

• [ ] Accessibility (contrast + label)
• Yes radio + managed (i.e. this came from API - don't tell anyone :shushing_face: ), input box deleteable
  • [ ] deleting leads to Yes and empty input and external provider
  • [ ] No radio, saves special case for reinstatement if yes clicked again

To achieve this I overrode the PIDField (and I mean completely). I didn't use the CustomPIDField because it's not exported and didn't try to copy-and-tweak it because its abstraction made it harder for me to change (and I suspect was why it had a couple of glitches :smile: ).

Anyway I wanted to gauge interest and see how we could proceed. Because it's a larger change it may be more challenging to get in the mainline.

[tmorrell]

@fenekku This looks really clean and like a great improvement. However, I am missing the "Get DOI now" button for a couple of reasons

• Changing functionality is hard to get merged. The button does let folks know they can see their DOI before publishing.
• We're actually using the button functionally in our publications repository. We had to make DOI not required because we have some content that we don't want to assign DOIs to (e.g. patents) and we have multiple records with the same external DOI (publishers using one DOI for an entire conference proceeding). When you make DOI optional, the get DOI button acts as a positive signal that a local DOI should be assigned to this record.

So my thought would be to have the "get DOI" button as an option to the right of No. Otherwise the functionality works much better than the current confusing version.

[fenekku]

Ah yes. I think that focuses the discussion on how to configure an InvenioRDM component from an instance and how to share custom components in the InvenioRDM ecosystem.

Overriding via react-overridable is essentially the way right now. In mapping.js, the original component is imported and wrapped in another. The original components' props are set to what is needed and the parent component is set to override. It's a little intrusive, but it does allow an instance to really configure.

I guess the alternative could be to have InvenioRDM components take a config props derived from the backend (from some settings really). Then an instance would only have to change some settings to populate that config props appropriately and have it in turn configure pre-existing components... I tend to be less attracted by that solution, because ultimately it's already possible by override and the configuration approach tends to make the resulting component very abstract to the point it becomes hard to understand what is going on. However, the configuration approach does cut down on some boilerplate that each instance would have to write in some cases...

To use a component shared by a third-party, there'd have to be better support for that. Right now an installer would have to manually add the {{ webpack['component-key'] }} to their deposit page html I think... Something to bring up to people more familiar with webpack/assets building.

Thanks!

[chriz-uniba]

hi,

thanks a lot for tackling this!

I like your approach.

• For draft of unpublished record
  • Yes radio + filled text input + click No + click Yes again
  • I saw some glitches (with Zoom, I think) with a similiar behaviour
  • so please make sure for the following scenario:
    • Yes radio + filled text input + click No
    • that No was the last answer, even though you have somewhere laying around the "filled text input" - please do not use it ;)
• "I arelady have a DOI"
  • https://github.com/inveniosoftware/invenio-app-rdm/issues/2129
  • maybe a wording issue
• "Get DOI now"
  • I think also this one is a wording issue
  • I'm pretty sure, that this was discussed before (likely on discord, but I cannot find it anymore)
  • Lars mentioned, that having the DOI makes sense to add it to a README file etc. but it does not mean, that the DOI is really minted
  • I think this is a general problem, since we had to discard records for several issues and the wording here implies, that you minted a doi
  • Maybe something like "Preview DOI" and a good hint "When publishing this record, this will be its DOI."

[fenekku]

that No was the last answer, even though you have somewhere laying around the "filled text input" - please do not use it ;)

Yes, I remember seeing this issue in the past somewhere. Here the form is explicitly altered to remove the Yes value, so we should be good. :+1:

"I arelady have a DOI" [...] wording issue

We haven't encountered the issue directly yet, so we don't know what kind of wording would work. We'll keep our eye on it though.

"Get DOI now"

So far this is my understanding of this whole thing:

• InvenioRDM doesn't mint a DOI with Datacite for drafts, because drafts are created very often in the system and we don't want to cost the instance unnecessary Datacite service fees (See Dan's comment and Datacite's fee model). A DOI is really only needed for something published anyway.

• "Get DOI now" is actually a specific case of a more general functionality applicable to any PID. The idea was to allow any PID to be potentially reserved internally before publication, so the depositor has it on hand (and then that PID can't be taken up by other record). That DOI feature has been implemented from that lens even though for DOI it is redundant to some extent. The draft's pid value is used as the DOI identifier, so it can never be taken up by another record and we already know the pid value once the record is saved once.

• Although saving an internal PID entry for the DOI, reserves it locally, it doesn't externally. For READMEs and such it makes sense, but for wider distribution/publication it doesn't. In that case, the depositor will want to publish the record. Explaining this to depositors is hard.

What we are toying with is to provide a text next to the "No" option when the record is saved that says something like: "Once your upload is published, its DOI will be 10.XYZ/1234-abcd". This can be done for DOI confidently without additional API calls.

Thanks!