See bug 18355.
(In reply to Katrin Fischer from bug 21010 comment #6) > (In reply to Jonathan Druart from bug 21010 comment #5) > > Bug 21466 - Data inconsistencies - items.location values must have a > > corresponding authorised value > > What if they are not mapped to LOC? I think I remember patches to display as > is in this case a while ago (Biblibre?) The mapping for items.location, depending on the framework, must be used.
Created attachment 80746 [details] [review] Bug 21466: Search for items.location inconsistencies
I am wondering if we should not be more generic and search for any item's attribute that is mapped to a koha field, linked to an authorised value category but without a corresponding value. That would catch itemlost, damaged, notforloan, restricted, etc. as well
(In reply to Jonathan Druart from comment #3) > I am wondering if we should not be more generic and search for any item's > attribute that is mapped to a koha field, linked to an authorised value > category but without a corresponding value. > > That would catch itemlost, damaged, notforloan, restricted, etc. as well Sounds good to me. We probably would have to check the frameworks too?
Created attachment 86118 [details] [review] Bug 21466: Catch any values that should be defined in the AV but are not Let's expand the idea of the first patch to catch the wrong values for any others AV.
Created attachment 95773 [details] [review] Bug 21466: Search for items.location inconsistencies Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 95774 [details] [review] Bug 21466: Catch any values that should be defined in the AV but are not Let's expand the idea of the first patch to catch the wrong values for any others AV. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Works as expected and it a useful addition.. Signing off
It would be good to get this into 19.11.01, it sohuld have been in .00 really, but it got stuck awaiting QA
This has languished long enough.. Passing QA.
Nice work everyone! Pushed to master for 20.05
I found a bug in this one. I am working on it.
Created attachment 98062 [details] [review] Bug 21466: Keep all AVs for a given framework There was a major (and silly) issue in the previous version, only one AV was kept as we erased the hash value at the end of each iteration: $invalid_locations_per_framework->{$framework->frameworkcode } = { items => $items, av_category => $mss->authorised_value, kohafield => $kohafield };
Created attachment 98063 [details] [review] Bug 21466: Keep all AVs for a given framework There was a major (and silly) issue in the previous version, only one AV was kept as we erased the hash value at the end of each iteration: $invalid_locations_per_framework->{$framework->frameworkcode } = { items => $items, av_category => $mss->authorised_value, kohafield => $kohafield };
See also https://gitlab.com/koha-community/koha-misc4dev/-/merge_requests/36
I think it's ready now, but I'd like a QA review on the last patch.
Created attachment 98389 [details] [review] Bug 21466: Keep all AVs for a given framework There was a major (and silly) issue in the previous version, only one AV was kept as we erased the hash value at the end of each iteration: $invalid_locations_per_framework->{$framework->frameworkcode } = { items => $items, av_category => $mss->authorised_value, kohafield => $kohafield }; Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
OK, Tested thoroughly here.. looks good... Thanks Jonathan, passing QA