Bug 23422 - CART location feature
Summary: CART location feature
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-02 20:41 UTC by Christopher Brannon
Modified: 2023-04-24 18:59 UTC (History)
3 users (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 Christopher Brannon 2019-08-02 20:41:28 UTC
Why was the CART feature made to be a stored value?  I am curious why a preference wasn't setup for an hour value, and if an item location is displayed anywhere, this setting could be compared to the timestamp and current time and if it is within the value entered, just display CART or Recently Returned or whatever next to the location.

I know it would take changing things in several locations, but it seems this would be much more stable, and would also be less information to store.  I don't know if it would cause a performance issue or not.  Just thought I'd throw this out there.
Comment 1 Katrin Fischer 2019-08-03 09:44:17 UTC
Time comparisons in a lot of places could possible be more time consuming. We'd also need to pull information that is not available in some places like the XSLT built result list - the time of return would require querying the old_issues table.

Having a value to query makes it easier for reporting - that might be another slight advantage. Instead of using the location, one could have imagined having a separate item column for the information. Other systems I know treat the 'cart' more like a status value, but it was always stored with the item.

Thinking about this... could it be nice to have a 'reshelving done' feature that allows you to easily change all those 'cart' items returned in a time range back to their usual location without having to wait or schedule the cron?
Comment 2 Christopher Brannon 2019-08-03 17:28:32 UTC
(In reply to Katrin Fischer from comment #1)
> Time comparisons in a lot of places could possible be more time consuming.
> We'd also need to pull information that is not available in some places like
> the XSLT built result list - the time of return would require querying the
> old_issues table.
> 
> Having a value to query makes it easier for reporting - that might be
> another slight advantage. Instead of using the location, one could have
> imagined having a separate item column for the information. Other systems I
> know treat the 'cart' more like a status value, but it was always stored
> with the item.
> 
> Thinking about this... could it be nice to have a 'reshelving done' feature
> that allows you to easily change all those 'cart' items returned in a time
> range back to their usual location without having to wait or schedule the
> cron?

Either that, or the option of barcode batches, or a checklist that can be checked as one is shelving.  Good options, but I think most libraries would rather the system do it automatically.  But for those trying to be more accurate, small libraries might go with the time range, since they are handling less books.  But there is no guarantee that it is actually shelved.  Maybe if it had another status applied to it, like damaged, it is ignored?

Just some thoughts.
Comment 3 Christopher Brannon 2023-04-24 18:48:58 UTC
In thinking this over more, I think it would be great if the item record had one or two shelving statuses available, along with time stamps, and a preference that could manage them.

For example, if we had at least one temp shelving field with associated timestamp, we could use this for the cart feature (which I think should at least be renamed bookcart), and we could tell how long it has been since it was triggered.

Then we have a preference that allows us to look at this field and watch for certain values, and then decide how long that value sticks around, in either hours or days.  So, maybe the entry looks like:

bookcart|1d

or

bookcard|12h

But this would only work with 1 value.  Sometimes we might want to have more than one value.  Maybe we want the item to be on a display too.  If we had another field with timestamp, we could have it setup for a temp display for a period of time:

display1|31d

Maybe we don't need to touch cart at all, and just have the other for displays?

It WOULD be helpful if whether it was a cart location or display location, that it would show next to the permanent location rather than replacing it, as the cart location currently does.
Comment 4 Christopher Brannon 2023-04-24 18:59:08 UTC
Also, maybe we don't want certain locations to be put back on display when returned, and others we do.  Maybe if we don't want an item to go back on the display when checked out, instead of a time period, we put something else:

display1||x

If the item is checked back in and the timestamp is not older than the time period in the setting, or if the time period is x, the location and timestamp are cleared, and it acts as normal.  But if it has a time period that hasn't lapsed, when the item is checked in, there is an alert or flag on the item to let the staff know it goes back to display.

Then maybe a predefined term, like bookcart, doesn't need to remind or flag items on checkin.  Or maybe we can use another indicator to not remind/flag on checkin.  That way we have options on everything?

bookcart|1d|n

I'm just shooting out ideas here.  If there would be a better way to implement this and still provide the same abilities, I'd be open to suggestions.