[OPEN-ILS-DEV] ***SPAM*** Re: displaying due time in opac/feeds? UPDATE

[Dan Scott]

On Mon, 2009-11-02 at 08:58 -0400, Grant Johnson wrote:
> Alexander has facilitated the due date TIME so it is displayed in the
> OPAC and Staff client for items that have "Hourly" locations.
> Things like Hourly Reserves and Study Rooms.
> 
> Click below and look for a Study Room that is "Not currently
> available"
> http://islandpines.roblib.upei.ca/opac/en-CA/skin/roblib/xml/rresult.xml?rt=title&tp=title&t=Group%2Bstudy%2Broom&l=4&d=2&f=&av=&ol=4
> 

That's pretty cool. As usual, UPEI forges ahead and solves its own
problem! I guess Alex is checking the location name in the returned acp
(asset.copy) object and displaying the due time if it matches "hourly",
which works well enough for your use case. The data is already there, it
just needed somebody to use it, and hardcoding a check against the
location name in the JavaScript itself does the job :)

I do wonder if there's a good generalized way that we could bubble that
behaviour upwards, so that libraries could turn the display of due times
on or off depending on attributes of the copy itself and/or the copy
location and/or the circulation attributes.

For example, here I've been reluctant to display the expected return
date for items because they're subject to being renewed - but if we were
to check the "renewal_remaining" attribute of the "circ" object (which
is part of the standard set of information returned for each copy in the
copy display panel) and saw that it was "0", then we could safely say
that it is supposed to be returned by the given date / time. That's no
guarantee that it won't be overdue, of course... for a more consistent
display, we could just display the due date / time and the number of
renewals remaining in all cases.

It should be easy enough to add another variable to the rdetails.js list
of variables that control record display, to turn this sort of behaviour
on and off. I guess the question that I'm hanging out there is, is that
the approach that we want to continue to foster? At some point, I expect
that there will miraculously (heh) be an OPAC that does more work on the
server side, and it would be nice if we were storing these skin-level
display decisions in the database so that they could be consistent
across skins & display mechanisms for each org_unit, rather than being
coded directly into one or more of the JavaScript files.