[OPEN-ILS-DEV] Reshelving Complete

[Mike Rylander]

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?

>
> 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.

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.

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?

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com