| Time |
Nick |
Message |
| 02:18 |
|
BitRent joined #evergreen |
| 02:19 |
|
BitRent left #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 07:31 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
JBoyer joined #evergreen |
| 07:43 |
|
Callender joined #evergreen |
| 08:16 |
|
tsbere joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:49 |
|
bos20k joined #evergreen |
| 08:56 |
csharp |
http://xkcd.com/1741/ feels particularly relevant to me this morning as I stare at acq code |
| 08:57 |
csharp |
actually it's cstore editor syntax that's snagging me right now |
| 08:57 |
jeff |
what's the EDI order cancellation code for Glass Supplier Dispute? |
| 08:57 |
csharp |
jeff++ |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:04 |
|
mdriscoll joined #evergreen |
| 09:04 |
jeff |
one of the questions that often comes up with "allow people to check out their spouse/child/friend's items from the hold shelf" is "which patron gets the circ?" |
| 09:06 |
|
maryj joined #evergreen |
| 09:07 |
jeff |
there are arguments for both "the patron who placed the hold" and "the patron with the item in hand", and something that came to mind was "the patron with the item in hand, but the patron who placed the hold gets the option to 'claim' the circ, therefore be able to renew, get the overdue notices, etc." |
| 09:07 |
jeff |
but the complexity (both for the user and implementation) of that last one... |
| 09:07 |
Dyrcona |
jeff: We've been talking about that at C/W MARS a bit lately. |
| 09:08 |
csharp |
yowza - that would get confusing quickly |
| 09:09 |
* csharp |
dictatorially institutes a "pick up your own damn holds" policy |
| 09:10 |
* tsbere |
prefers csharp's method, though won't complain about "staff look up the child's card and check out to them" either |
| 09:11 |
Dyrcona |
We figured a setting for who gets the circulation. |
| 09:12 |
jeff |
another option is simply to check the item out to the patron who had it on hold (arguably "best" for things like renewals, notifications, etc) -- and to call attention to that fact at checkout time (in a SIP client, this would be by setting an item alert message and ensuring the client is configured to display it), and an email to the patron "As previously authorized by you, John Smith has picked up the following item/items which are now checked out to yo |
| 09:12 |
Dyrcona |
And, a radio group in the dialog for what to do about the hold. |
| 09:12 |
Dyrcona |
Didn't really think about SIP doing this. I'm not sure I'd allow that. :) |
| 09:12 |
jeff |
and a "contact the library if there's a problem with this" where staff could handle the (ideally infrequent) issues. |
| 09:13 |
jeff |
Dyrcona: what options were you thinking of presenting for the hold? |
| 09:13 |
csharp |
actually, PINES policy allows for "proxy" borrowing and hold pickups. In the case of the latter, they have to be "authorized" on the hold patron's account in advance. The item is checked out to the person picking up unless they have the hold patron's card in hand. |
| 09:13 |
Dyrcona |
jeff: Cancel the checkout, checkout and retarget hold, checkout and fill the hold.... |
| 09:13 |
jeff |
so that isn't proxy borrowing, really -- because you don't allow the proxy to check out for the patron who authorized? |
| 09:14 |
Dyrcona |
We really ought to implement a "friends" feature, though I'm sure most wouldn't use it. |
| 09:14 |
csharp |
jeff: sorry, I can see I wasn't clear - the proxy *can* check out the item if they have the hold patron's library card in hand |
| 09:14 |
csharp |
otherwise it would go on their own card |
| 09:14 |
|
krvmga joined #evergreen |
| 09:14 |
csharp |
(the proxy's own card) |
| 09:15 |
* csharp |
unties the knots in his brain |
| 09:15 |
jeff |
Dyrcona: what's the scenario where you'd checkout and retarget? would that be for when a patron was NOT authorized by the hold patron, but just staff opting to allow someone to take an item that a patron had already been notified was available for them? |
| 09:16 |
jeff |
csharp: got it. perhaps i was being too strict in my definition of "proxy" there. |
| 09:16 |
Dyrcona |
jeff: Yeah. If the patron isn't related and staff are going to go ahead and check it out anyway. That shouldn't be allowed, but I don't get to make the rules. |
| 09:16 |
csharp |
(for the logs and the curious, PINES circ policy manual is here: http://pines.georgialibraries.org/circulation) |
| 09:16 |
jeff |
Dyrcona: yeah, that's going to be hard to explain to the original patron who had the hold. |
| 09:16 |
miker |
Dyrcona: "friends" backend is there, waiting for biz logic checks and a UI :) |
| 09:17 |
jeff |
friends backend is one of the things we'd be considering to make use of for this. |
| 09:17 |
Dyrcona |
miker: Yeah, I know. I was considering finishing it up at one point 3 or 4 years ago, but time. |
| 09:17 |
Dyrcona |
jeff: I agree, but it isn't me that has to explain, so.... |
| 09:17 |
miker |
cool. I support all of this |
| 09:17 |
Dyrcona |
I think most staff just blame "the system." :( |
| 09:18 |
csharp |
@blame the system |
| 09:18 |
pinesol_green |
csharp: the system stole bradl's tux doll! |
| 09:18 |
Dyrcona |
We have too many "stole x's tux dolls." :) |
| 09:18 |
csharp |
(in reality, we just *kept* bradl's tux doll, which is still in the PINES cage) |
| 09:20 |
* Dyrcona |
loves it when ssh sessions "hang" for no apparent reason. |
| 09:20 |
Dyrcona |
@blame the firewall |
| 09:20 |
pinesol_green |
Dyrcona: I know it was you, the firewall. You broke Dyrcona's heart. You broke Dyrcona's heart. |
| 09:22 |
csharp |
mosh++ |
| 09:22 |
csharp |
jeff++ # for introducing me to mosh |
| 09:22 |
jeff |
Dyrcona: perhaps you joke, and i dislike almost every time that someone latches onto "it must be the firewall", but as recent experience confirmed, sometimes it really is the firewall. :-) |
| 09:23 |
Dyrcona |
Yeah, sometimes it is. I really don't know this time. |
| 09:23 |
Dyrcona |
@blame the tubes |
| 09:23 |
pinesol_green |
Dyrcona: Forget it, Jake. It's just the tubes. |
| 09:23 |
jeff |
(firewall bug was what was causing my ssh sessions to hang for a while, among other things -- like not being able to complete a download of IDL2js if the latency between my client and the server was too low) |
| 09:24 |
Dyrcona |
Well, this one just became unresponsive. and xoff/xon wasn't helping, so... |
| 09:24 |
jeff |
that latest @blame sounds like it could be part of a @MicroSFF story |
| 09:26 |
|
kmlussier joined #evergreen |
| 09:29 |
Dyrcona |
heh. Chinatown. :) |
| 09:32 |
* kmlussier |
likes the idea of a setting to determine who gets the checkout. |
| 09:33 |
kmlussier |
I thought we had built the option in with the requirements MassLNC wrote up a couple of years back, but it looks like we didn't. http://masslnc.org/node/2912 |
| 09:44 |
jeff |
and since we'd be doing it via SIP, we have the additional requirement of needing authorization stored in a way that we can check in a programmatic way. |
| 09:47 |
jeff |
i'm pretty sure that establishing the "friend" link is going to be trickier than the actual circulation changes. |
| 09:50 |
kmlussier |
As much as a like the friends feature, if it's ever implemented, I hope we're able to do this more seamless checkout for libraries that opt against using the friends feature. |
| 09:53 |
Dyrcona |
kmlussier: I'm inclined to say no to that. We already have too many ways to do most things. |
| 09:55 |
kmlussier |
When I've shared the idea with many circ folks, there has been some reluctance to implementing the friends feature. Some people like it, but there were concerns that a) people wouldn't designate other people as friends and b) circ staff would have time to do that kind of linking on behalf of them. |
| 09:55 |
kmlussier |
I got the sense that people would continue to do workarounds rather than utilizing the friends infrastructure. |
| 09:56 |
Dyrcona |
Of course, they will. They continue to do workarounds rather than use other built-in features of the software, so how is this different? |
| 09:57 |
kmlussier |
Most people I've talked to simply want the 3 options you mentioned earlier in the prompt. It seems fairly reasonable to save a few clicks. |
| 09:58 |
Dyrcona |
Well, that was our quick and dirty solution without the full implementation of friends. |
| 09:58 |
Dyrcona |
And, that's likely what we'll do here if we implement it. |
| 09:59 |
kmlussier |
Yes, I think that addition to the prompt on its own will be valuable to users |
| 09:59 |
kmlussier |
FWIW, I really like the idea of using the Friends infrastructure for handling proxy holds. I'm just reporting what I've heard when I've tried talking it up. |
| 10:00 |
jeff |
CREATE TABLE actor.org_unit_philosophy ( |
| 10:00 |
jeff |
... |
| 10:05 |
|
mmorgan1 joined #evergreen |
| 10:40 |
|
mmorgan joined #evergreen |
| 10:41 |
miker |
friends has the possible benefit of letting a site decide which subset of the above options to display to staff by looking at what permissions the friend has been granted, I think. and the original thought was that there would be specialized UIs for linking and adding certain permissions (and a generic link and permission management UI for the patron, as well) |
| 10:43 |
miker |
so I don't think using friends as a backend means staff can't have what they want, short of "on demand" just-do-it proxy-ing ... which, from a patron privacy standpoint, I'm kinda against |
| 10:43 |
jeff |
they can be used independently and they can be complimentary. good to keep in mind when developing each (which also might happen independently but ideally not in a vacuum) |
| 10:44 |
jeff |
but yes, in our environment we'd disable at least some of what has been proposed above. |
| 10:45 |
jeff |
i don't know what i think in terms of "staff should know not to use this option", but I see a UI that encourages off-policy behavior (or offers it as an option in a prompt) as at least potentially problematic. |
| 10:46 |
Dyrcona |
Well, yeah, and my thinking was that we'd do the dialog with options to get something that staff can use now, and then drop it when friends is working. |
| 10:46 |
jeff |
we're also not looking to build overly burdensome interfaces that hamper staff's ability to service patrons with things like "are you sure? this sounds against policy. please call an on-duty manager to proceed", etc. :-) |
| 11:06 |
|
Christineb joined #evergreen |
| 11:30 |
|
brahmina joined #evergreen |
| 11:57 |
csharp |
"are you sure? You know we log all this stuff, right?" |
| 11:58 |
jeff |
"well, except that." |
| 11:58 |
jeff |
"clever!" |
| 12:06 |
kmlussier |
I'm looking at possibly merging the fix for bug 1308090. Dyrcona, I noticed you mentioned that you think it might be a bug fix. Before I backport it, I wanted to see if anyone had concerns about it being a bug fix since it requires a partial reingest. |
| 12:06 |
pinesol_green |
Launchpad bug 1308090 in Evergreen 2.10 "sorting of name headings with relator codes " [Undecided,Confirmed] https://launchpad.net/bugs/1308090 |
| 12:08 |
jeff |
is the partial reingest optional, with the only consequence being "you don't benefit from the bug fix"? |
| 12:08 |
kmlussier |
I suppose it could be. |
| 12:09 |
jeff |
that would just leave it up to the person crafting the point release upgrade script to include the partial reingest or simply recommend it. |
| 12:11 |
|
gmcharlt joined #evergreen |
| 12:32 |
|
sandbergja joined #evergreen |
| 12:52 |
csharp |
so... shouldn't there be a rel_2_11_0 in the git repo? |
| 12:53 |
Dyrcona |
origin/tags/rel_2_11_0 |
| 12:53 |
csharp |
oh - thanks |
| 12:54 |
Dyrcona |
np |
| 12:55 |
|
krvmga joined #evergreen |
| 13:09 |
|
Christineb joined #evergreen |
| 13:49 |
csharp |
50407652 |
| 13:49 |
pinesol_green |
csharp: [evergreen|Kathy Lussier] LP#1612274: Add distinct classes for hold statuses - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5040765> |
| 14:19 |
|
collum joined #evergreen |
| 15:12 |
|
kmlussier joined #evergreen |
| 15:36 |
|
ssieb joined #evergreen |
| 15:42 |
Dyrcona |
I'm setting up a Debian Wheezy fresh install for the first time and the Evergreen pre-requisites had a single CPAN package fail. |
| 15:44 |
Dyrcona |
Excel::Writer::XLSX failed because Archive::Zip was not installed. |
| 15:44 |
Dyrcona |
Installing libarchive-zip-perl fixed it. |
| 15:45 |
Dyrcona |
I have only just now gotten as far as installing the OpenSRF and basic Evergreen pre-reqs. |
| 16:04 |
csharp |
Dyrcona: why wheezy? |
| 16:05 |
miker |
because wheezy is the bees knees-ies |
| 16:05 |
Dyrcona |
csharp: I want to test my upgrade branch on something as close to our production setup as possible. |
| 16:06 |
Dyrcona |
So, I'm installing OpenSRF 2.4.1 and Evergreen 2.9.5 from git. Then, I'll test my tarball and upgrade script. |
| 16:06 |
Dyrcona |
We're upgrading to 2.10.7 this weekend. |
| 16:08 |
csharp |
oh, I see |
| 16:08 |
csharp |
miker++ |
| 16:08 |
Dyrcona |
csharp: If it makes you feel any better, I made a Jessie VM, too. I'm just not using it, yet. ;) |
| 16:08 |
* csharp |
feels WAY better now |
| 16:09 |
Dyrcona |
:) |
| 16:32 |
* mmorgan |
will be very happy when Canceled transit status makes it to a system near me :) |
| 17:10 |
|
mmorgan left #evergreen |
| 19:18 |
|
dcook joined #evergreen |
| 21:03 |
|
ssieb joined #evergreen |
