Bug 25676 - Staff interface catalog search shows incorrect item status under location
Summary: Staff interface catalog search shows incorrect item status under location
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-04 13:52 UTC by Joe Sikowitz
Modified: 2023-12-10 10:09 UTC (History)
1 user (show)

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


Attachments
Incorrect search result example (68.12 KB, image/jpeg)
2020-06-04 13:52 UTC, Joe Sikowitz
Details
Correct item record example (91.99 KB, image/jpeg)
2020-06-04 13:53 UTC, Joe Sikowitz
Details
Bug 25676: Display the correct Lost value in the result search (3.12 KB, patch)
2020-06-10 11:02 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Sikowitz 2020-06-04 13:52:21 UTC
Created attachment 105553 [details]
Incorrect search result example

If you have an item that has a Lost status of "Lost" it will appear as "long overdue" in staff client search results. See attached screenshots for an example.

This should display the current Lost status instead.
Comment 1 Joe Sikowitz 2020-06-04 13:53:22 UTC
Created attachment 105554 [details]
Correct item record example
Comment 2 Andrew Fuerste-Henry 2020-06-04 16:36:38 UTC
Looking at Joe's site, this seems to be particular to items that are set to itemlost=1 (which should show "Lost") but are also still checked out. 

select biblionumber from items where onloan is not null and itemlost=1
Bibs listed in this report display "long overdue" as Joe has described.

select biblionumber from items where onloan is null and itemlost=1
Bibs listed in this report show "Lost" as they should
Comment 3 Katrin Fischer 2020-06-07 13:08:01 UTC
I believe the issue is here:

koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/results.tt:                                                                    ([% onloan_items_loo.count | html %][% IF ( onloan_items_loo.longoverdue ) %], [% onloan_items_loo.longoverdue | html %] long overdue[% END %]) date due: [% onloan_items_loo.due_date | $KohaDates %]

And that leads us to Search.pm making wrong assumptions:

# if something's checked out and lost, mark it as 'long overdue'
if ( $item->{itemlost} ) {
   $onloan_items->{$key}->{longoverdue}++;
   $longoverdue_count++;
}

And now we have an issue: we can't guarantee which value is the long overdue value lost value. If a library isn't using the long overdue prefs but using command line parameters. So maybe we need to change this to just show the lost description as is.
Comment 4 Jonathan Druart 2020-06-10 11:02:06 UTC
Created attachment 105684 [details] [review]
Bug 25676: Display the correct Lost value in the result search
Comment 5 Jonathan Druart 2020-06-10 11:05:24 UTC
I had a try to fix this, but it's confusing.
About "(1, 1 Lost)", I never managed to display more that 1 on the same line.
For onloan items, I can only see 1 line per line (they are not grouped if same code, location, cn, etc.)

The idea here was to display:
(2, 1 Lost, 1 Long overdue), depending on the description in the LOST av category.
Comment 6 Katrin Fischer 2020-06-11 19:50:37 UTC
> The idea here was to display:
> (2, 1 Lost, 1 Long overdue), depending on the description in the LOST av
> category.

I think maybe we should just give up on the grouping and say:

1 Lost, 1 Long overdue