-
Notifications
You must be signed in to change notification settings - Fork 16
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
Update wf_owner when non-marc authority records are updated #1589
base: develop
Are you sure you want to change the base?
Update wf_owner when non-marc authority records are updated #1589
Conversation
Make this field visible in the display page, and update it using current user field. After uptading, redirect to the display page, because if redirects to the list, the modified record is lost and not easily accessible, except via the browser history. Closes rism-digital#1584
@jenniferward should confirm if this is desired behaviour |
To clarify my slight change of the behaviour: it all starts with the current Muscat behavior (inherited from ActiveAdmin) that "remembers" the last search for each kind of record, in that case, non-marc authorities. Let's imagine that the last time you were visiting places was Brno. Later on, maybe another day, you see in any record (source, publication, person or institution) a reference to a misspelled Zaggreb. You clik on the authority record for Zaggreb to correct it and, after saving it, suddenly you find a list of cities alphabetically around Brno. Moreover, if your finger also pressed a key near the return one, you may not be sure that Zagreb had been effectively corrected. I have been bitten by this behaviour. This slight change means that after correcting a place, subject, title or liturgical feast, Muscat now shows the record that you have just corrected, so you can check if your correction was right or not. |
Does this change the owner every time a record is saved? For the search problem, in the current devel branch Muscat is tab independent so searches should not cross tabs anymore. |
Maybe we can add two links like in the MARC editor, "save and close" and "Save and stay here"? |
I'm not sure to fully understand your question, due to the links between bibliographic and authority records. This patch just corrects the owner of the non-marc authority record (places, subjects, titles and liturgical feasts) you have just updated. Depending on how is well received by you, I have further proposals, some of them already implemented in my installations, but I wanted to start with a simple case.
That's good news. However, does it remember "old" searches like the Brno vs Zagreb scenario I've described above? Because I think that seeing what you have already corrected is a good thing on itself. |
The "Save and stay here" in the MARC records means that you don't leave the editor. In non-Marc records, the current behavior is to leave the record and go to the list of the last searched authority of the current type. I'd prefer not to add more buttons, because each of them means a doubt, a question and time resolving it. |
I agree with the new behavior: after you save a non-MARC authority, you should be taken to the full record view, not the list. "Save and close" should be the same across Muscat - whether an element is MARC or not shouldn't make a difference in terms of this behavior. Many thanks @fjorba ! |
In case this is relevant: I don't see owners for Standard Titles (https://muscat-test.rism.info/admin/standard_titles/50359392). |
Yes, this is also true: when authority records are created (at least) via importing bibliographic ones (or related authority), those newly created do not have owner. I was waiting the outcome of this PR to open a new issue or discussion asking about ownership of records, but I prefer not to complicate this simple patch. |
I finally had a moment to look at this - seems ok to me, auth files can be edited only by editors right? |
Catalogers can edit the authority records they are the owner of (generally the ones they created). |
Make this field visible in the display page, and update it using current user field. After uptading, redirect to the display page, because if redirects to the list, the modified record is lost and not easily accessible, except via the browser history.
Closes #1584