Bug 13465

Summary: Fields controlled by authorized values cannot be unset (Lost, damaged, not for loan status, ...)
Product: Koha Reporter: Mirko Tietgen <mirko>
Component: CatalogingAssignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: critical    
Priority: P5 - low CC: chris, jonathan.druart, katrin.fischer, m.de.rooy, mtj, tomascohen
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 12874    
Bug Blocks:    
Attachments: Bug 13465: Fix silly regex on generating default values hash
Bug 13465: Correct the field prefix ambiguity
Bug 13465: Correct the field prefix ambiguity
[PASSED QA] Bug 13465: Correct the field prefix ambiguity

Description Mirko Tietgen 2014-12-15 12:34:51 UTC
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.
Comment 1 Katrin Fischer 2014-12-15 12:47:00 UTC
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.
Comment 2 Jonathan Druart 2014-12-17 08:31:14 UTC
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?
Comment 3 Katrin Fischer 2014-12-17 08:37:18 UTC
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
Comment 4 Jonathan Druart 2014-12-17 08:59:45 UTC
Thanks.
Related to bug 12874.
Comment 5 Jonathan Druart 2014-12-17 09:51:00 UTC Comment hidden (obsolete)
Comment 6 Mirko Tietgen 2014-12-17 20:17:02 UTC
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 ;)
Comment 7 Jonathan Druart 2014-12-18 08:45:04 UTC Comment hidden (obsolete)
Comment 8 Jonathan Druart 2014-12-18 08:51:44 UTC
(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!
Comment 9 Mirko Tietgen 2014-12-18 10:45:56 UTC Comment hidden (obsolete)
Comment 10 Katrin Fischer 2014-12-18 22:30:09 UTC
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>
Comment 11 Tomás Cohen Arazi 2014-12-19 18:06:46 UTC
Patch pushed to master.

Thanks Jonathan!
Comment 12 Chris Cormack 2014-12-19 23:30:18 UTC
Pushed to 3.18.x will be in 3.18.2
Comment 13 Mason James 2014-12-22 19:07:56 UTC
(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