Add Zenodo file source template

[davelopez]

Depends on #19619 (to avoid conflicts, I will keep it as draft and rebase after the other one is merged)

This adds a new template similar to the one for Invenio but in this case for Zenodo. In theory, you can create a Zenodo File Source instance by using the Invenio one, and everything will work the same, but having its own template allows using it directly in the dedicated export section for histories as we can identify it by its type:

This also avoids having to set up a regular server-wide file source for Zenodo and makes the user experience more consistent by having all their file source instances managed in the same place.

The template interface is pretty similar to the one for Invenio but the server URL is assumed to be https://zenodo.org/

In addition, it includes a fix for Invenio-based instances (like Zenodo) that use numbers for the record identifiers in 1aa8187. It doesn't need a backport because the breaking changes are in dev.

How to test the changes?

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[kysrpex]

It's likely safe to assume we all agree that the use case

makes the user experience more consistent by having all their file source instances managed in the same place

makes great sense. I am wondering though if we are abusing the file source templates to this end.

There is just one Zenodo (https://zenodo.org/) that is the same for everyone (no private data besides draft records). This is precisely the situation that justifies a server-wide file source.

I am relatively new to the project, so I am not sure, but if there is a benefit of having server-wide file sources it must have to do with the URIs.

A Uniform Resource Identifier (URI), formerly Universal Resource Identifier, is a unique sequence of characters that identifies an abstract or physical resource, [1] such as resources on a webpage, mail address, phone number, [2] books, real-world objects such as people and places, concepts

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

The first thing that comes to mind is caching, and I am sure there may be other benefits I am overlooking related to interoperability and accessibility.

My point is, if we merge a file source template for Zenodo into the Galaxy Project, then we are somehow invalidating the use-case of server-wide file sources (and thus there would be no point in having code that backs it).

Maybe what is needed are UI changes. Maybe rather than like this

the option should read "Manage File Sources", "Configure locations to import files from and export files to." and show predefined file sources that cannot be deleted and just configured (but maybe can be hidden), of course still keeping the ability to add and delete file sources when it makes sense.

[kysrpex]

// Prioritize the one provided by the user in case there are multiple

I would consider opening a separate PR to prioritize the one provided by the user and in this PR keep things as they are (use the server-wide one if it exists, do not even show to Zenodo tab if it does not exist). Meanwhile people can choose their customized ones via the "to RDM repository tab".

I am suggesting this because looking at the UI I recognize two extra tricky points:

• the link to the user preferences page should point to the file source config, for example https://usegalaxy.eu/file_source_instances/2f666d94-802a-422e-9139-462fde6d5bf8/edit
• if the name of the file source is not shown when there are multiple Zenodo file sources and one of the user-defined ones is prioritized; you do not know where the files are going

[davelopez]

Thank you! Those are 2 really good points that I completely overlooked 😅

But I think I can fix them as part of this PR since they are very dependent on this.

[davelopez]

My point is, if we merge a file source template for Zenodo into the Galaxy Project, then we are somehow invalidating the use-case of server-wide file sources (and thus there would be no point in having code that backs it).

@kysrpex I 100% agree, your concerns are exactly the ones I had before creating the template 😆

But I think the main advantage of having both "flavors" server-wide and user-defined plugins is flexibility.

Some admins (or Galaxy instances) might decide to provide server-wide access to Zenodo to all their users, while others don't want to "overwhelm" the list of file sources available to their users while letting them set up what is really meaningful for them.
So, in summary, there are clear advantages and disadvantages to each way of handling file sources and I think is good to have the flexibility for each instance to handle it in the best interest of their users.