Bug 13465 - Fields controlled by authorized values cannot be unset (Lost, damaged, not for loan status, ...)
Summary: Fields controlled by authorized values cannot be unset (Lost, damaged, not fo...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: P5 - low critical (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on: 12874
Blocks:
  Show dependency treegraph
 
Reported: 2014-12-15 12:34 UTC by Mirko Tietgen
Modified: 2016-06-21 21:37 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 13465: Fix silly regex on generating default values hash (1.50 KB, patch)
2014-12-17 09:51 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 13465: Correct the field prefix ambiguity (1.98 KB, patch)
2014-12-18 08:45 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 13465: Correct the field prefix ambiguity (2.04 KB, patch)
2014-12-18 10:45 UTC, Mirko Tietgen
Details | Diff | Splinter Review
[PASSED QA] Bug 13465: Correct the field prefix ambiguity (2.10 KB, patch)
2014-12-18 22:30 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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