If you link an authorised value to a framework after you have done data entry on the same field, editing the record with the new authorised value drop down, and not filling it in will lose the data in the field. To reproduce: choose a free entry MARC field and add a record with some data in that field. create an authorised value category and link it to that field in a framework edit your record with the authorised value link now defined, do not select an authorised value from the field, and save it note that the data for that field is now gone. I have only heard this reported on 16.05, but it very well may be in Master. It would pay to check.
Created attachment 67385 [details] [review] Bug 19361 - Display the value of a MARC field in dropdown box after it is linked to an authorised value This patch displays the previously entered input of a MARC subfield (inputted before an authorised value was linked to the MARC field) in the new authorised value dropdown so that it can be resubmitted and not lost from the database. Test plan: 1. Create a record and write a value into the Edition 942$e MARC field and submit form 2. Create a new authorised value category and link it to the same Edition MARC subfield 3. Load the MARC record again and notice that the Edition field is now an empty dropdown box. Also for future reference in this test note the values in the 942$2 and 942$c dropdown boxes 4. Query the biblio_metadata table with the biblionumber of the record that you created in step 1 and notice that the value you entered in step 1 into the Edition (<subfield_code="e") still exists 5. Submit the form 6. Repeat step 4 and notice that <subfield_code="e" line no longer exists as the existing data for the edition MARC subfield has been lost by linking a new authorised value category to the edition subfield 7. Apply patch 8. Repeat steps 1 but this time write a value into the Classification part MARC subfield 9. Repeat step 2 but link the new authorised value category to the Classification part MARC subfield 10. Repeat step 3 and notice that the value you wrote into the Classification part subfield is displayed in the dropdown box (selected by default), along with a message in brackets informing you that this value is not an authorised value 11. Note that the other dropdown boxes 942$2 and 942$c both display the same values as in step 3 12. Submit the form 13. Query the biblio_metadata table and notice that the <subfield_code="h" line still exists with the value you entered and that was shown in the dropdown box As this is quite a complex test plan, I have done my best to keep it as simple as possible, however if you are confused please let me know and I am more than happy to clarify Sponsored-By: Catalyst IT
Created attachment 67652 [details] screenshot of MARC during step 10
I just attached a screen shot of the result I get at step 10. It doesn't seem to have changed since I can see what i first wrote in the field inside the dropdown. Also, (<subfield_code="e") line is absent from the database after submitting the form...
meant to write "I can't see what I first wrote in the field..."
Created attachment 67655 [details] Screenshot of success!
Hi Alex, I tested your patch both in 16.05 ans in the master. It didn't work in 16.05. I didn't see the old value as the default in the drop down menu. I think it has to do with the db structure that is different. In 16.05 there is no biblio_metadata. The MARC information is stored in the biblioitems table in the marc field. In the master, everything work as you described it. I attached a screenshot of the field with the value followed by the mention that it is not authorized. However, I would change the phrasing to "This is a previously entered..." instead of "previous".
Created attachment 67657 [details] [review] Bug 19361 - Display the value of a MARC field in dropdown box after it is linked to an authorised value This patch displays the previously entered input of a MARC subfield (inputted before an authorised value was linked to the MARC field) in the new authorised value dropdown so that it can be resubmitted and not lost from the database. Test plan: 1. Create a record and write a value into the Edition 942$e MARC field and submit form 2. Create a new authorised value category and link it to the same Edition MARC subfield 3. Load the MARC record again and notice that the Edition field is now an empty dropdown box. Also for future reference in this test note the values in the 942$2 and 942$c dropdown boxes 4. Query the biblio_metadata table with the biblionumber of the record that you created in step 1 and notice that the value you entered in step 1 into the Edition (<subfield_code="e") still exists 5. Submit the form 6. Repeat step 4 and notice that <subfield_code="e" line no longer exists as the existing data for the edition MARC subfield has been lost by linking a new authorised value category to the edition subfield 7. Apply patch 8. Repeat steps 1 but this time write a value into the Classification part MARC subfield 9. Repeat step 2 but link the new authorised value category to the Classification part MARC subfield 10. Repeat step 3 and notice that the value you wrote into the Classification part subfield is displayed in the dropdown box (selected by default), along with a message in brackets informing you that this value is not an authorised value 11. Note that the other dropdown boxes 942$2 and 942$c both display the same values as in step 3 12. Submit the form 13. Query the biblio_metadata table and notice that the <subfield_code="h" line still exists with the value you entered and that was shown in the dropdown box As this is quite a complex test plan, I have done my best to keep it as simple as possible, however if you are confused please let me know and I am more than happy to clarify Sponsored-By: Catalyst IT Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Thanks Caroline I am attaching a amendment with the new wording now
Created attachment 67658 [details] [review] Bug 19361 - Followup altered wording of the default value Sponsored-By: Catalyst IT
It's ok now!
Created attachment 67955 [details] [review] Bug 19361 - Followup altered wording of the default value Sponsored-By: Catalyst IT Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
QA: Looking here now
QA Comment: The problem described in the first comment does not really seem a problem to me. This is just what authorized values mean. The value is controlled now; and you should not be able to save another value. Note that if you change it here, why not change it in the items form or even other places? I think this exception needs more discussion/consensus. Maybe raise it on the dev list or a dev meeting. And what do librarians want here? Furthermore I would not hardcode the [% ELSIF mv.default != 'ddc' %] exception. Same thing is true when you delete a value from the auth values while still having the value in your data. Should Koha warn you for that or not allow it ?
Looking over this bug report again.
(In reply to Marcel de Rooy from comment #13) > QA Comment: > The problem described in the first comment does not really seem a problem to > me. This is just what authorized values mean. The value is controlled now; > and you should not be able to save another value. Note that if you change it > here, why not change it in the items form or even other places? > I think this exception needs more discussion/consensus. Maybe raise it on > the dev list or a dev meeting. Hmm, I figure if it's a controlled field, you shouldn't be able to save a non-controlled value, but I think the behaviour right now might be to silently delete the existing data. Flagging that the current data isn't authorized and that they must use an authorized value is probably the optimal path forward?
Many thanks David for your thoughts, much appreciated! I think you're idea of flagging that the current data is not authorised and prompt to choose another authorised value is an excellent compromise so at least the library staff member is made aware and the data is not just silently lost.
Any other/opposing thoughts anyone else?
Flagging sounds like a good idea and it should not let you save until you have resolved the issues. Sometimes it would be nice if we could allow a mix of authorised values and free text entry, like we allow for the suggestion reason in the staff interface. You can either choose from a list or do a free text entry picking "other reason". But that would definitely be a new feature and separate bug. And not sure if "Select2" supports that.
(In reply to Alex Buckley from comment #17) > Any other/opposing thoughts anyone else? A gut yor Alex, I've asked people at Bulac library, though we don't catalogue with Koha, this answer is more about modifying items. My colleagues feel it's safer to keep the old value by default and let the librarian decide what to do. So your work is seen as a better behaviour!
Thanks very much for sharing your thoughts Katrin and Nicolas, much appreciated! It sounds like the consensus is flagging that the data will be lost is the way to go. But that a nice future enhancement would be to allow librarians to choose to allow free text values in a linked field. I'll work on adding flagging alert to this patchset.
Created attachment 105848 [details] [review] [ALTERNATIVE-PATCH] Bug 19361: Add a tooltip warning if value not in AV list (This patch depends on bug 25728) When cataloguing it may happen that a previous value of a subfield is not longer in the list of AVs. Prior to this patch the value was removed. This patch suggests to display a tooltip next to the problematic subfield. If nothing is done, the value is kept. This patch work when cataloguing a bibliographic record, and adding/editing items. It could be implemented easily for authority cataloguing.
(In reply to Jonathan Druart from comment #21) > Created attachment 105848 [details] [review] [review] > [ALTERNATIVE-PATCH] Bug 19361: Add a tooltip warning if value not in AV list > > (This patch depends on bug 25728) > > When cataloguing it may happen that a previous value of a subfield is > not longer in the list of AVs. > > Prior to this patch the value was removed. > > This patch suggests to display a tooltip next to the problematic > subfield. If nothing is done, the value is kept. > > This patch work when cataloguing a bibliographic record, and > adding/editing items. > > It could be implemented easily for authority cataloguing. This is my try: https://snipboard.io/Eso74Y.jpg
Created attachment 142158 [details] [review] Bug 19361: Display unauthorized values when cataloging and add a warning This patch adds a warning and tool tip when an unauthorised vlaue is encountered during item or biblio editing, and adds the value to the list to allow preserving the value (in case the librarian is only editing another part of the record, or there is some reason to retain) To test: 1 - Edit a record in advanced cataloging editor 2 - Under settings click 'Show fields verbatim' 3 - Edit 942$c to 'HAM' or some other invalid itemtype 4 - Save record 5 - sudo koha-mysql kohadev UPDATE items SET location = 'HAM' WHERE biblionumber = {biblionumber from above} 6 - Edit the biblio and items, confirm the HAM value shows in dropdowns
Created attachment 142159 [details] [review] Bug 19361: Fix advanced cataloging editor dropdowns
Trying to revive this - feel free to take back if you want Alex
Created attachment 142208 [details] [review] Bug 19361: Display unauthorized values when cataloging and add a warning This patch adds a warning and tool tip when an unauthorised vlaue is encountered during item or biblio editing, and adds the value to the list to allow preserving the value (in case the librarian is only editing another part of the record, or there is some reason to retain) To test: 1 - Edit a record in advanced cataloging editor 2 - Under settings click 'Show fields verbatim' 3 - Edit 942$c to 'HAM' or some other invalid itemtype 4 - Save record 5 - sudo koha-mysql kohadev UPDATE items SET location = 'HAM' WHERE biblionumber = {biblionumber from above} 6 - Edit the biblio and items, confirm the HAM value shows in dropdowns Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Created attachment 142209 [details] [review] Bug 19361: Fix advanced cataloging editor dropdowns Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
FAIL koha-tmpl/intranet-tmpl/prog/en/includes/cateditor-ui.inc OK filters FAIL forbidden patterns forbidden pattern: simple-quote string (line 125)
Having a look here - I'll fix the QA script in a follow-up patch
Created attachment 148377 [details] [review] Bug 19361: Display unauthorized values when cataloging and add a warning This patch adds a warning and tool tip when an unauthorised vlaue is encountered during item or biblio editing, and adds the value to the list to allow preserving the value (in case the librarian is only editing another part of the record, or there is some reason to retain) To test: 1 - Edit a record in advanced cataloging editor 2 - Under settings click 'Show fields verbatim' 3 - Edit 942$c to 'HAM' or some other invalid itemtype 4 - Save record 5 - sudo koha-mysql kohadev UPDATE items SET location = 'HAM' WHERE biblionumber = {biblionumber from above} 6 - Edit the biblio and items, confirm the HAM value shows in dropdowns Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Created attachment 148378 [details] [review] Bug 19361: Fix advanced cataloging editor dropdowns Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Created attachment 148379 [details] [review] Bug 19361: (QA follow-up) Make sure translatable string is wrapped in double quotes This fixes the QA script complaint: FAIL koha-tmpl/intranet-tmpl/prog/en/includes/cateditor-ui.inc FAIL forbidden patterns forbidden pattern: simple-quote string (line 125) Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Created attachment 148380 [details] [review] Bug 19361: (QA follow-up) Make sure "Not an authorised value" appears in the pull down This is to make sure that the small icon with the additional tooltip style explanation is not as easily missed. Also updates text slightly: * Pull downs: "X (Not an authorised value)" * Tooltip: "The current value X is not configured for the authorised value category controlling this subfield" Switches from exclamation triangle to the more "alerting" exclamation-triangle :) Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Pushed to master for 23.05. Nice work everyone, thanks!
Nice work everyone! Pushed to stable for 22.11.x