IRC log for #evergreen, 2014-07-17

All times shown according to the server's local time.

Time	Nick	Message
00:14		ldw joined #evergreen
02:29		jboyer_isl joined #evergreen
02:29		dreuther_ joined #evergreen
02:29		ktomita_ joined #evergreen
02:32		mtcarlsoz joined #evergreen
02:34		pmurray joined #evergreen
02:34		pmurray joined #evergreen
02:35		krvmga joined #evergreen
02:35		pastebot joined #evergreen
02:36		ningalls1 joined #evergreen
04:56	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
07:52		jboyer-isl joined #evergreen
07:54		jennyl joined #evergreen
08:00		rjackson-isl joined #evergreen
08:18		collum joined #evergreen
08:26		mrpeters joined #evergreen
08:41		ericar joined #evergreen
08:41		mmorgan joined #evergreen
08:43		RoganH joined #evergreen
08:44		jwoodard joined #evergreen
08:45		akilsdonk joined #evergreen
08:49		finnx joined #evergreen
08:57		jennyl_ joined #evergreen
09:09		kbeswick joined #evergreen
09:10		ericar joined #evergreen
09:13		kmlussier joined #evergreen
09:16		ericar joined #evergreen
09:16		RoganH joined #evergreen
09:21		ericar joined #evergreen
09:22		dbwells joined #evergreen
09:22		remingtron joined #evergreen
09:32		bmills joined #evergreen
09:46		mjingle joined #evergreen
09:47		kmlussier joined #evergreen
10:00		yboston joined #evergreen
10:12		akilsdonk joined #evergreen
10:23		bmills1 joined #evergreen
10:28		mllewellyn joined #evergreen
10:40		finnx joined #evergreen
10:42		finnx joined #evergreen
10:44		finnx joined #evergreen
10:46		finnx joined #evergreen
10:47		Dyrcona joined #evergreen
10:48		finnx joined #evergreen
10:50		finnx joined #evergreen
10:51		finnx joined #evergreen
10:53		dbwells_ joined #evergreen
10:53		collum\|2 joined #evergreen
10:53		remingtron_ joined #evergreen
10:53		kmlussier1 joined #evergreen
10:53		jboyer_isl joined #evergreen
10:54		finnx joined #evergreen
10:55		bmills joined #evergreen
10:55		jboyer_isl joined #evergreen
10:56		jboyer_isl joined #evergreen
11:03		jboyer-isl joined #evergreen
11:07		pastebot joined #evergreen
11:15	Bmagic	hello all: I am troubleshooting an issue with hold targeting. On a test machine I placed a hold on a bib that had no available items. I checked in one of the items and the system did not direct the item to my hold. Instead it wanted it to go back to the owning library.
11:16	jeff	what status was the item in when the hold was placed?
11:16	Bmagic	Is there a function in the database that I can probe and expierement with to find the answer to the hold magic? In this case, the system definatly should have put that item on the hold shelf for me.
11:16	Bmagic	jeff: The status was "in transit"
11:16	jeff	can you reproduce, and can you check the action.hold_copy_map table after placing the hold but before checking the item in, to see if the item is in the ahcm?
11:17	jeff	Bmagic: holds are dependent upon so many variables... if you retarget the hold and check the item in again, does it capture?
11:17	jeff	Bmagic: if not, then the copy is likely not eligible to fulfill the hold for any specific reason.
11:17	Bmagic	jeff: I did so. The copy that I checked in, is for sure in the pool from action.hold_copy_map
11:18	jeff	Bmagic: is age hold protection at play?
11:18	jeff	er, "in play" perhaps?
11:18	Bmagic	the circumstance is the copy belongs to another library but happens to be located at my location.
11:19	Bmagic	jeff: well, now that you mention it, the copy does have hold protection on it... let me see if that was it
11:20	hopkinsju	How did it come to be at the remote location if hold protection was active?
11:20	jeff	hold protection does not prevent the copy from being added to ahcm, but can make it fail a hold permit check at checkin/capture time.
11:20	Dyrcona	Also, patrons can return stuff anywhere.
11:20	hopkinsju	Oh, true Dyrcona
11:20	Dyrcona	And, just because the hold protection interval is set, it doesn't mean that that the protection is still active.
11:21	jeff	hopkinsju: hold protection may no longer be applicable due to create/active time, the copy may be in a volume with an owning_lib other than the library it's at, but a circ_lib of the library it's at -- or could be floating, or (my favorite corner case that isn't really a corner case) the item may have been returned to the library other than its circ lib.
11:21	jeff	and dyrcona got at least two of those things while i was typing
11:21	jeff	:-)
11:22	Dyrcona	:)
11:22	Dyrcona	Staff often forget that many patrons use multiple libraries in the consortium for a variety of reasons.
11:22	hopkinsju	We have a library system with 7 branches that is complaining of a behavior where an item belonging to one library in their system is placed on hold by a patron at another branch. The item is transited to the remote branch and upon being checked in...
11:22	hopkinsju	goes back home before fulfilling more holds at the same remote branch.
11:23	hopkinsju	Personally I'm not crystal clear about whether or not it fulfills a local (circ_lib) hold before being sent back out remote or if it just bounces through it's circ_lib and heads straight back out.
11:23	Bmagic	jeff: so, I checked the item in at the location that the system wanted me to send it... then it turns it right around and wants to send it back to the other branch for the hold!
11:23	hopkinsju	Now I'm clear, lol.
11:24	Dyrcona	Bmagic: That doesn't sound like what is supposed to happen. Have you altered the hold matrix weighting?
11:25	Bmagic	Dyrcona: I really don't know... where do I find that?
11:25	jeff	Bmagic: what was the status of the item before it being in transit?
11:26	Bmagic	it was in transit when I started this expierement
11:26	Dyrcona	Bmagic: If you don't know, then you probably haven't. The table is config.hold_matrix_weights if you want to peek in the database.
11:26	Bmagic	Dyrcona: I'll check
11:26	hopkinsju	Dyrcona: I don't believe we have made any changes to the matrix.
11:26	Bmagic	Dyrcona: There are 4 rows there
11:26	hopkinsju	Isn't the UI in the staff client to do that new?
11:27	Bmagic	Dyrcona: "Default","Item_Owner_First","User_Before_Requestor","All_Equal"
11:27	Dyrcona	Not sure. I know we've had it for a while, since like 2.4 or so.
11:27	Dyrcona	Bmagic: OK. Just thought it might be worth having a look.
11:28		mrpeters joined #evergreen
11:28	Bmagic	Dyrcona: Does that look default?
11:28		asimon joined #evergreen
11:29	mmorgan	Bmagic: try aborting the transit, then checking in?
11:29	Dyrcona	Bmagic: Those are the different entries.
11:30	Dyrcona	I doubt you've changed them. Very few people do. I don't think we've changed ours.
11:31	Bmagic	mmorgan: more expierements to come, I will report back
11:32		montgoc1 joined #evergreen
11:32	jeff	jennyl++ for "Evergreen allows you to be as militant as you like"
11:33	jennyl	jeff: or as lenient as you like!
11:33	Bmagic	s/experements/experiments/g
11:34	Dyrcona	There are also at least 36 org unit settings in master that affect holds.
11:34	Dyrcona	Having fun, yet? :)
11:35	mmorgan	...not to mention the "holdable" flags in the copy record, and the copy location ...
11:37	mmorgan	... and the statuses!
11:37	hopkinsju	Let's write a song about it guise.
11:38	hopkinsju	Take one down, pass it around, 35 org unit settings in master that affect holds on the wall.
11:41	asimon	*: What determines which stat cats and stat cat entries appear on the Patron Registration screen? Changing the home library doesn't change the stat cats and stat cat entries to those available for that org unit (at least on our system).
11:45	jeff	asimon: i believe it is the org unit of the workstation, though i haven't had occasion to look.
11:45	* mmorgan	believes jeff is correct.
11:45	Bmagic	mmorgan: Dyrcona: jeff: So, this time, setup the hold on the bib with all of the items not available. Found that the ahcm conatained the item in question. I manually changed the status of that item to "checked out" Then I checked it in, AND IT TARGETED THE HOLD... Perhaps it wasn't working before because it was "in trasit"
11:46	asimon	jeff: Ahh, that makes sense. TY.
11:46	jeff	asimon: it might also start with the home_ou of an existing patron, falling back to the org unit of the workstation, and not change "live" in the editor when the home ou is changed. that seems less likely.
11:46	jeff	Bmagic: i don't think you ever mentioned what status it was in before it was "in transit"
11:47	Bmagic	jeff: Scroll up
11:47	asimon	jeff: It definitely does NOT start with the home_ou of an existing patron, because the startging stat cat entries are incorrect when editing an existing patron.
11:48	jeff	asimon: thanks for confirming :-)
11:49	jeff	Bmagic: I don't think I'm seeing what you're expecting me to see when I scroll up. What specifically were you trying to draw my attention to?
11:50	Bmagic	jeff: The status was "in transit"
11:52	jeff	yes, but what status was the item in before going in transit? was it created with a status of "in transit"? that seems unusual.
11:55	mmorgan	does it matter what the status before going in transit was if the hold was placed while the item was already in transit?
11:58	Dyrcona	If the hold was placed while the item was in transit, it won't full until it reaches its destination, of course.
11:59	Dyrcona	full? really? umm... I guess you get the point.
12:00	mmorgan	so an in transit item checked in at a location other than its destination will never be captured for a hold?
12:00	Dyrcona	No, that depends on a lot of things.
12:01	Dyrcona	That copy may not be eligible to fill the hold at the time the hold targeter first runs.
12:01	hopkinsju	I don't understand why the item was in transit either Bmagic... Presumably the item was checked out to another patron right?
12:01	Dyrcona	After that it depends on how frequently the hold targeter, how long transit takes, etc.
12:02	* Dyrcona	cannot type today.
12:02	Bmagic	mmorgan: My expieriment tells me that you are correct. No matter how many times I check that item in, it wanted it to ship to the other location. Just to be clear, action.hold_copy_map contained the item in question.
12:02	hopkinsju	mmorgan: The behaviour I've seen is that the item will be repeatedly transited to the location where the current hold exists. It should only return home if there aren't any holds for it to fulfill I believe.
12:02	Bmagic	hopkinsju: it was in transit before I came to the system.. I don't know why it was in transit to begin with. Presumably, the hold didnt exist prior to it going to "in transit"
12:03	Dyrcona	I believe there is a list of statuses that are eligible for holds in the code somewhere, probably where it is checked. I don't recall , but I think "transit" is not on the list.
12:03	Dyrcona	Holds are very complicated.
12:04	* Dyrcona	runs off to acquire some lunch.
12:04	Bmagic	Dyrcona: interesting
12:04	mmorgan	we often find that we have to abort a transit in order to capture a hold, which by all rights should capture.
12:04	kmlussier	It seems like transit should be in that list.
12:11	mmorgan	Hmm. org unit setting "Minimum Transit Checkin Interval" seems relevant here.
12:13	* kmlussier	wonders about the use case for that setting.
12:13	mmorgan	"In-Transit items checked in this close to the transit start time will be prevented from checking in" is the description. We don't have it set.
12:13	kmlussier	It says it prevents checking, not hold capturing.
12:13	kmlussier	That is, checkin
12:15	kmlussier	Bmagic: Does the patron have any penalties that might prevent the hold from fulfilling?
12:34	* eeevil	reads up
12:36	eeevil	Bmagic: to be perfectly clear, a transit is going to hide the copy from capture. period. you can cancel the transit and capture, but if the transit is already taking place, the system assumes that it's potentially in the hands of a courier, not necessarily staff at the transit source (think: sorter)
12:38	jeff	eeevil: if the transit destination was the same as the location where it was being checked in, the transit would complete and then the item would be (potentially) captured, correct?
12:39	eeevil	jeff: yes, but note, it's not capturing until the transit is complete
12:39	* jeff	missed that the transit in question was not TO the library where the item was being checked in
12:40	eeevil	IOW, it's not capturing /in spite/ of the transit, it's finishing the transit and then, separately, checking the item in, which captures it
12:40	jeff	eeevil: right. checking an item in that is in transit to a library destination other than where the checkin is taking place will try to continue the transit to the destination
12:40	eeevil	aye
12:41	jeff	a rare holds question where the answer was for simple reasons -- i just missed noticing / asking about the destination of the transit. :-)
12:41	kmlussier	But hopkinsju said above that the item was being transited to the location where the hold exists.
12:41	jeff	s/for simple reasons/had a simple explanation/
12:41	eeevil	jeff: I had the benefit of a transcript ;)
12:42	eeevil	and thinkin' time ;)
12:42	hopkinsju	kmlussier: I wasn't speaking to Bmagic's specific case but the behavior I see in general.
12:42		dbwells_ joined #evergreen
12:42		remingtron__ joined #evergreen
12:42	kmlussier	Ah, ok.
12:42	eeevil	kmlussier: I don't think that's true for Bmagic's case
12:43	hopkinsju	Being that I don't work in a library, this usually happens when I check in a book without registering my workstation to the appropriate library.
12:43	jeff	kmlussier: i was thinking of Bmagic's issue, and not hopkinsju's
12:44	* kmlussier	buries her head back into the sand.
12:44	Dyrcona	Yeah, I understood it to mean that the copy was in transit status before the checkin that was expected to fill the hold.
12:45	* Dyrcona	was just perusing O::A::C::Circulate.pm.
12:46	Dyrcona	I sort of misspoke earlier: Transit is a "good" status for checkin in the place that I was thinking of.
12:47	Dyrcona	However, as eeevil said, transit short circuits some things elsewhere and holds won't capture until the transit is complete.
12:47	* mmorgan	is wondering why the system assumes the item is potentially in the hands of a courier if it's being checked in at the circ desk...
12:48	Dyrcona	mmorgan: That's only one way of explaining it. Basically, the transit needs to complete before holds will capture.
12:48	Dyrcona	Or be aborted/gone.
12:51	Dyrcona	The only checkin that will clear the transit is one that occurs at the transit destination.
12:53	jeff	Dyrcona: similar to how if you have an item on the hold shelf for a patron, and you check that item in (barring any checkin modifier like 'clear shelf expired holds'), the item will just go right back to the hold shelf for that patron.
12:53	jeff	er.
12:54	jeff	mmorgan: similar to how if you have an item on the hold shelf for a patron, and you check that item in (barring any checkin modifier like 'clear shelf expired holds'), the item will just go right back to the hold shelf for that patron.
12:55	Dyrcona	jeff: Unless, of course, you let your staff override it in the interest of "serving the patron" and they check it out to someone else, and then patron comes in to pickup a hold that isn't there, and staff blame Evergreen for the mixup. ;)
12:55	jeff	mmorgan: similar for transits -- if you're checking the item in that has a transit, and your checkin is not taking place at the library that is the destination for that active transit, then evergreen is going to tell you to send the item to the library that IS the destination. this is useful in a number of cases, including when an item for one library is mistakenly placed in the courier bag for another library, etc.
12:56	jeff	is this copy in transit? yes. are we the destination? no. try to send it to the destination!
13:01		ericar joined #evergreen
13:01	mmorgan	jeff: ok, makes sense, but I wonder ...
13:02	jeff	mmorgan: wondering about "if item was in transit when we scanned it, display a slightly different message and offer to abort or continue transit?" :-)
13:03	mmorgan	yes :) or if the transit should be reevaluated each time it's checked in to see if all the same circumstances are still true.
13:03	mmorgan	Like, is there still a hold the item is going in transit to fill
13:04	jeff	i'm not sure how much re-evaluation i'd want/expect the system to do, but i can see an optional prompt being helpful to avoid confusion.
13:04	mmorgan	or is there a hold here in my library that should be filled instead of sending it home :)
13:04		mjingle joined #evergreen
13:06	mmorgan	jeff: an additional prompt might certainly help.
13:07	jeff	I'm trying to think of common workflows where an item might be checked in at the non-destination library in a "normal" process -- where it wasn't just a "mistakenly sent to the wrong library".
13:07	jeff	I don't think we have any in our environment.
13:08	mmorgan	we have had situations where an in transit item has shown up at its home library which was neither the source nor destination of the transit.
13:09	mmorgan	the user needs to abort the transit, but needs that special permission to abort transits for which they are neither source nor destination.
13:10	mmorgan	failed to mention that the hold the item was travelling to fill had long been cancelled ...
13:11	mmorgan	if the system were to reevaluate whether the item really needed to be in transit, the staff user wouldn't need that special permission (which gives them more power than they generally need - or should have under normal circumstances)
13:14	mmorgan	I guess this all ties in with comfort level (or lack thereof) with giving users permission to abort transits - especially since they all end up in "Reshelving" status
13:16	mrpeters	@pinsol_green seen sylvar
13:16	pinesol_green	mrpeters: If all else fails, try this: http://en.wikipedia.org/wiki/Rubber_duck_debugging
13:17	kmlussier	@seen sylvar
13:17	pinesol_green	kmlussier: sylvar was last seen in #evergreen 26 weeks, 5 days, 0 hours, 21 minutes, and 22 seconds ago: <sylvar> but yeah, I know that feel :)
13:17	mrpeters	hah yikes long time no see
13:29	* Dyrcona	"sees" sylvar on Google+ all the time.
13:32		akilsdonk_ joined #evergreen
14:09		hbrennan joined #evergreen
14:25		kmlussier joined #evergreen
14:43		ldw joined #evergreen
14:51		RoganH joined #evergreen
15:23		ericar joined #evergreen
15:31		mjingle joined #evergreen
15:51		akilsdonk joined #evergreen
16:01		RoganH joined #evergreen
16:09		mjingle joined #evergreen
16:15		finnx left #evergreen
16:28		mjingle left #evergreen
16:44	Bmagic	anyone know what table that this would come from: hold.current_copy.call_number.record.simple_record.title ?
16:44	Bmagic	in the context of action trigger template
16:47		bmills joined #evergreen
16:52	Dyrcona	Bmagic: look in fm_IDL.xml for class id="bre" and see where the simple_record link goes.
16:53	Dyrcona	I believe it goes to reporter.metabib_simple_record or class id="rmsr"
16:53	Bmagic	Dyrcona++
16:53	Dyrcona	The object chain for that is something like: ahr->acp->acn->bre->rmsr using IDL class ids.
16:56	Dyrcona	Anyway, about time to go.
16:56	kmlussier	Dyrcona: Have a nice night!
16:56	Dyrcona	You also!
16:57	RoganH	Drycona: good night!
16:57	kmlussier	RoganH: Too late! :)
16:57	RoganH	kmlussier: that's my life, a fortnight late and a dinar short
16:58	kmlussier	Heh
17:01		vlewis joined #evergreen
17:04		ericar joined #evergreen
17:11		mrpeters joined #evergreen
17:12		mmorgan left #evergreen
17:21		kmlussier left #evergreen
18:51		hbrennan joined #evergreen
18:51		jwoodard joined #evergreen
18:53		remingtron__ joined #evergreen
18:53		mtcarlson joined #evergreen
18:53		b_bonner joined #evergreen
18:53		wjr_ joined #evergreen
18:53		riot joined #evergreen
18:53		paxed joined #evergreen
18:53		mtj_ joined #evergreen
18:53		vlewis joined #evergreen
18:53		rangi joined #evergreen
18:54		bradl joined #evergreen
18:55		ktomita_ joined #evergreen
18:55		dreuther_ joined #evergreen
18:55		dkyle joined #evergreen
18:55		shadowspar joined #evergreen
18:55		sseng joined #evergreen
18:55		edoceo joined #evergreen
18:55		eby__ joined #evergreen
18:55		dbs joined #evergreen
18:55		Callender joined #evergreen
18:56		Bmagic joined #evergreen
18:56		hopkinsju joined #evergreen
18:56		gmcharlt joined #evergreen
18:56		jventuro joined #evergreen
20:04		bmills joined #evergreen
20:58		ldw joined #evergreen