| Time |
Nick |
Message |
| 02:16 |
|
rsinger joined #evergreen |
| 02:17 |
|
zxiiro joined #evergreen |
| 03:43 |
|
book` joined #evergreen |
| 05:31 |
|
rsinger joined #evergreen |
| 06:12 |
|
gsams joined #evergreen |
| 07:21 |
|
phasefx joined #evergreen |
| 07:32 |
|
tater joined #evergreen |
| 07:57 |
|
tater joined #evergreen |
| 07:58 |
|
phasefx joined #evergreen |
| 08:10 |
|
werebutt joined #evergreen |
| 08:10 |
|
werebutt left #evergreen |
| 08:29 |
|
mrpeters joined #evergreen |
| 08:31 |
|
collum joined #evergreen |
| 08:32 |
|
ericar joined #evergreen |
| 08:37 |
|
Shae joined #evergreen |
| 08:38 |
|
kbeswick joined #evergreen |
| 08:47 |
|
mmorgan1 joined #evergreen |
| 08:47 |
|
mmorgan1 left #evergreen |
| 08:49 |
|
mmorgan joined #evergreen |
| 08:59 |
|
timf joined #evergreen |
| 08:59 |
|
finnx_ joined #evergreen |
| 09:02 |
|
rfrasur joined #evergreen |
| 09:08 |
|
Dyrcona joined #evergreen |
| 09:14 |
|
finnx_ joined #evergreen |
| 09:28 |
|
Callender joined #evergreen |
| 09:36 |
|
rjackson-isl joined #evergreen |
| 09:45 |
|
yboston joined #evergreen |
| 10:02 |
|
BigRig joined #evergreen |
| 10:28 |
|
mcooper joined #evergreen |
| 10:39 |
|
Shae joined #evergreen |
| 10:39 |
bshum |
Hmm |
| 10:39 |
|
ericar joined #evergreen |
| 10:40 |
rfrasur |
? |
| 10:40 |
* bshum |
needs to learn more asciidoc |
| 10:40 |
bshum |
Or remind myself how it all works again |
| 10:40 |
dbs |
bshum: what's the q? |
| 10:41 |
bshum |
I was looking for documentation on something, which I found in my git repo, but I couldn't find it in the docs site index. |
| 10:41 |
bshum |
Specifically, I was trying to find where docs/circulation/rfid_product_integration.txt ended up in the docs website. |
| 10:41 |
* rfrasur |
is looking forward to learning much DIG related stuff at EG2014 |
| 10:41 |
bshum |
But couldn't find it anywhere. |
| 10:41 |
dbs |
It's entirely possible the transforms are broken, or that the file isn't included anywhere |
| 10:41 |
* dbs |
takes a look-see |
| 10:42 |
dbs |
include::rfid_product_integration.txt instead of include::circulation/rfid_product_integration.txt |
| 10:42 |
dbs |
whoopsie. |
| 10:42 |
bshum |
Aha |
| 10:42 |
bshum |
That explains it |
| 10:43 |
bshum |
I was just looking at the root.txt and trying to figure out how it ought to be |
| 10:43 |
bshum |
Thanks dbs! |
| 10:43 |
* dbs |
tries running a fixed version of the PDF/ePub transforms, will check in the fix if it works |
| 10:44 |
bshum |
I was just talking with PV Supa folks and they were like, yeah, go make sure you install the add-ons. Which I knew must have docs explaining somewhere.... |
| 10:44 |
dbs |
meh, dblatex error. bah |
| 10:45 |
bshum |
Hmm |
| 10:45 |
bshum |
That file looks like maybe it needs some light tweaking anyways. |
| 10:46 |
bshum |
Oh hmm |
| 10:46 |
bshum |
Just different than I originally expected. |
| 10:48 |
dbs |
might be a local issue, PDF transform is complaining that it doesn't grok source highlighting for "conf" |
| 10:49 |
dbs |
epub transform was clean though, so I'll check in the simple fix |
| 10:49 |
|
dluch joined #evergreen |
| 10:50 |
|
dluch joined #evergreen |
| 10:51 |
rfrasur |
Just a reminder that DIG meeting will begin in 10 minutes. |
| 10:51 |
bshum |
dbs++ #thanks! |
| 10:51 |
dbs |
Okay, pushed to master / 2.5 |
| 10:52 |
|
kbutler joined #evergreen |
| 10:54 |
pinesol_green |
[evergreen|Dan Scott] Include RFID docs with full path - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f8eefdb> |
| 11:01 |
yboston |
#startmeeting 2014-01-27 - DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting. |
| 11:01 |
pinesol_green |
Meeting started Mon Jan 27 11:01:07 2014 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 11:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 11:01 |
pinesol_green |
The meeting name has been set to '2014_01_27___dig_monthly_meeting_evergreen_documentation_interest_group__dig__monthly_meeting_' |
| 11:01 |
yboston |
The agenda can be found here http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140127-agenda |
| 11:01 |
yboston |
#topic Introductions |
| 11:01 |
yboston |
Please feel free to start introducing yourselves... |
| 11:01 |
* yboston |
is Yamil Suarez @ Berklee college of Music - DIG meeting facilitator |
| 11:01 |
bshum |
#info bshum = Ben Shum, Bibliomation |
| 11:02 |
* dluch |
is Debbie Luchenbill, Missouri Evergreen at MOBIUS |
| 11:02 |
* ldwhalen |
is Liam Whalen, Sitka |
| 11:02 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 11:02 |
rfrasur |
#info rfrasur = Ruth Frasur, Hagerstown, Evergreen Indiana |
| 11:02 |
kbutler |
#info kbutler = Kate Butler, Rodgers Memorial, NH |
| 11:02 |
* mceraso |
is Melissa Ceraso, Bibliomation |
| 11:03 |
ericar |
#info ericar = Erica Rohlfs, Equinox |
| 11:04 |
yboston |
I think we can get started now |
| 11:05 |
yboston |
Lets start with New agenda items |
| 11:06 |
yboston |
#topic Post DIG hack-a-way discussion |
| 11:06 |
yboston |
we spoke a bit about this already, but it was still in the agenda |
| 11:06 |
yboston |
any comments or questions? |
| 11:08 |
yboston |
One sub item on this topic is that we need to think about what to do and work on during this year's conferece |
| 11:09 |
dluch |
Just a general question--I couldn't participate, because we had a "crisis" with one of our libraries...but did participants feel like this is something we should/could do on a regular basis to update documentation? (or not) |
| 11:09 |
rfrasur |
dluch: this meaning a hackaway or what? |
| 11:09 |
dluch |
Yes, sorry |
| 11:10 |
dluch |
Hackaway |
| 11:10 |
bshum |
"regular" being more than just once a year at a different time than the main conference. |
| 11:11 |
yboston |
I definitely would like to do it more often than a hack-a-way in the fall and during the conference hackfest |
| 11:11 |
yboston |
but it has been hard to gert a group of people to have the free time for day long meetings |
| 11:11 |
rfrasur |
Well, there were only three people here at the last meeting. I agree with yboston that it'd be nice to do it more often. |
| 11:11 |
rfrasur |
yes, that. |
| 11:11 |
jeff |
doc sprints? :-) |
| 11:12 |
yboston |
I guess I have hoped that once we get more participation and folks trained at those two events, then we can do more group work |
| 11:12 |
yboston |
and more often |
| 11:12 |
yboston |
(like doc sprints) |
| 11:14 |
yboston |
for example, as a group we have considered to collectively devote two hours on a Friday afternoon to work on documentation while being connected on GooGle Hangout |
| 11:15 |
yboston |
I keep thinking that training new folks and having ready bite size assignments or practice HW will be key to increase our numbers |
| 11:16 |
yboston |
(practice homework or quizzes) |
| 11:16 |
yboston |
so far we have an hourlong training online, and several DIG members have started identifying bite size assignments |
| 11:18 |
yboston |
#link https://docs.google.com/presentation/pub?id=1o8HruJayUSEvXQlU_IjU6xN3cJbuw3yagENlcUM7sUU&start=false&loop=false&delayms=3000 DIG AsciiDoc tutorial Slides |
| 11:18 |
dluch |
As a new folk, I think that sounds like a good plan |
| 11:18 |
yboston |
#link https://www.youtube.com/watch?v=7uX1NtlJRfU DIG AsciiDoc training Video (1 hour long) |
| 11:18 |
bshum |
Yes, it sounds like a nice logical foundation to build upon. |
| 11:19 |
yboston |
with the upcoming conference, we have another opportunity to recruit more volunteers and get work done during the cofnerence |
| 11:20 |
yboston |
at some point, today I would like to talk about what we should try to do at the conference |
| 11:20 |
yboston |
from recruiting, training, and work on docs |
| 11:20 |
rfrasur |
(pardon...trying to deal with a network issue) |
| 11:20 |
ldwhalen |
I need to learn AsciiDoc, after I look at the slides and watch the video, if there was a small piece of documentation that was needed, that I could write while learning AsciiDoc that might be a good way for me to both learn and produce something useful. |
| 11:21 |
rfrasur |
Can I just throw something out there for people to chew on? |
| 11:22 |
yboston |
ldwhalen: In a perfect world, what I would rather you (and other newcomers) do is to design a simple test assignment that gives you a chance to try the basic skills of the training video |
| 11:22 |
yboston |
because an assignment in the wild could be deceptively confusing for a newcomer |
| 11:23 |
rfrasur |
I know we're putting a lot of conversation/emphasis on AsciiDoc and that's very necessary. I think, however, that we'll get more buy-in/participation if we can separate the formatting from the content. |
| 11:23 |
yboston |
but until I create that assignment we can pair newcomers with a veteran DIG member to find a good starting tasks |
| 11:24 |
yboston |
rfrasur: that is a valid point |
| 11:24 |
rfrasur |
oy. pardon again. I need to go offline. Back in a dang sec. (or minute) |
| 11:25 |
yboston |
ldwhalen: go ahead and check out the video, and follow up with me directly if you want or the list so we can suggest a small documentation task for you to work on |
| 11:26 |
ldwhalen |
#action ldwhalen will review AsciiDoc tutorial information and contact yboston afterwards. |
| 11:27 |
yboston |
so if I may, I woudl like to shift to one of the sub-agenda items of this topic |
| 11:27 |
yboston |
#topic: Post DIG hack-a-way discussion: ideas for next year and next year's conference |
| 11:28 |
yboston |
we need to start brainstorming on what DIG will do before, during, and after the conference |
| 11:29 |
yboston |
for example, I think we should try schedule a time for people to get asciidoc training online before the confernece |
| 11:29 |
yboston |
kinda like we did for the 2013 DIG hack-a-way |
| 11:30 |
yboston |
we can do training on the day of the DIG hack-fest, but I rather get an early crack and training new folks |
| 11:30 |
|
rfrasur joined #evergreen |
| 11:31 |
yboston |
we need to schedule a DIG meeting during the conference, either during the Wednesday DIG ahckfest or at some other free time during the conference |
| 11:31 |
* rfrasur |
is back. |
| 11:31 |
yboston |
we do not have to sort all this out today, but I wanted to at least bring it up now |
| 11:32 |
yboston |
rfrasur: while you were gone I brought up that we should start brainstorming what DIG should do before, during, and after the conference, like offering acidic training before the conference starts |
| 11:33 |
rfrasur |
yboston: do you think we could wait to schedule the meeting until we get there for Wednesday? |
| 11:33 |
yboston |
I would rather pick a time before hand, but we should decide as a group |
| 11:34 |
rfrasur |
I'd love to see part of the hackfest be training on AsciiDoc. I'm not sure what the layout off the work area will be, but I have to imagine that there could be some separation for people that just wanna work and people that want to learn. |
| 11:34 |
yboston |
one reason is that we often have folsk that are curious about DIG that only show up to the meeting, and if we don't have a set time they might not know when o show up |
| 11:35 |
yboston |
rfrasur: we will have a room that can fit at least 20 people, if not more |
| 11:35 |
rfrasur |
that's true. Well, I think it should probably be after Wednesday. If those are the people we're targeting, they may not arrive until Wednesday night/Thursday morning. |
| 11:35 |
yboston |
there will be another room, that will house the dev hack-fest |
| 11:35 |
* rfrasur |
nods. |
| 11:35 |
rfrasur |
Rock on. |
| 11:35 |
dluch |
I'm in favor of scheduling in advance, so people can make appropriate schedule and travel plans and such |
| 11:36 |
ldwhalen |
I am also in favour of scheduling in advance. If the hack fest and DIG meeting are at the same time, then I will be attending the hack fest. |
| 11:37 |
* dbs |
= Dan Scott, Laurentian University |
| 11:37 |
yboston |
for the record, DIG only has Wednesday officially assigned for our work and meeting. I wanted to suggest that we have a second informal meeting at some point in the afternoon during the conference to try to recruit new members |
| 11:38 |
yboston |
or something of the sort |
| 11:38 |
dbs |
fwiw I've always advocated that we shouldn't care what format someone gives us, as long as it has the right license and the content is good, asciidoc markup only takes a few minutes |
| 11:38 |
rfrasur |
ldwhalen: Right now, the dev hackfest and docs hackfest are at the same time. |
| 11:38 |
rfrasur |
dbs++ |
| 11:38 |
ldwhalen |
rfrasur: alright, no need to change for me then. I will do my best to catch up afterwards. |
| 11:40 |
rfrasur |
ldwhalen: that's just the hackfest though. And, if there's AsciiDoc training, it'd most likely be first thing (I'm assuming). Time can def be split between dev and doc if you're comfortable and interested. It's my understanding that the meeting would be separate...like Yamil described. |
| 11:40 |
yboston |
dbs: I have made it clear when asked that DIG accepts any format, but when it comes time to find someone to do the asciidoc conversion, we always are short of volunteers. |
| 11:40 |
bshum |
I could see some time in between hacking and DIG activities for myself. |
| 11:41 |
yboston |
dbs: also when a new volunteer wants to just add a few things or fix a few things, asciidoc becomes somewhat necessary |
| 11:42 |
|
ElliotFriend joined #evergreen |
| 11:42 |
rfrasur |
yboston: I'm looking at the schedule. At 4:15 on Thursday, there's FulfILLment and Release management as well as a cataloging interest group. |
| 11:43 |
yboston |
rfrasur: regretfully, I'll probably need to attend the cataloging interest group |
| 11:43 |
yboston |
meeting |
| 12:02 |
|
serflog joined #evergreen |
| 12:02 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 12:03 |
yboston |
OK folks, thanks! |
| 12:03 |
bshum |
Oy, we lost the meeting when the server rebooted. |
| 12:03 |
yboston |
#endmeeting |
| 12:04 |
yboston |
oops |
| 12:04 |
rfrasur |
Thank you, Yamil. |
| 12:04 |
ElliotFriend |
yboston++ |
| 12:04 |
dluch |
Thanks, yboston |
| 12:04 |
ldwhalen |
yboston++ |
| 12:04 |
mceraso |
yboston++ |
| 12:04 |
bshum |
I'll see what I can do about putting back together logs |
| 12:05 |
rfrasur |
are you going to copy and paste, bshum? |
| 12:05 |
bshum |
rfrasur: Something like that. |
| 12:05 |
rfrasur |
okay. I'll leave you to it. |
| 12:05 |
bshum |
Once I figure out where everything went on the actual web server. |
| 12:05 |
* rfrasur |
is redundant. |
| 12:06 |
rfrasur |
bshum++ |
| 12:11 |
bshum |
Yep, csharp was right. The lockup on the web server basically killed the bots off around 11:43 or so. So there's some gaps there and we did lose the meetbot notes :( |
| 12:11 |
jeff |
hrm. not sure if i missed some agenda points. did we cover "Including technical information in end-user docs" under old business? |
| 12:11 |
yboston |
jeff: we did not cover it |
| 12:12 |
jeff |
I've had a few times where I'd like to write up some bits in detail, especially nitty-gritty bits. I'd love some guidance (either in general, or case-specific) on where this kind of thing could belong. |
| 12:13 |
jeff |
Because I think it had been general concensus that placing detailed technical documentation in the wiki or in TechRef was something we wanted to move away from -- is that still correct? |
| 12:13 |
jeff |
In talking about it now, I suppose placing things in the wiki to begin with and then optionally moving some into docs can make sense also. Talking aloud and contradicting myself, perhaps. |
| 12:14 |
jeff |
Anyone else have thoughts? |
| 12:15 |
ldwhalen |
jeff: what do you mean by technical information? |
| 12:15 |
yboston |
jeff: BTW, this topic was discussed in an earlier DIG meeting and perhaps also on the mailing list. I can't remember what the consensus was |
| 12:15 |
jeff |
And as for DIG access to developers, I'd recommend IRC or (perhaps better) the dev mailing list -- many hands make fewer instances of what ldwhalen described as "at some point I will catch up". |
| 12:25 |
ldwhalen |
yboston: You wanted to talk after the meeting? |
| 12:26 |
yboston |
ldwhalen: yes, do you want to switch to a private messgae |
| 12:26 |
yboston |
? |
| 12:26 |
ldwhalen |
yboston: ok |
| 12:27 |
jeff |
ldwhalen: it varies, but anything from "this is how hold shelf expiration dates and closed dates interact" (which is useful across all levels of technical detail) to "this is information about the guts of 'thing' with probably little benefit to users/admins and a potentially high chance of changing" |
| 12:31 |
jeff |
so rather than worrying about it up-front, if and when i have some bits thrown on a wiki page i'll bring it to the attention of the dig mailing list and go from there. |
| 12:32 |
ericar |
yboston: I just added how to contribute documentation to EG wiki homepage. Not so hard to find now. |
| 12:33 |
jeff |
ericar++ |
| 12:33 |
ldwhalen |
jeff: thanks for the explnation. I was curious about the separation between instructions and technical informaiton. |
| 12:41 |
|
kbutler joined #evergreen |
| 12:42 |
|
smyers_ joined #evergreen |
| 12:47 |
bshum |
Bleh, I miss the plain text IRC logs sometimes. The new ilbot logs in MySQL annoy me. |
| 12:48 |
bshum |
I should look into converting that to PostgreSQL sometime. |
| 12:48 |
bshum |
And upgrading everything. |
| 12:48 |
bshum |
Again. |
| 12:48 |
* bshum |
should go eat lunch first. |
| 12:50 |
rfrasur |
Someday, I aspire to have an IT staff. Just saying. |
| 13:00 |
|
smyers__ joined #evergreen |
| 13:12 |
|
jihpringle_ joined #evergreen |
| 13:35 |
ldwhalen |
berick: Thank you for taking the time to respond to my questions and statements. I am going to hold off on further comments until I have had time to work with the code. |
| 13:49 |
|
stevenyvr joined #evergreen |
| 14:03 |
|
phasefx_ joined #evergreen |
| 14:04 |
|
Callender_ joined #evergreen |
| 14:04 |
|
BigRig_ joined #evergreen |
| 14:06 |
|
mtate joined #evergreen |
| 14:12 |
|
kbeswick joined #evergreen |
| 14:27 |
|
Dyrcona1 joined #evergreen |
| 14:28 |
|
Dyrcona joined #evergreen |
| 14:28 |
Dyrcona |
wifi... |
| 14:29 |
rfrasur |
is highly overhyped. |
| 14:29 |
rfrasur |
local wifi? or wifi internet? |
| 14:30 |
|
hopkinsju joined #evergreen |
| 14:31 |
bshum |
http://pandawhale.com/post/25590/maslow-pyramid-20-now-with-wifi |
| 14:31 |
hopkinsju |
Does age based hold protection have a setting for scope? By default, how far can the item circulate when it's under protection? |
| 14:31 |
Dyrcona |
my laptop decided to join a different access point visible from my office. |
| 14:32 |
Dyrcona |
I've told it not to join that one again. |
| 14:32 |
rfrasur |
Ah yes. The battle of the access points. |
| 14:33 |
rfrasur |
My laptop was joining an access point across the street rather than our home access point. I figure it's one of those stupid rebels. The kind that just likes to steal even if it's getting something inferior to what it already has. |
| 14:33 |
hopkinsju |
Is it possible to set up age based hold protection in such a way that patrons at another branch in the same system can place holds, but not patrons outside the system? |
| 14:34 |
bshum |
hopkinsju: Assuming this is circ-matrix stuff? |
| 14:34 |
bshum |
Either way |
| 14:35 |
bshum |
I think that what you need to poke at might be the "prox" value in config.rule_age_hold_protect |
| 14:35 |
bshum |
If that's 0, then it won't go very far. |
| 14:35 |
bshum |
aka, nowhere other than local library |
| 14:35 |
bshum |
Oh, right hold matrix, duh |
| 14:35 |
hopkinsju |
bshum: I'm looking at the hold policy configuration screen in the staff interface. I'll have to investigate the DB side |
| 14:36 |
hopkinsju |
A related question is whether or not an item needs to have age based hold protection if it's defined in the hold policy matrix... |
| 14:37 |
bshum |
hopkinsju: From the client, I think you'd want to look at the Server Admin --> Age Hold Protect Rules GUI |
| 14:37 |
bshum |
And then change the "Allowed Proximity" value for a given protection rule |
| 14:38 |
bshum |
We don't use age protection in Biblio, so I'm not sure about how it all works actually. |
| 14:38 |
hopkinsju |
So "2" = branch |
| 14:38 |
hopkinsju |
? |
| 14:39 |
bshum |
I think 2 is how far it can hop in terms of org unit proximity. But I'm not sure. |
| 14:39 |
bshum |
0 meaning, no hops, local only. 2 meaning two hops... so from org unit --> org system --> consortium |
| 14:39 |
rfrasur |
jboyer-isl: I know we have a couple districts that deal with this. |
| 14:39 |
hopkinsju |
Seems like a value of 2 would allow it to go anywhere. |
| 14:39 |
bshum |
This is the dark ages of Evergreen to me :( |
| 14:40 |
* bshum |
tries to forget silly bootstrap config interface |
| 14:40 |
mmorgan |
hopkinsju: we use age hold protection in NOBLE, we have prox = 2 to keep new items among branches. |
| 14:40 |
mmorgan |
One hop up and one hop down |
| 14:40 |
bshum |
Well it's require four hops to go to another library in another branch system |
| 14:41 |
bshum |
library --> system --> consortium --> system --> library |
| 14:41 |
|
Bmagic joined #evergreen |
| 14:41 |
bshum |
Or like mmorgan says, two hops for in -system: library --> system --> library |
| 14:41 |
hopkinsju |
This seems like an odd and unconventional (at least in the way EG does other things, depth wise) |
| 14:42 |
jeff |
poll: do your libraries have the PATRON_EXCEEDS_FINES standing penalty set to block renewals, and if so, what is your threshold for that standing penalty? :-) |
| 14:42 |
bshum |
jeff: We took off the block on renewals for most of our penalties. |
| 14:42 |
bshum |
I think |
| 14:42 |
* bshum |
checks |
| 14:42 |
hopkinsju |
This may not be our issue then bshum, mmorgan. One of our systems came on with 7 branches and when they catalog new items for another branch it sends the item home rather than fulfilling active holds |
| 14:43 |
jboyer-isl |
hopkinsju: For better or worse, the best documentation for the holds and circ matricies are the code files in Open-ILS/src/sql/Pg/100...sql and 110...sql. The age protection stuff in the holds matrix isn't actually connected to anything. |
| 14:43 |
jboyer-isl |
Yet. |
| 14:43 |
hopkinsju |
jboyer-isl: That's so awesome! |
| 14:43 |
jboyer-isl |
And the transit_distance field wants an id to the org_units_type table, not an actual distance. |
| 14:43 |
bshum |
The hold matrix stuff is still a gnarly mess :\ |
| 14:44 |
bshum |
Oy |
| 14:44 |
mmorgan |
hopkinsju: Just new items? |
| 14:45 |
jboyer-isl |
As for your initial question, you can set an actual distance in the Admin/Server Admin/Age hold Protection settings page, we have a Cons/Sys/Branch setup here and use a distance of 2 on age protection so branches can circulate each others items. |
| 14:45 |
hopkinsju |
mmorgan: Well, the problem report is mostly new items with one exception. |
| 14:46 |
hopkinsju |
The one exception being an item that was returned at branch A, owned by branch B, with a hold placed at branch C. The item was routed back home to B rather than sent on to C for the hold. |
| 14:47 |
bshum |
hopkinsju: What are the circ lib on the copies set to? vs. the own lib on the volumes? |
| 14:47 |
bshum |
Cause I would expect items with a circ lib to fulfill holds at their location or wherever they're checked in, before going to fill holds elsewhere. |
| 14:47 |
bshum |
Unless you have rules setup based on ownership instead of circ library. |
| 14:48 |
jboyer-isl |
hopkinsju: and because it sometimes matters, are the acn.owning_lib the same as the acp.circ_lib on the problem items? |
| 14:48 |
jboyer-isl |
Oh, hey, bshum types faster than I do. :D |
| 14:48 |
bshum |
Heh |
| 14:48 |
bshum |
Well, we have that situation in one of our libraries. |
| 14:49 |
bshum |
Where the main branch catalogs and "owns" copies of things |
| 14:49 |
bshum |
But they want their copies used to fill holds at their sister branches. |
| 14:49 |
hopkinsju |
We are looking at the examples now. |
| 14:49 |
* hopkinsju |
plays hold music |
| 14:49 |
bshum |
So either they have to catalog things to be circ lib at those other branches |
| 14:49 |
bshum |
Or we finally finish fixing our instance of Evergreen to support some additional hold sorting options that came with Evergreen 2.4+ |
| 14:50 |
bshum |
(plus bugfixes, since apparently some things are broken) |
| 14:51 |
jboyer-isl |
hopkinsju, bshum: I just noticed something that is really important above. bhsum, in your explanation of transit distance, I don't think that's quite how it works. |
| 14:51 |
bshum |
jboyer-isl: Oh I'm sure you're probably right. I might be going off super old interpretations there. |
| 14:52 |
jboyer-isl |
As I understand it, if you look at the org_unit tree, distance increases as you go up AND down in the tree. So if you have 2 systems (a,b) and each of them has 2 branches (a1,a2,b1,b2) the count goes like so: |
| 14:53 |
bshum |
jboyer-isl: I'm not sure about that actually.... just because of what I see for values by default in actor.org_unit_proximity.prox |
| 14:53 |
jboyer-isl |
a1 to a is 1, a1 to a to a2 is 2. So for an item under hold protection to transit to be |
| 14:54 |
bshum |
With that table, proximity between orgs is basically how I described it earlier for counting hops. |
| 14:54 |
hopkinsju |
a1 meaning System A Branch 1 |
| 14:55 |
hopkinsju |
nm, read up |
| 14:56 |
jboyer-isl |
(meant to trim that last bit..) If that's not how it's counted, I'm not sure how our current setup would work at all. (unless the hold protection allowed proximity field is ALSO an index into the org_unit_types table...) |
| 14:58 |
bshum |
jboyer-isl: I think we might be talking two different things |
| 14:58 |
hopkinsju |
From earlier bshum, we are seeing that the circ_lib and owning_lib are == |
| 14:58 |
bshum |
In config.hold_matrix_matchpoint.transit_range, that *is* actor.org_unit_type as you say |
| 14:58 |
jboyer-isl |
Could be. I'm trying to work on too many things. |
| 14:58 |
bshum |
What I might have been trying to talk about was what prox was in config.rule_age_hold_protect |
| 14:59 |
bshum |
And I think that's the prox that comes from actor.org_unit_proximity |
| 14:59 |
hopkinsju |
In our case config.hold_matrix_matchpoint.transit_range = 2 should accomplish what we need. Same with number of hops. |
| 14:59 |
jboyer-isl |
yes, that's what I was talking about with the odd counting. (the up and down stuff) |
| 15:00 |
hopkinsju |
Hmm. actor.org_unit_proximity... |
| 15:02 |
bshum |
hopkinsju: So in the examples, you're saying that the library branch A who catalogs for library branch B, has the copies set to circ/own at B and the items still go back to A first? |
| 15:02 |
|
snowball joined #evergreen |
| 15:02 |
hopkinsju |
bshum not exactly. |
| 15:02 |
* bshum |
loves and hates holds logic |
| 15:03 |
hopkinsju |
There are holds placed by patrons at branch A that the new copy should fulfill. |
| 15:03 |
Dyrcona |
Who said there was logic involved. |
| 15:03 |
jboyer-isl |
(I'm going to bow out of this since I don't really think I'm helping by paying partial attention. You're in good hands with bshum!) |
| 15:03 |
* bshum |
happily trots closer and closer to the edge of the huge cliff of doom. |
| 15:04 |
hopkinsju |
Honestly I'm feeling like we might need to take a break from this conversation as well. We are going to get some fresh examples to play with. |
| 15:04 |
* tsbere |
has a basic clue how all of this works, but hasn't been following the discussion |
| 15:04 |
mmorgan |
maybe the problem is the new items are not targeted? |
| 15:04 |
|
DPearl joined #evergreen |
| 15:04 |
hopkinsju |
mmorgan: That pretty much sums it up. |
| 15:04 |
mmorgan |
The checkin modifiers that retarget work only for local holds |
| 15:05 |
mmorgan |
If they manually retarget one of the holds, does it change anything? |
| 15:05 |
hopkinsju |
Negative. |
| 15:06 |
hopkinsju |
TBH I'm not sure what they end up doing. Let me call the library and see what they've done because at this point our examples have been fixed. |
| 15:07 |
|
sseng joined #evergreen |
| 15:07 |
|
ktomita joined #evergreen |
| 15:07 |
DPearl |
Help unconfuse me. I added a column to a database table, changed fm_IDL.xml to include it. Did the autogen. Restarted opensrf services and apache. The field is not present when (from the javascript shell, I do a props(fieldmapper.IDL.fmclasses['bmp'].field_map). I do see the field in /openils/var/web/js/dojo/fieldmapper/fmall.js . What am I missing? |
| 15:09 |
|
ktomita_ joined #evergreen |
| 15:09 |
dbwells |
DPearl: did you also change the fm_IDL.xml in var/web/reports/? |
| 15:09 |
DPearl |
dbwells: negative |
| 15:11 |
DPearl |
dbwells: Is that suggested? |
| 15:11 |
dbwells |
DPearl: some unexpected (i.e. non-reports) parts of EG pull from that IDL, probably because it was conveniently web-accessible. I've been bitten in the past by being lazy and not updating that IDL. |
| 15:12 |
dbwells |
When doing quick and dirty testing of things. |
| 15:12 |
DPearl |
dbwells: I'll give it a try. |
| 15:12 |
|
ktomita joined #evergreen |
| 15:12 |
|
dconnor joined #evergreen |
| 15:14 |
|
ktomita__ joined #evergreen |
| 15:14 |
|
sseng_ joined #evergreen |
| 15:14 |
Bmagic |
Does evergreen have functionality that limits the search for available items on a title level hold to a list of items that were in the system at the time the hold was placed. So when new items are added to the title, they are not included in the targeting process until a new hold is added? |
| 15:15 |
Dyrcona |
Bmagic: No. You want age hold protection that hopkinsju just asked about. |
| 15:16 |
bshum |
Or err, is Bmagic wondering why old holds don't target newly added stuff at first? |
| 15:16 |
* bshum |
isn't sure from the question |
| 15:16 |
Bmagic |
Dyrcona: hopkinsju and I are working on the same issue, new info has brought me to this question |
| 15:16 |
hopkinsju |
We are looking at the same issue yeah |
| 15:16 |
Dyrcona |
If that was the question, then he should have asked that question and not the question that was asked. |
| 15:17 |
Dyrcona |
:) |
| 15:17 |
bshum |
:) |
| 15:17 |
Dyrcona |
Bmagic: The targeter is only going to retarget any single hold once per day, regardless of how often the targeter runs. |
| 15:18 |
bshum |
Basically though, holds don't look for new targets all the time. They only check for potential copies once per day, based on the previous check time |
| 15:18 |
hopkinsju |
I'm looking at action.hold_copy_map and wondering if this is the table that the hold targeter searches through - and if this table is not reevaluated when new copy is added - that is, even though new items that could fulfill the hold are added, the hold targeted isn't considering them because they haven't been added as possible copies to target. |
| 15:18 |
Dyrcona |
So, if a hold x was targeted at 8:00 this morning, anything added after 8:00 won't be considered until tomorrow. |
| 15:18 |
hopkinsju |
Dyrcona: Interesting. |
| 15:19 |
bshum |
Alternatively, if hold X was targeted 8 am yesterday, anything you added today still won't count till 8 am tomorrow. |
| 15:19 |
hopkinsju |
Where is the last checked information stored? |
| 15:19 |
Dyrcona |
This is why the retarget local holds flags exist at checkin. |
| 15:20 |
bshum |
In action.hold_request, the last check time is stored in prev_check_time |
| 15:20 |
Dyrcona |
action.hold_request.prev_check_time |
| 15:20 |
Dyrcona |
heh. |
| 15:20 |
bshum |
:) |
| 15:20 |
Dyrcona |
I had to look it up. |
| 15:20 |
bshum |
Me too. Silly pgAdmin was slow |
| 15:20 |
Dyrcona |
Couldn't remember the field name off the top of my head. |
| 15:20 |
|
ktomita joined #evergreen |
| 15:20 |
bshum |
I couldn't remember if it was prev_checktime or prev_check_time |
| 15:21 |
bshum |
So, basically, once 24 hours has passed the prev_check_time, and whenever the hold_targeter cron job runs, it'll try again. |
| 15:21 |
bshum |
And then update the entry with the new check time |
| 15:22 |
Bmagic |
interesting |
| 15:22 |
bshum |
My understanding is this is a matter of reducing computing load. Otherwise, checking items in all the time and deciding hold targets continuously would be burdensome. |
| 15:22 |
bshum |
(aka, slow to check in). |
| 15:23 |
bshum |
Hence the use of the checkin modifiers to force retargeting when you care about it. And don't mind being slow while it computes all the potential hold targets. |
| 15:23 |
Dyrcona |
you can set prev_check_time to null and I think it'll be picked up the next time hold targeter runs. |
| 15:23 |
tsbere |
Note that the checkin modifier stops looking after it finds a hold that can target, it doesn't retarget all possible holds. |
| 15:24 |
tsbere |
And manual "find another target" in the staff client is the more manual way to ignore the prev_check_time |
| 15:24 |
|
ktomita_ joined #evergreen |
| 15:27 |
|
ktomita joined #evergreen |
| 15:28 |
hopkinsju |
We are looking at the prev_check_time and the hold we are checking hasn't been looked at in 10 days. |
| 15:28 |
hopkinsju |
Something weird is going on. |
| 15:29 |
bshum |
hopkinsju: Remind me which version of Evergreen you guys are on? |
| 15:29 |
hopkinsju |
2.4.1 |
| 15:29 |
mmorgan |
or maybe there haven't been any items to target in the past 10 days? |
| 15:30 |
hopkinsju |
two copies were added on the 21st actually |
| 15:30 |
hopkinsju |
But even still, wouldn't it check regardless? I mean, isn't the point of checking? |
| 15:31 |
Dyrcona |
Is the hold targeter actually running? |
| 15:31 |
hopkinsju |
Dyrcona: yes |
| 15:31 |
bshum |
2.4? Hmm, that's a good question with the hold targeter.... |
| 15:32 |
hopkinsju |
Holds are being targeted all the time. The system is generally working. |
| 15:32 |
bshum |
Given what we know about hold targeting these days. |
| 15:32 |
tsbere |
hopkinsju: And the hold isn't captured (no capture_time) or frozen? |
| 15:32 |
hopkinsju |
Another interesting find is that manually retargeting (Find Another Target) does nothing. |
| 15:33 |
hopkinsju |
What *does* fix it, apparently, is to cancel the existing hold and then create a new hold. Boom, targeted. |
| 15:33 |
|
dconnor joined #evergreen |
| 15:33 |
hopkinsju |
tsbere: Correct. It's not been captured (no capture_time) also not frozen. |
| 15:34 |
|
smyers_ joined #evergreen |
| 15:34 |
|
sseng joined #evergreen |
| 15:34 |
bshum |
hopkinsju: And it's a title hold with the right target? |
| 15:34 |
|
fparks joined #evergreen |
| 15:34 |
|
ktomita_ joined #evergreen |
| 15:34 |
hopkinsju |
bshum: Yes to both |
| 15:35 |
Dyrcona |
hopkinsju: Is the hold filled? |
| 15:35 |
hopkinsju |
We started in the staff client. I've got Bmagic and dluch in a screen sharing session. 2 of us on in the DB and dluch is in the staff client. |
| 15:35 |
hopkinsju |
Dyrcona: The hold has not been filled. You mean that the hold would have been filled without ever being targeted? |
| 15:36 |
jeff |
Quick! Everybody change something different and see if you can figure out who changed what! |
| 15:36 |
* jeff |
ducks |
| 15:36 |
* hopkinsju |
throws something |
| 15:36 |
|
smyers__ joined #evergreen |
| 15:36 |
hopkinsju |
DROP TABLE ... |
| 15:36 |
* hopkinsju |
solves problems |
| 15:36 |
Dyrcona |
hopskinju: If there is a value in action.hold_request.fulfillment_time, then EG thinks it is filled regardless of what staff have or have not done. |
| 15:37 |
dluch |
/me laughs hysterically |
| 15:37 |
jeff |
Has anyone else considered making standing penalty blocks different based on patron profile? |
| 15:37 |
hopkinsju |
lol |
| 15:37 |
hopkinsju |
Dyrcona: fulfillment_time is null |
| 15:38 |
bshum |
hopkinsju: Is the patron a good patron? i.e. still allowed to have the item? |
| 15:38 |
Dyrcona |
hopkinsju: Check if the hold is canceled or frozen, also what bshum said. |
| 15:38 |
Dyrcona |
jeff: Only theoretically, I've never considered doing it for real. |
| 15:39 |
Dyrcona |
The type of hold might be a factor, too. |
| 15:39 |
Dyrcona |
Holds are so simple.... :p |
| 15:42 |
hopkinsju |
bshum: AFACT the user is all good. Not expired, in good standing, etc, etc. |
| 15:42 |
hopkinsju |
I'm still baffled about the prev_check_time being 2014-01-16 08:04:29-06 |
| 15:44 |
* Dyrcona |
doesn't have enough information to be baffled. There are still too many unknowns, so your system may be doing exactly what it is supposed to. |
| 15:45 |
jeff |
Dyrcona: thanks. i might have cause to try. not sure i want to do it with a cronjob pseudo-system ausp. :P |
| 15:46 |
Dyrcona |
jeff: We used to have something like different penalties for different groups set up, but they were mostly the same. |
| 15:46 |
Dyrcona |
jeff: I should have added on our previous ILS. |
| 15:47 |
bshum |
hopkinsju: For those holds that wigged out |
| 15:48 |
bshum |
Is there any entries in action.hold_copy_map for those hold IDs? |
| 15:48 |
hopkinsju |
bshum: Yes, but... |
| 15:49 |
hopkinsju |
Say a title had 1 copy from way back, and then the library added 2 more a few days ago. action.hold_copy_map has just the 1 entry. |
| 15:49 |
hopkinsju |
I'm looking at that, and I think the answer is that they haven't been rechecked. |
| 15:50 |
jeff |
Hrm. I wonder about the implications of changing config.circ_matrix_test.circulate from mapping to COPY_CIRC_NOT_ALLOWED to some new event. |
| 15:50 |
hopkinsju |
What process is responsible for looking at prev_check_time and going out to look for new copies? |
| 15:50 |
jeff |
Seems like it would benefit from being more specific. |
| 15:52 |
Dyrcona |
hopkinsju: the hold targeter. |
| 15:52 |
Dyrcona |
hopkinsju: Also, are the new copies in a status that can fill a hold? |
| 15:52 |
hopkinsju |
Dyrcona: They are Available |
| 15:53 |
jeff |
Dyrcona: compliment grp_penalty_threshold with grp_penalty_block_list or something. Not sure. |
| 15:53 |
hopkinsju |
Our hold targeted runs almost constantly. We nulled the prev_check_time and the hold targeted has run and completed several times since then and still hasn't repopulated the prev_check_time column. |
| 15:54 |
Dyrcona |
hopkinsju: Did you check the hold itself to see if it is canceled or frozen? |
| 15:54 |
hopkinsju |
Dyrcona: yes, it's all good |
| 15:55 |
bshum |
Well, so far, in my own system, I've found 11 holds in my action.hold_request table that show up as prev_check_time < '2014-01-26' (i.e. yesterday) that haven't been filled, captured, canceled, thawed, whatever. |
| 15:55 |
bshum |
And all of them target deleted bibs. Thanks alot Evergreen. |
| 15:55 |
bshum |
(oh and aren't expired) |
| 15:56 |
hopkinsju |
http://pastebin.com/fCTbA3PJ |
| 15:56 |
bshum |
So I can't prove any weirdness in my system :( |
| 15:58 |
Dyrcona |
hopkinsju: That hold has a null prev_check_time. |
| 15:58 |
bshum |
Probably not it, but is 3004580462 a mint condition item? |
| 15:59 |
hopkinsju |
Dyrcona: Right, it's the one we null'd by hand to see if the hold targeter would re-check |
| 15:59 |
hopkinsju |
It had a prev_check_time of 01/16 |
| 15:59 |
bshum |
Or, otherwise, can you paste us an output of the values for that item in asset.copy |
| 15:59 |
tsbere |
We have quite a few oddities...117 or so. Hmmm.... |
| 16:01 |
hopkinsju |
http://pastebin.com/vZXCac55 |
| 16:01 |
hopkinsju |
It is mint_condition = 't' |
| 16:02 |
bshum |
Just checking, didn't expect it to be related. |
| 16:02 |
tsbere |
Ok, one hold in our system is doing this on a non-deleted bib. The rest are on deleted bibs. |
| 16:02 |
tsbere |
Though in this case it is "created a few days ago and not getting checked" |
| 16:02 |
hopkinsju |
tsbere: What query are you running to get that result? |
| 16:03 |
bshum |
Every single hold I have that's stuck and not doing anything seems pointed at deleted bibs. I would have expected those to die out by now with untargeted expiration or similar. |
| 16:04 |
tsbere |
SELECT ahr.* FROM action.hold_request ahr JOIN reporter.hold_request_record rhrr ON ahr.id = rhrr.id JOIN biblio.record_entry bre ON rhrr.bib_record = bre.id WHERE ((prev_check_time IS NULL AND request_time < '2014-01-26') OR prev_check_time < '2014-01-26') AND cancel_time IS NULL AND capture_time IS NULL AND fulfillment_time IS NULL AND NOT frozen AND NOT bre.deleted |
| 16:04 |
hopkinsju |
2448 records... |
| 16:04 |
tsbere |
And the one hold I get from that query I have yet to figure out what is going on |
| 16:06 |
tsbere |
Oh, this might be age protection weirdness |
| 16:06 |
tsbere |
Two copies, one is "on order", the other is age protected and created only a few days ago. |
| 16:07 |
tsbere |
and....it went away from the query, so not that. But then again, that also means "not a problem" |
| 16:10 |
* tsbere |
wonders if he should do something about the 114 deleted bib holds sitting here >_> |
| 16:11 |
Dyrcona |
I was tooling 'round in my dev database, but don't think the data is representative. |
| 16:12 |
Dyrcona |
It hasn't run the hold targeter since the database was reloaded last week. |
| 16:20 |
hopkinsju |
There has to be another place the hold targeter looks at before it rechecks. Everything in action.hold_request tells me it should be rechecked, but it just isn't. All of the 2448 rows returned by tsbere's query belong to the system we last migrated. |
| 16:21 |
|
krvmga joined #evergreen |
| 16:21 |
tsbere |
hopkinsju: For fun, the hold targeter may be checking, and bailing mid-run on the hold |
| 16:22 |
hopkinsju |
The prev_check_time of the 01/16 was 3 days after we migrated though. So the thing was checking at some point... then stopped. |
| 16:22 |
jboyer-isl |
I'm told there's a page someone made to use Google as a better LaunchPad search. Does anyone have it handy? |
| 16:22 |
hopkinsju |
tsbere: Bmagic is looking at troubleshooting the hold targeter run itself |
| 16:22 |
Dyrcona |
Does the hold targeter work like the fine generator? Can you run the method via srfsh with a hold id? |
| 16:23 |
hopkinsju |
Dyrcona: We were thinking so, Bmagic was talking about doing that. |
| 16:23 |
Bmagic |
yeah, just need syntax I guess |
| 16:25 |
* hopkinsju |
lightbulb |
| 16:26 |
hopkinsju |
I just discovered action.unfulfilled_hold_list |
| 16:26 |
hopkinsju |
If an entry *does not* exist in that table for a particular hold id, I'm guessing the hold targeter wouldn't recheck regardless |
| 16:27 |
bshum |
Interesting. |
| 16:27 |
hopkinsju |
I'm feeling pretty good about this... |
| 16:35 |
tsbere |
hopkinsju: Actually, I believe you are incorrect |
| 16:35 |
hopkinsju |
We know that the holds that are currently there are the problem. Removing them and creating new ones solves the issue. What we need to do is have a 'reset button' for the 2448 problem holds. I suppose we could just delete them and recreate, but that seems like overkill that could possibly leave a bunch of cruft. |
| 16:35 |
hopkinsju |
tsbere: I agree |
| 16:36 |
hopkinsju |
tsbere: The fact that the table requires a target_copy gave it away. |
| 16:36 |
tsbere |
hopkinsju: I think to tell you anything I would need actual rows. <_< |
| 16:37 |
hopkinsju |
tsbere: from which table? |
| 16:37 |
tsbere |
action.hold_request |
| 16:38 |
hopkinsju |
tsbere: I think the history of the problem is to blame more than the current state. I may be wrong, but if you look at that last paste you can see an ahr row. |
| 16:40 |
hopkinsju |
We inserted a bunch of rows into ahr and then later went back and made some "fixes" - Bmagic inserted them with current_copy already filled out which was incorrect. Our working-theory-this-minute is that the hold targeter got to those rows and made changes somewhere else that, even after the current_copy was removed, keep it from rechecking. |
| 16:41 |
tsbere |
hopkinsju: Have you considered that the problem is the requestor? |
| 16:42 |
hopkinsju |
tsbere: no |
| 16:42 |
tsbere |
I know that I have, in my dev machine, screwed things up by having a deleted requestor owning holds. |
| 16:43 |
hopkinsju |
Well usr 1 isn't deleted. We always set the requestor to 1 when importing holds. |
| 16:46 |
tsbere |
hopkinsju: For that matter, I would double-check the selection_ou. Most of our holds have that the same as the pickup_lib or the request_lib, I note your example matches neither... |
| 16:47 |
Dyrcona |
yeah, I noticed that and almost asked if the pickup ou could receive holds from the selection ou, but then was less sure that it mattered. |
| 16:47 |
tsbere |
(though not all, granted, but not knowing your tree I can't say much there) |
| 16:52 |
|
ericar joined #evergreen |
| 17:15 |
|
ktomita joined #evergreen |
| 17:26 |
|
dac joined #evergreen |
| 17:42 |
|
ktomita__ joined #evergreen |
| 17:42 |
|
ktomita___ joined #evergreen |
| 17:43 |
|
mmorgan left #evergreen |
| 17:51 |
|
dMiller__ joined #evergreen |
| 17:54 |
|
gsams joined #evergreen |
| 18:00 |
|
mrpeters left #evergreen |
| 18:44 |
|
dac joined #evergreen |
| 18:46 |
|
jeffdavi1 joined #evergreen |
| 18:47 |
|
dconnor_ joined #evergreen |
| 18:49 |
|
jeffdavis joined #evergreen |
| 19:05 |
|
GeoffSams joined #evergreen |
| 20:01 |
|
schatz joined #evergreen |
| 21:03 |
|
smyers_ joined #evergreen |
| 23:31 |
|
b_bonner_ joined #evergreen |
| 23:44 |
|
stevenyvr joined #evergreen |
