| Time |
Nick |
Message |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
collum joined #evergreen |
| 07:30 |
|
rjackson_isl_hom joined #evergreen |
| 08:30 |
|
mmorgan joined #evergreen |
| 08:32 |
|
mantis joined #evergreen |
| 08:57 |
|
Keith-isl joined #evergreen |
| 09:02 |
|
Keith_isl joined #evergreen |
| 09:07 |
|
jvwoolf joined #evergreen |
| 09:08 |
|
rfrasur joined #evergreen |
| 09:45 |
|
Dyrcona joined #evergreen |
| 10:31 |
|
rfrasur joined #evergreen |
| 10:31 |
|
Keith_isl joined #evergreen |
| 10:31 |
|
mantis joined #evergreen |
| 10:31 |
|
collum joined #evergreen |
| 10:32 |
|
berick joined #evergreen |
| 10:32 |
|
eady joined #evergreen |
| 10:32 |
|
jeff joined #evergreen |
| 10:32 |
|
bshum_ joined #evergreen |
| 10:32 |
|
Dyrcona joined #evergreen |
| 10:32 |
|
collum joined #evergreen |
| 10:32 |
|
Bmagic joined #evergreen |
| 10:32 |
|
phasefx joined #evergreen |
| 10:32 |
|
dbs joined #evergreen |
| 10:32 |
|
akilsdonk joined #evergreen |
| 10:32 |
|
rhamby joined #evergreen |
| 10:32 |
|
csharp_ joined #evergreen |
| 10:32 |
|
gmcharlt joined #evergreen |
| 10:32 |
|
eby joined #evergreen |
| 10:32 |
|
miker joined #evergreen |
| 10:33 |
|
book`_ joined #evergreen |
| 10:33 |
|
jonadab joined #evergreen |
| 10:33 |
|
JBoyer joined #evergreen |
| 10:35 |
miker |
jeff: re uncanceling holds, the reason it's like that is because, if the hold was canceled by mistake by staff, the patron doesn't lose their place in line due a mistake. maybe make it dependent on cancel reason? |
| 10:35 |
|
Dyrcona joined #evergreen |
| 10:38 |
jeff |
the new request_time can be set to that of the original hold (depending on the value of the org unit setting circ.holds.uncancel.reset_request_time). |
| 10:45 |
jeff |
part of my musing was to try and avoid losing some of the original data about the hold, such as cancel_time, cancel_cause, cancel_note. It would also be nice to not lose shelf_time, though uncancel hold isn't the only operation that can reset shelf_time. |
| 10:46 |
miker |
jeff: doh, indeed. |
| 10:46 |
jeff |
and i suppose if we were to create a new ahr on "uncancel", we'd need to decide if we continue to show the original now-uncancelled hold in "recently cancelled holds" (probably), and if we do show it, if we allow it to be uncanceled (probably not) |
| 10:47 |
miker |
an "already_uncanceled" flag ;) |
| 10:49 |
jeff |
to avoid the two ahr rows pointing at each other, perhaps the cancelled hold gets an uncancel_time (and the newly reanimated hold can continue to have a link that points to the original ahr id) |
| 10:50 |
jeff |
but trying to determine "has this hold been uncanceled by looking at all other holds for a hold that points at this hold" makes me wary about indexes and performance and such. |
| 10:50 |
jeff |
uncancel_time, uncancel_reason, uncancel_note... *ducks* |
| 10:53 |
JBoyer |
jeff, maybe a separate table like action.hold_cancelation that only contains a link to the ahr in question and whatever historical data you're interested in keeping? those fields could be copied from ahr by a trigger watching for the cancelation related fields. Cancel and un-cancel the same ahr 3 times and you get 3 historical cancelations but the row in ahr is no different than it would be today. |
| 10:55 |
JBoyer |
i.e. not quite an auditor entry, and only fields that "matter" to a cancelation, not things like current copy, etc. |
| 10:57 |
jeff |
While I see some value in that kind of thing in a lot of places (including here) where we want to give staff some better visibility into the history of a thing (without resorting to "ask someone to read the auditor tables"), it makes things like reporting on "count of holds by shelf time" or "holds cancelled by date/cause/etc" more complex. |
| 11:00 |
jeff |
needing to conditionally consult another table for the "real/original" data and perhaps count that hold twice (once for the ahr table, 0 or more times for the ancillary table) seems awkward, even if you created a helper view/etc that synthesized a list of all the holds with all of their pissible current and historical values... |
| 11:02 |
jeff |
now you have a bunch of rows output by this view that you're looking at, but some of them have duplicate ids now... we could teach the helper view/etc to create different IDs for the rows that it synthesizes, but... |
| 11:04 |
JBoyer |
It depends on how un-canceled holds are counted (and the desired outcome in the end). Since they currently "disappear" from canceled hold reports like those I'd be inclined to just keep that going. |
| 11:04 |
jeff |
I think holds are something where I would like a table of events, mostly intended for staff view, and to perhaps be considered ephemeral or something that goes away when the hold is aged, etc. |
| 11:05 |
JBoyer |
Mmm, an event log sort of thing. |
| 11:05 |
jeff |
right. |
| 11:06 |
jeff |
copies and holds are two places where i've thought we might benefit from that kind of thing. |
| 11:06 |
JBoyer |
That could be useful (reminds me of Unicorn's event log reports), could be awful (an auditor for *.*!) |
| 11:07 |
jeff |
and could be a mix of intentional/explicit log entries as well as auditor-style trigger-based updates. |
| 11:09 |
jeff |
"Marked as damaged by staff FOO on workstation BAR" vs "Changed: Location Stacks -> New Fiction; Circ modifier (none) -> BOOK by unknown" |
| 11:10 |
JBoyer |
Sounds like a potential (substatnial) expansion of the existing work log |
| 11:10 |
JBoyer |
(Which I'll admit to having precious little knowledge of, as I never cared about it before) |
| 11:11 |
* mmorgan |
wonders how many cancelled holds actually get uncancelled vs. a new hold being placed, supposes there's no way to know that. |
| 11:11 |
jeff |
and in that second example, if it was a batch db update, if you called set_event_info(user, workstation, note, etc) then the "by unknown" wouldn't be there, it could say something useful like "batch update to fix stray something-or-other ticket XYZ1234" |
| 11:11 |
jeff |
mmorgan: right! :-) |
| 11:11 |
jeff |
mmorgan: now you see the problem! ;-) |
| 11:12 |
* jeff |
ducks again |
| 11:12 |
mmorgan |
or - is it really a problem? ;-) |
| 11:12 |
* mmorgan |
ducks |
| 11:12 |
jeff |
there are two ways that can help answer that question: you can examine logs for use of the uncancel API call, or you can enable auditing on action.hold_request |
| 11:13 |
jeff |
I think that some libraries audit action.hold_request, but I suspect with retargeting that there's a lot of churn there, and I don't know how much of a performance impact it would have -- we don't currently but I might soon, and find out. |
| 11:13 |
jeff |
JBoyer: yes, there are similarities to work log. |
| 11:14 |
mmorgan |
Only staff can uncancel a hold, right? Not patrons. |
| 11:14 |
jeff |
but first, i have a batch of holds to uncancel for reasons. |
| 11:14 |
jeff |
mmorgan: correct |
| 11:15 |
jeff |
mmorgan: or to be more precise, you need CANCEL_HOLDS permission and there's no patron-side UI that exposes the functionality. |
| 11:17 |
jeff |
(and patrons don't need CANCEL_HOLDS to cancel their own holds) |
| 11:54 |
|
jihpringle joined #evergreen |
| 12:23 |
|
collum joined #evergreen |
| 12:32 |
|
collum joined #evergreen |
| 13:44 |
|
jvwoolf joined #evergreen |
| 13:52 |
|
rfrasur joined #evergreen |
| 14:08 |
|
jihpringle joined #evergreen |
| 15:09 |
|
jvwoolf joined #evergreen |
| 16:05 |
|
Keith_isl joined #evergreen |
| 16:24 |
|
jihpringle joined #evergreen |
| 16:42 |
mmorgan |
What kiosk software/browser/mode are folks using these days for the Evergreen self check? |
| 16:45 |
jihpringle |
mmorgan: I think most of our libraries are just using Chrome, some may be using the kiosk mode but they set that up themselves (we just supply them with the self-check interface) |
| 16:45 |
jihpringle |
If someone has something that works well for them I'd love to know so we can recommend it |
| 16:47 |
mmorgan |
jihpringle: Thanks! Eons ago we used OpenKiosk, but a few things have changed since then ;-) |
| 16:52 |
jeff |
I would strongly recommend using something like OpenKiosk or WebConverger or another tool that does a good job of limiting interaction with the browser. We have used OpenKiosk in the past and I haven't used it lately. WebConverger comes highly recommended and we've dabbled with it a while back. There are likely other suitable options, those are just the two potentials that spring to mind first. |
| 16:54 |
mmorgan |
Has anyone tried Chrome Kiosk mode? |
| 16:54 |
|
jvwoolf left #evergreen |
| 16:54 |
jeff |
Trying to use a general-purpose web browser strikes me as a bad idea for multiple reasons, mostly related to preventing theft and abuse of the staff auth token that the self checkout interface uses. |
| 16:55 |
jeff |
(I'm making no assertions either way about Chrome in kiosk mode -- on Chrome OS or any other OS) |
| 16:55 |
jeff |
(no assertions either way, I meant to say) |
| 16:58 |
mmorgan |
jeff: Ok, thanks for the feedback. I'll find some time to poke and report back if I discover anything useful. |
| 16:58 |
mmorgan |
jihpringle++ |
| 16:58 |
mmorgan |
jeff++ |
| 17:39 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:20 |
|
alynn26_away joined #evergreen |
