[Bug 25609] New: Use of permanent location instead of location
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25609 Bug ID: 25609 Summary: Use of permanent location instead of location Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Course reserves Assignee: koha-bugs@lists.koha-community.org Reporter: jonathan.druart@bugs.koha-community.org QA Contact: testopia@bugs.koha-community.org Depends on: 25444, 21446 Initially the course reserves used "location", since bug 21446 it uses "permanent location". It leads to a display problem if permanent location is not set, but location is. Reported initially on bug 25444 comment 14. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21446 [Bug 21446] Improve display of changed values on course reserves and show permanent location instead of cart https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25444 [Bug 25444] Course reserve settings are not saved on edit -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25609 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25609 --- Comment #1 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Jonathan Druart from comment #0)
Initially the course reserves used "location", since bug 21446 it uses "permanent location".
It leads to a display problem if permanent location is not set, but location is.
Reported initially on bug 25444 comment 14.
That leads to an interesting question; How is it possible to have permanent location not set while location is? Koha::Item::store sets permanent_location to location if it doesn't have one in nearly all scenarios. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25609 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Kyle M Hall from comment #1)
(In reply to Jonathan Druart from comment #0)
Initially the course reserves used "location", since bug 21446 it uses "permanent location".
It leads to a display problem if permanent location is not set, but location is.
Reported initially on bug 25444 comment 14.
That leads to an interesting question; How is it possible to have permanent location not set while location is? Koha::Item::store sets permanent_location to location if it doesn't have one in nearly all scenarios.
I checked an installation continually updates from 3.2 - and the permanent_location is definitely empty there. I don't think we ever did a global change for that to clean up existing data. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25609 --- Comment #3 from Kyle M Hall <kyle@bywatersolutions.com> ---
I checked an installation continually updates from 3.2 - and the permanent_location is definitely empty there. I don't think we ever did a global change for that to clean up existing data.
That feels like a bug, would you agree? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25609 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- A bug in the installation or a bug we should have a patch for? :) If we start (or already do) rely on permanent location we should fix the data for existing installations I think. It looks like Item CRUD operations were only moved to Koha::Object recently - could it be that we had places where it was not set before? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25609 --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #4)
A bug in the installation or a bug we should have a patch for? :) If we start (or already do) rely on permanent location we should fix the data for existing installations I think.
It looks like Item CRUD operations were only moved to Koha::Object recently - could it be that we had places where it was not set before?
I presume the functionality moved intact. The permanent location is primarily used by the Cart to Shelf feature, and UpdateItemLocationOnCheckin can use it as well. It seems to me that it certainly would not hurt anything to have a database update to populate permanent_location from location. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25609 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I have dug a bit deeper: $DBversion = '3.01.00.043'; if (C4::Context->preference("Version") < TransformToNum($DBversion)) { $dbh->do('ALTER TABLE items ADD COLUMN permanent_location VARCHAR(80) DEFAULT NULL AFTER location'); $dbh->do('UPDATE items SET permanent_location = location'); So if a database set up with a later version shows empty permanent_location entries, while location is set, this must have happened somewhere after this updatedatabase entry. Maybe by not setting the permanent_location correctly in import, editing, adding...? So maybe we need to make sure that it's now handled correctly everywhere before we try to get to a clean state again. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25609 --- Comment #7 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- The new Koha::Item->store ensure us that it will be correct each time we save it. We can add a new update DB entry and eventually a check in search_for_data_inconsistencies.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org