Skip to content

fix(config): disallow versioning for external DOIs - #973

Open
TahaKhan998 wants to merge 1 commit into
CERNDocumentServer:masterfrom
TahaKhan998:fix/issue-943-doi-on-latest-version
Open

TahaKhan998 wants to merge 1 commit into
CERNDocumentServer:masterfrom
TahaKhan998:fix/issue-943-doi-on-latest-version

Conversation

@TahaKhan998

@TahaKhan998 TahaKhan998 commented Sep 16, 2026 •

Copy link
Copy Markdown

closes #943

same as zenodo, curators shouldn't be able to create a new version of a record that has an external DOI. set RDM_ALLOW_EXTERNAL_DOI_VERSIONING = False.

return (source or "").lower() in _ARXIV_SOURCES


def keep_shared_doi_on_latest(latest_entry, versions):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's discuss this IRL with the team

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more context - this is because of the external DOIs not being displayed on the latest version and if harvester adds a new version, the DOI will not be displayed on the latest
suggested approach: not to create versions for external DOIs, both in migration and harvester
ON HOLD

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

discussed:
when we are updating records with external DOIs, we should keep one version only (check how zenodo implements this - the feature is already there, it is a question of setting the permissions correctly)

@TahaKhan998
TahaKhan998 force-pushed the fix/issue-943-doi-on-latest-version branch 2 times, most recently from 5b5ade0 to 8b2801f Compare September 24, 2026 14:05
@TahaKhan998 TahaKhan998 changed the title fix(harvester): keep shared DOI on the latest version fix(config): disallow versioning for external DOIs Sep 24, 2026
@TahaKhan998

Copy link
Copy Markdown
Author

can_edit does not use this config, so yes curators can still edit a record after they publish it. They just cannot create a new version when the record has an external DOI, because that goes through can_new_version, which is what this config controls.
image

@TahaKhan998

Copy link
Copy Markdown
Author

Updating files needs a new version. This config blocks new version for records with an external DOI, so a curator cannot add or delete files on those records. They can still edit the metadata.

@TahaKhan998
TahaKhan998 force-pushed the fix/issue-943-doi-on-latest-version branch from 8330746 to 5d7e0b6 Compare October 1, 2026 11:50
@TahaKhan998
TahaKhan998 force-pushed the fix/issue-943-doi-on-latest-version branch from 5d7e0b6 to a0200f7 Compare October 1, 2026 11:59
Administration(),
InspireHarvester(),
SystemProcess(),
IfExternalDOIRecord(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might be more complex than this, see the file modification grace period

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the scope of this PR I think it will not be?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

depends what this line mean.... anyway my point is, we need to document and know in the case of external DOIs what is the file modification policy:

  • do we always allow file modifications?
  • is there a file modification grace period and then it is blocked?

this is more essential now that we have blocked newer versions for the external DOIs.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

harvester - validate harvests for multiple document types

3 participants