For this purpose we have the fix clean_preselects(), which removes the abstract field if it detects that there is no content in the text field, but only the preselected language field - which means that there is no abstract.
The same goes for related_material.link. It's a combined field of a relation and a url and the relation is always preselected. The fix removes it if there is not also content in the url field when the record is submitted.

For all other repeatable fields we have the vacuum() fix, which removes empty arrays, empty hashes and empty strings before saving/returning the record.

How exactly would you separate the add button from the input field? And what would change in the form data when doing this?

Repeated form fields (especially the complex ones) like abstract generate useless array entries in the record.

The reason for this that always one element for input (e.g. combination of "language" and "text") is shown.

This way unwanted empty values slip in, and one cannot distinguish anymore between wanted and unwanted empty values..

Why no separate the "add" button from the input element, and leave the "remove" element with the element?

Now you have

<input> - +

Coverage remained the same at 81.384% when pulling 59c9eaf71e25b9bedbb31f0cc92fe169ef8a4e8d on pr/typo_in_arxiv_mapping_fix into ec3e4ebb15a8da54834fff2cf994b244d878142e on dev.

Arxiv ID missing in arXiv imports.

Should be r.external_id.arxiv instead of external_id.arxiv

Due to the crossref DOI import getting slower and slower, this PR introduces a new import using a different crossref API.

Crossref has changed their APIs to be faster and more reliable if services using the APIs identify themselves correctly, so they can be contacted in case of any problems resulting from their use of the API. Anyone refusing to identify themselves (as we have been doing - unknowingly) will only have access to a slow and often overloaded server pool running the APIs.

The new crossref import for LibreCat not only implements (at least the most basic) identification via an email address - and thus is waaay faster -, but also switches from REST to XML API, which provides far better and more detailed metadata for each record.

Important notes:

1. Make sure to set a real, working and somehow identifying email address in catmandu.local.yml -> admin_email. You should be reachable there, it's only fair.
2. The fixes/lookup/cr_type_mapping.fix is kind of a wild guess on my account. I have not been able to find a reliable list of publication types in use at crossref so far. This mapping, however, works for the types coming into LibreCat from crossref.
3. The method of first determining the agency (crossref or datacite) for a DOI and then requesting the metadata is no longer usable. The API used for the agency check is the same slow REST API we have been using all along and it will basically kill a request through timeout before it has even happened. The new way to identify the agency is to request a DOI from crossref directly. The resulting XML (there will always be one) will either contain status="resolved" or status="unresolved". In the latter case we then request the DOI from datacite
4. There was quite some pushing and shoving involved in getting the XML into hash format and into the fixer. Crossref has some (to me) strange xml tags in there that needed to be replaced in order to be read correctly. These changes are done by regex in the fetch sub in lib/LibreCat/FetchRecord/crossref.pm. Any suggestions for a better/nicer/faster/more beautiful way of dealing with this XML are welcome!

E.g. we got a request to reindex the user model (for some internal reason).

Coverage remained the same at 81.384% when pulling f73e4811682b9aac4d3d131a7a606b74226525f5 on pr/error_message_correction into f39acd2cd5c04e9a5a538d0ead43dfd4ae85f4ba on dev.

Just a correction of an error message.

And I just found out that the single-sign-on modules (Plack::Auth::SSO::*) don't work well if your session cookie has setting SameSite: Strict:

• access /auth/orcid
• /auth/orcid adds csrf_token (for cross site request forgery) to your session, and redirect to orcid
• orcid redirects back to /auth/orcid, but .. without a cookie, so it thinks that this is a CSRF attack

Reason: combination redirect + samesite:Strict does not work..