Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PeriodO Client not accepting all the changes made to an existing authority #323

Open
ylan1 opened this issue Jul 5, 2021 · 3 comments
Open
Assignees
Labels

Comments

@ylan1
Copy link

ylan1 commented Jul 5, 2021

A couple of weeks ago, I tried to make two changes (stop date and adding alternative labels) to the authority record (http://n2t.net/ark:/99152/p0wf3wdnm6q).
After submitting the changes, I noticed that only the alternative label field was updated, and the stop date reverted to the original, incorrect value. I tested twice, and the result was the same.

Before submitting
before

After submitting
after

Last week, I separately submitted the stop date change that did not work the first time, and it seems to have worked. So I assume that the Client currently is only accepting one field change.

@atomrab
Copy link

atomrab commented Jul 9, 2021

I merged this submission and can confirm that the submitted version included a successful end-date change.

@atomrab
Copy link

atomrab commented Oct 11, 2022

@rybesh Is this related to the problem the person who submitted the BSA periodization is having with attempts to change language and date labels? She writes:

I had to go back again several times to fix the labels because they were returning to the previous ones (when I was changing English to Modern Greek and BCE to BC) . Maybe it's just a glitch. In the end I had to work on the json file, that I downloaded and reimported as a backup file.

Will make a new issue if you think this is a different problem.

@atomrab
Copy link

atomrab commented Feb 10, 2023

@rybesh I've replicated this problem with an edit to the ArkeOpen collection, in which I edited both the start date and the source note and submitted a patch that recognized changes to both of those fields. The merged version, however, only included the change to the source notes, and dropped the change to the date. A second patch with the changed entry from the same local collection shows only the date change and merges successfully.

Without knowing how the programming works, I would hazard the guess that the change-submission or merge script only recognizes changes to the single most recently edited field, so by default only updates one value, no matter which field was edited.

@rybesh rybesh self-assigned this Feb 10, 2023
@rybesh rybesh added the bug label Feb 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants