In item cataloguing, if you set a field controlled by an authorized value, changing it back to '<empty>' does not work. The field cannot be reset.
I confirmed the bug in our 3.18.1 database - you can't unset not for loan, damaged or smilar values once you have set them.
Could you please give more detail, I don't reproduce (but not sure to understand how to reproduce). Does the problem still exist on master?
To test: - edit an item, set a status that is controlled by an authorized value examples tested: damaged, not for loan - check the status saved correctly - edit the item again, try to reset the status to empty - verify the item is saved, but the status remains
Thanks. Related to bug 12874.
Created attachment 34478 [details] [review] Bug 13465: Fix silly regex on generating default values hash This is introduced by Bug 12874. Without this patch, it's not possible to clear (set to an empty string) an item field. This appended for field linked to an AV list but even if it's not. The regex tried to prefix 'my_field' with 'items.' to have 'items.my_field'. It wanted to take care of the case where the prefix already exists (Actually only 1: 'items.cn_source'). The regex is changed to: "add the prefix only if the string does not contain a dot". Test plan: - edit an item, set a status that is controlled by an authorized value examples tested: damaged, not for loan - check the status saved correctly - edit the item again, reset the status to empty - check the status saved correctly
With this patch applied, situation is worse. I can't save most fields. »damaged« does stay when set, other fields forget/ delete the value on save. But deleting a value that has been set before applying the patch works ;)
Created attachment 34508 [details] [review] Bug 13465: Correct the field prefix ambiguity This is introduced by Bug 12874. Without this patch, it's not possible to clear (set to an empty string) an item field. This appended for field linked to an AV list but even if it's not. The regex tried to prefix 'my_field' with 'items.' to have 'items.my_field'. It wanted to take care of the case where the prefix already exists (Actually only 1: 'items.cn_source'). The regex is changed to: "add the prefix only if the string does not contain a dot". Moreover an ambiguity existed on the prefix: in marc_subfield_structure, the kohafield is prefixed, but not in the key of the hash sent to ModItemFromMarc. Test plan: - edit an item, set a status that is controlled by an authorized value examples tested: damaged, not for loan - check the status saved correctly - edit the item again, reset the status to empty - check the status saved correctly - edit the item again, reset fields, edit fields - check the fields saved correctly
(In reply to Mirko Tietgen from comment #6) > With this patch applied, situation is worse. I can't save most fields. > »damaged« does stay when set, other fields forget/ delete the value on save. > > But deleting a value that has been set before applying the patch works ;) Sorry, Mirko, it's was a quick fix and I did not test it deeply. This one should be better. Thanks for testing!
Created attachment 34511 [details] [review] Bug 13465: Correct the field prefix ambiguity This is introduced by Bug 12874. Without this patch, it's not possible to clear (set to an empty string) an item field. This appended for field linked to an AV list but even if it's not. The regex tried to prefix 'my_field' with 'items.' to have 'items.my_field'. It wanted to take care of the case where the prefix already exists (Actually only 1: 'items.cn_source'). The regex is changed to: "add the prefix only if the string does not contain a dot". Moreover an ambiguity existed on the prefix: in marc_subfield_structure, the kohafield is prefixed, but not in the key of the hash sent to ModItemFromMarc. Test plan: - edit an item, set a status that is controlled by an authorized value examples tested: damaged, not for loan - check the status saved correctly - edit the item again, reset the status to empty - check the status saved correctly - edit the item again, reset fields, edit fields - check the fields saved correctly Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Created attachment 34519 [details] [review] [PASSED QA] Bug 13465: Correct the field prefix ambiguity This is introduced by Bug 12874. Without this patch, it's not possible to clear (set to an empty string) an item field. This appended for field linked to an AV list but even if it's not. The regex tried to prefix 'my_field' with 'items.' to have 'items.my_field'. It wanted to take care of the case where the prefix already exists (Actually only 1: 'items.cn_source'). The regex is changed to: "add the prefix only if the string does not contain a dot". Moreover an ambiguity existed on the prefix: in marc_subfield_structure, the kohafield is prefixed, but not in the key of the hash sent to ModItemFromMarc. Test plan: - edit an item, set a status that is controlled by an authorized value examples tested: damaged, not for loan - check the status saved correctly - edit the item again, reset the status to empty - check the status saved correctly - edit the item again, reset fields, edit fields - check the fields saved correctly Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Patch pushed to master. Thanks Jonathan!
Pushed to 3.18.x will be in 3.18.2
(In reply to Chris Cormack from comment #12) > Pushed to 3.18.x will be in 3.18.2 skipping patch for 3.16.x