Bug 38671 - Add fields to item search and item search results table - lost_on, withdrawn_on, damaged_on
Summary: Add fields to item search and item search results table - lost_on, withdrawn_...
Status: RESOLVED DUPLICATE of bug 38331
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-10 19:55 UTC by hebah
Modified: 2024-12-12 14:58 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hebah 2024-12-10 19:55:29 UTC
Since bug 37238 brought item search into table settings, it would be great to flesh out some of the other item data fields like lost_on, damaged_on, or withdrawn_on. Because it is now a configurable table, libraries would be able to hide or expand those columns as needed.
Comment 1 Andrew Fuerste-Henry 2024-12-11 14:51:08 UTC
The three fields you mention are all datetimes rather than just dates and most of the options here are just checking = / !=. That seems like it will confuse people -- they'll search for itemlost_on='2024-12-11' and not find anything because the actual value is '2024-12-11 14:39:24.'

We could add a hint here that suggests one might want to use % after a date. Or we could make the search just compare to the date alone, ignoring the time.

The former seems more accurate. The latter seems more friendly to a novice user.
Thoughts?
Comment 2 hebah 2024-12-11 15:27:07 UTC
I did ponder the complication of the datetime issue.

Which is to say - I initially thought of it as simply adding the columns to the display without making it a search parameter for that reason.

But to be added as a search parameter, I think only searching the date would be the most librarian-friendly, with folks who need more granularity there able to do so from report.
Comment 3 Andrew Fuerste-Henry 2024-12-11 16:00:32 UTC
(In reply to hebah from comment #2)
> I did ponder the complication of the datetime issue.
> 
> Which is to say - I initially thought of it as simply adding the columns to
> the display without making it a search parameter for that reason.
> 
> But to be added as a search parameter, I think only searching the date would
> be the most librarian-friendly, with folks who need more granularity there
> able to do so from report.

Oh! I misunderstood your request; lemme look at getting those columns available in results.
Comment 4 Lucas Gass (lukeg) 2024-12-11 23:39:08 UTC
If we just want this in the results table, awesome. 

I do think it would be beneficial to be able to search ON those fields also, like datelastborrowed currently. 

I filed this:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38681

I think having a datepicker is nicer for staff and also make it easier to deal with datetime.
Comment 5 hebah 2024-12-12 14:01:29 UTC
On further thought, though it wasn't the original scope of my idea, I do think searching by lost_on etc would be helpful - a common library workflow is to review items lost longer than X time, and with batch modification from item search now, it would be fab to be able to find these really old lost items and batch end checkouts/withdraw etc.
Comment 6 Andrew Fuerste-Henry 2024-12-12 14:58:21 UTC

*** This bug has been marked as a duplicate of bug 38331 ***