Bug report: Overwriting DOI with a non-DOI number
I observe a strange behaviour that Zotero overwrites a DOI after creating an item.
Steps to reproduce:
1) Import the following article with this DOI with the Zotero Connector: 10.1209/0295-5075/110/10001
2) The correct DOI appears after import.
3) But after some time, the DOI is replaced automatically (no input from me) to: 2020031311332586.
[Further details below if needed.]
Using Zotero 6.0.19-beta.1+26847c672 on Windows 10, all add-ons disabled.
The Debug ID is D830359738.
In this Debug ID process, I have tested the following DOIs:
10.1209/0295-5075/110/10001 -> 2020031311332586
10.1209/0295-5075/110/46002 -> 2020031311343294
10.1209/0295-5075/110/47010 -> 2020031311343107
10.1209/0295-5075/110/40002 -> 2020031311350371
I did not understand what triggers the replacement of the DOI, as it was switched at different times for each item.
I have noticed this behaviour only for the papers in this issue of the journal.
It does not seem to be related to the Zotero Connector, as I was able to trigger the same DOI replacement simply by entering manually the DOI in an empty Journal Article item:
1) Create a new empty Journal Article item
2) Enter the following DOI: 10.1209/0295-5075/110/10001
3) Restart Zotero
5) At the end of the sync, the DOI is replaced by: 2020031311332586
But somehow, these steps were less reproducible.
If I re-enter the correct DOIs after restart and sync, they seem to remain stable. So the DOI replacement seems to be related to newly added items.
This seems to be a very narrow bug report, but I am quite surprised why Zotero would change perfectly valid DOIs.
Steps to reproduce:
1) Import the following article with this DOI with the Zotero Connector: 10.1209/0295-5075/110/10001
2) The correct DOI appears after import.
3) But after some time, the DOI is replaced automatically (no input from me) to: 2020031311332586.
[Further details below if needed.]
Using Zotero 6.0.19-beta.1+26847c672 on Windows 10, all add-ons disabled.
The Debug ID is D830359738.
In this Debug ID process, I have tested the following DOIs:
10.1209/0295-5075/110/10001 -> 2020031311332586
10.1209/0295-5075/110/46002 -> 2020031311343294
10.1209/0295-5075/110/47010 -> 2020031311343107
10.1209/0295-5075/110/40002 -> 2020031311350371
I did not understand what triggers the replacement of the DOI, as it was switched at different times for each item.
I have noticed this behaviour only for the papers in this issue of the journal.
It does not seem to be related to the Zotero Connector, as I was able to trigger the same DOI replacement simply by entering manually the DOI in an empty Journal Article item:
1) Create a new empty Journal Article item
2) Enter the following DOI: 10.1209/0295-5075/110/10001
3) Restart Zotero
5) At the end of the sync, the DOI is replaced by: 2020031311332586
But somehow, these steps were less reproducible.
If I re-enter the correct DOIs after restart and sync, they seem to remain stable. So the DOI replacement seems to be related to newly added items.
This seems to be a very narrow bug report, but I am quite surprised why Zotero would change perfectly valid DOIs.
You have two clients syncing, and the item appears to have been modified remotely immediately after it was uploaded by this computer.
2020031311332586
→2020-03-13 11:33:25.86
. I don't think they're from us.)The problem indeed goes away when I disable the DOI Manager plugin on the other computer. I will report it on the GitHub of the plugin.
https://api.crossref.org/v1/works/10.1209/0295-5075/110/40002
-- date-time "2020-03-13T12:22:22Z"
though for some reason not precisely. Given how limited this is, I almost wonder if this is a CrossRef bug, but @bwiernik (author of the DOI manager) would be able to confirm that more quickly