[OPEN-ILS-DEV] Reshelving Complete

[Bill Ott]

Mike Rylander wrote:
> On Thu, Sep 17, 2009 at 7:33 PM, Bill Ott <bott at grpl.org> wrote:
>   
>> We've found some oddities in the times at which items would go from
>> reshelving to available.  I've located a couple issues, and am wondering
>> what others think about the process.
>>
>> I've found some items selected by the query that I can't explain.  It's a
>> pretty complex query, but I believe the later portion, designed to make
>> newly processed items that have never circulated available, is selecting
>> more than expected, but I can't identify a reason.
>>     
>
> As it stands, with the UNION ALL, it will select some copies twice,
> which is not as efficient as it could be but shouldn't be selecting
> more than, well, it should.  Do you have some examples?
>   

Here's some auditor data for an item that was in circulation for a few 
days, it was checked in and went from reshelving to available in about 
36 minutes.  (current status is available, audit_times are desc)

   id   | status |          audit_time          
--------+--------+-------------------------------
 381832 |      7 | 2009-09-17 13:00:01.43433-04
 381832 |      1 | 2009-09-17 12:24:28.221189-04
 381832 |      0 | 2009-09-11 13:13:07.690483-04


I also just located 37 copies that have never circulated (i.e. no 
action.circulation record), but have a status of reshelving.  I would 
think that these should have been caught as newly created items.  Those 
that I've looked at seem to be reference items that were apparently 
checked in for some reason.

   id    | status |           edit_date          
---------+--------+-------------------------------
  635989 |      7 | 2008-11-05 20:12:29.392036-05
  325796 |      7 | 2008-11-13 14:51:47.993696-05
  263712 |      7 | 2008-11-13 15:01:34.121305-05

If you or someone with access has time to investigate further, please 
feel free.


>> A separate issue exists with transited items.  The current query looks at
>> the circ.checkin_time and the copy status, but not the copy edit_date.  This
>> means that a transited item will not consider the
>> circ.reshelving_complete.interval, as the checkin may have occurred long
>> before the status is changed from in transit to reshelving.
>>
>>
>> My question is:  Is it important to look at the circulation at all?  Would
>> it be bad to have all items to go from reshelving to available on the same
>> timeline, regardless of how they got there?
>>     
>
> I think that goal is a good one, but we need to be clear on what that
> timeline, whatever it ends up being, means in workflow terms.
>
> The current definition centers on circulation completion.  It has the
> two caveats you mention (transited items probably won't get the full
> reshelving delay, and uncirculated item reshelving is based on
> edit_date), but the central tenant seems correct.
>   

Just to stay on track, it currently looks at create_date.


> The first implication that comes to mind if we move to all-edit_date
> is that we make it easy to extend the reshelving delay by making
> changes to the copy unrelated to circulation or the concept of the
> reshelving delay.  Today, those are all manual processes, but by
> pinning what is currently meant to be "time since checkin" to a
> generic "last time we touched the copy", we are opening ourselves up
> to unintended consequences with automated processes down the road.  In
> essence, any automated or batch process that deals with copies could
> end up causing this unintended extension.
>   

True...

> Now, IMO, it's a question we should put to circulation managers, but
> my vote is currently no on the option of moving to edit_date-based
> reshelving.
>
> That said, I would be in favor of two alternate additions:  first,
> adding another branch to the current query to take the most recent
> transit of an item into account, if that transit ended /after/ the
> most recent circulation; and, moving to UNION instead of UNION ALL to
> improve the UPDATE performance.
>
> Thoughts on that counter-proposal?
>   

Transits are certainly our largest issue.  Our volume and work flow puts 
items back to available much to soon in many cases.

Performance of this query hasn't been an issue for us, but the examples 
above do confuse me.