You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@jonathannoah reported an issue with one of our script commands, move_publish. Here, it was not able to find the folder. Looking at the curation metadata, we noticed that author list changed such that the original first author was not listed as first. This was even though the published metadata shows the correct author information.
This occurred twice with two published deposits, #14477715 and 14481795.
Note that this is not a bug on our end, it's Figshare API responses. We contacted Figshare and they say:
We have managed to reproduce the issue and we believe that the author order get flipped in curation approved entries based on ascending order of the author IDs.
I have forwarded this to our development team for further investigation and as soon as we have a fix in place we will let you know.
For now we are waiting on a solution; however, it's worth investigating to see what other datasets were impacted. This should be straightforward by retrieving the public metadata and comparing it to the curation metadata.
Reproduction Steps
After publishing the data through the Figshare UI
Perform a move_publish. This will gather the metadata and it would be easily identifiable
Outputted Messages
Version information
LD_Cool-P version: N/A
Expected behavior
Implemented in: TBD
The text was updated successfully, but these errors were encountered:
Describe the bug
@jonathannoah reported an issue with one of our script commands,
move_publish
. Here, it was not able to find the folder. Looking at the curation metadata, we noticed that author list changed such that the original first author was not listed as first. This was even though the published metadata shows the correct author information.This occurred twice with two published deposits, #14477715 and 14481795.
Note that this is not a bug on our end, it's Figshare API responses. We contacted Figshare and they say:
For now we are waiting on a solution; however, it's worth investigating to see what other datasets were impacted. This should be straightforward by retrieving the public metadata and comparing it to the curation metadata.
Reproduction Steps
move_publish
. This will gather the metadata and it would be easily identifiableOutputted Messages
Version information
Expected behavior
Implemented in: TBD
The text was updated successfully, but these errors were encountered: