| Summary: | Use of permanent location instead of location | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Jonathan Druart <jonathan.druart> |
| Component: | Course reserves | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | kyle |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Bug Depends on: | 21446, 25444 | ||
| Bug Blocks: | |||
|
Description
Jonathan Druart
2020-05-27 10:46:25 UTC
(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. (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. > 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?
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? (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. 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.
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 |