Bug 25609 - Use of permanent location instead of location
Summary: Use of permanent location instead of location
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Course reserves (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 21446 25444
Blocks:
  Show dependency treegraph
 
Reported: 2020-05-27 10:46 UTC by Jonathan Druart
Modified: 2020-05-29 08:06 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Druart 2020-05-27 10:46:25 UTC
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.
Comment 1 Kyle M Hall 2020-05-27 11:02:55 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.
Comment 2 Katrin Fischer 2020-05-27 11:55:25 UTC
(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.
Comment 3 Kyle M Hall 2020-05-27 14:16:54 UTC
> 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?
Comment 4 Katrin Fischer 2020-05-27 20:26:58 UTC
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?
Comment 5 Kyle M Hall 2020-05-28 18:15:03 UTC
(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.
Comment 6 Katrin Fischer 2020-05-28 20:55:18 UTC
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.
Comment 7 Jonathan Druart 2020-05-29 08:06:51 UTC
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