| Time |
Nick |
Message |
| 03:18 |
|
gsams joined #evergreen |
| 05:19 |
|
gsams_ joined #evergreen |
| 07:11 |
|
gsams joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:24 |
|
rlefaive joined #evergreen |
| 07:33 |
|
rlefaive joined #evergreen |
| 07:49 |
|
mrpeters joined #evergreen |
| 07:59 |
|
ericar joined #evergreen |
| 08:41 |
|
collum joined #evergreen |
| 08:54 |
|
bos20k joined #evergreen |
| 08:54 |
|
mmorgan joined #evergreen |
| 09:00 |
|
Dyrcona joined #evergreen |
| 09:05 |
|
bos20k joined #evergreen |
| 09:21 |
|
yboston joined #evergreen |
| 09:27 |
|
yboston joined #evergreen |
| 10:01 |
|
mmorgan1 joined #evergreen |
| 10:14 |
Dyrcona |
Want to really bloat your odt files? Just check the "Embed fonts in the document" option in the File -> Properties dialog. ;) |
| 10:15 |
* Dyrcona |
wonders if Word or Google Docs can work with the embedded fonts. |
| 10:16 |
|
sard joined #evergreen |
| 10:16 |
|
ejk joined #evergreen |
| 10:17 |
|
justdoglet joined #evergreen |
| 10:20 |
Dyrcona |
Well, Google doesn't work with embedded fonts.. |
| 10:55 |
|
mmorgan joined #evergreen |
| 11:17 |
|
sandbergja joined #evergreen |
| 12:38 |
gsams |
I have a library asking if automatic/automated renewal is a possibility in Evergreen. Seems we've had a few libraries in the area roll out similar features recently. |
| 12:39 |
gsams |
Other than a few conversations here and there I wasn't able to find anything definitive. Is this possible? |
| 12:42 |
jeff |
heh. i was thinking about automatic renewal over the weekend, actually. :-) |
| 12:44 |
gsams |
I've been looking into the idea for a few weeks, and overall I think it'd be a smart move for a few of our libraries. |
| 12:45 |
jeff |
gsams: i'm not aware of any libraries doing automatic renewal using Evergreen, and while you might be able to implement something of the sort with action/triggers, I'm not aware of any features specific to that functionality in Evergreen |
| 12:46 |
gsams |
jeff: If it can be cleanly done with action/triggers that'd be good enough for me honestly. I've been living in there recently. |
| 12:46 |
gsams |
I'll never master them, but that's alright. |
| 12:48 |
jeff |
Even if it's possible (I haven't looked/tried), I think it's the kind of thing that would benefit from more effort in order to be a really useful thing. |
| 12:48 |
jeff |
That sentence is vague and poorly-phrased, but hopefully gets the point across. |
| 12:49 |
gsams |
yeah, I'm not sure that it is currently possible. But you are right, there is a certain level of nuance required to make it truly effective. |
| 13:12 |
csharp |
gsams: I'm personally very interested in that feature idea, but I don't know if it would have support from our libraries |
| 13:12 |
tsbere |
gsams / jeff: For doing automatic renewal with A/T I would suspect you would need a new function/module to do the renewal and a new validator....and I am not sure how to do "we renewed/couldn't renew" notifications in that case. |
| 13:13 |
jeff |
tsbere: right, which is where the "would benefit from more effort [even if possible using A/T]" |
| 13:13 |
* tsbere |
wonders if it would be better to have the renewal be a new cronjob task that creates "we renewed/couldn't renew" A/T events like the "hold is ready for pickup" events are made |
| 13:13 |
jeff |
would likely need to be paired with "don't allow renewals if item needed for hold", etc. |
| 13:14 |
jeff |
And I'd also like to consider "renew up to X days early without 'losing time'" |
| 13:15 |
jeff |
but there are some other things that will likely come first. |
| 13:16 |
tsbere |
jeff: Perhaps the latter one should be "within X% of the duration rule"? Either that or specify it on the duration rules...hourlies and all. |
| 13:16 |
* jeff |
nods |
| 13:16 |
jeff |
similar for pre-overdue courtesy reminders. on a four day circ, a '3 days before due' courtesy notice is almost worthless. |
| 13:16 |
jeff |
annoying, in many cases. :-) |
| 13:17 |
tsbere |
Very true. Luckily we don't circulate things for a time period that would trigger that. :) |
| 13:37 |
gsams |
csharp: That seemed to be what most of the discussion around the topic seemed to imply. People generally liked the idea but there wasn't anyone pushing for development really. |
| 13:39 |
jeff |
pre-warning of "i'm not going to be able to renew this item because it is needed for a hold" is something i'd like to add as an option also, independent of auto-renew, but almost a requirement for auto-renew. |
| 13:43 |
csharp |
I would personally love it as a patron if there was an attempt to automatically renew what I have out and I'm notified if renewal fails |
| 13:43 |
csharp |
most of the fines I pay are on items I forget to renew |
| 13:43 |
gsams |
For me, that's an absolute requirement for the purposes of auto renewal |
| 13:44 |
Dyrcona |
Isn't that what Library Elf is for? ;) |
| 13:44 |
jeff |
I've also been re-thinking the timing of courtesy vs overdue notices. Three days ahead of due isn't nearly enough urgency. :-) |
| 13:45 |
jeff |
But notice on/after due date with a grace period... that's a little more urgent. |
| 13:45 |
* Dyrcona |
experimented with two scripts to auto renew items for himself and his family, but never really used them much. |
| 13:45 |
csharp |
ours get notified 2 days before due date, then 10 days after - we're looking at adding another notice sooner after the due date |
| 13:47 |
jeff |
we have libraries that are closed sunday and monday, so you could return an item saturday evening, then it isn't checked in until tuesday morning (backdated to saturday) |
| 13:48 |
jeff |
of course, i should run actual numbers (i already know them to be non-zero, but that doesn't say much) before building too much around that scenario. |
| 13:48 |
jeff |
but it's one reason we don't do due+1 phone calls. |
| 13:49 |
|
tsbere joined #evergreen |
| 13:49 |
jeff |
but due+3 phone calls might be reasonable. |
| 14:10 |
phasefx |
hey guys, I'm just curious, what are some real world scenarios for wanting to have multiple active cards for a given account? |
| 14:11 |
* Dyrcona |
can't think of any good ones off the top of his head but believes MVLC has some such accounts. |
| 14:12 |
csharp |
phasefx: I can't come up with any |
| 14:12 |
bshum |
No good reasons. But that doesn't mean there are not good ones... |
| 14:13 |
bshum |
Or bad reasons |
| 14:13 |
phasefx |
I was thinking maybe keeping alive some legacy system's way of having a family or classroom group; but I can't think of a better reason |
| 14:14 |
Bmagic |
I could imagine a scenario where the patron lost their old card, got a new one, then found the old one |
| 14:14 |
tsbere |
phasefx: Off the top of my head I can think of a couple. "School" accounts with multiple teachers carrying cards (so you can turn one off without affecting them all) is the best of them. |
| 14:15 |
tsbere |
phasefx: Worst of them is "I want to access more than one library's subscription for a third party service that uses barcode prefix to authenticate, so I need multiple cards!" - Though a single "test account" with a pile of cards for such a thing is less of a bad thing IMO. |
| 14:16 |
phasefx |
mmm |
| 14:16 |
phasefx |
thanks! |
| 14:17 |
tsbere |
I have also heard of "I want my secretary to have a card on my account so that she can pick my holds up for me" and "parent wants a card for each kid so they can pick the holds up, but we don't have a duplicator so we needed new numbers" |
| 14:18 |
tsbere |
phasefx: Oh, and at least one library I helped write a query for a while back had a problem where half of the branches had barcode scanners not outputting the check digit, but the other half did, so they wanted *both* variants on each account. |
| 14:21 |
* tsbere |
isn't sure how they resolved the *item* barcodes in that case, but can only assume they used different barcode formats for the two or something |
| 14:26 |
jeff |
phasefx: we support multiple active cards because we allow people to use drivers license or library card |
| 14:27 |
* tsbere |
always forgets that one because of laws preventing MVLC from supporting that |
| 14:27 |
jeff |
tsbere: weird. which laws, out of curiosity? |
| 14:28 |
phasefx |
jeff: ah |
| 14:28 |
tsbere |
jeff: State laws about storing certain personal information such that it can be retrieved by people who don't need to know, with drivers license being equiv to social security number |
| 14:29 |
jeff |
amusing, since in so many states (until very recently) license numbers were based on name + dob |
| 14:29 |
tsbere |
If we could lock it out so that you couldn't look it up, just check against it, we would probably be good, but we don't have that ability right now. |
| 14:30 |
* jeff |
nods |
| 14:30 |
* phasefx |
received a letter once where they wanted to suspend his license.. it was someone else with the same DL number |
| 14:32 |
jeff |
that reminds me of another item from this weekend: fixing some of the remaining places where multiple barcodes can break certain poor assumptions in the SIP code. |
| 14:33 |
tsbere |
jeff: Actually, MA drivers license numbers used to *be* your SSN. |
| 14:34 |
phasefx |
you're all welcome for the tangents :) |
| 14:34 |
* tsbere |
had to check a box saying he wanted it to *not* be his SSN when he got his license, in fact |
| 14:34 |
tsbere |
Now they have changed it, but that used to be the rule |
| 14:34 |
jeff |
interesting. thanks for the history. :-) |
| 14:35 |
tsbere |
Makes the "drivers license == social security number in the privacy law" more understandable, though now I think they could let up on that a bit... |
| 14:35 |
|
ericar joined #evergreen |
| 14:47 |
|
bos20k joined #evergreen |
| 15:06 |
dbs |
jeez. currently at 21 hours for our bib reingest _with_ the "faster reingest" function! Ridiculous. |
| 15:06 |
bshum |
That is a *long* time |
| 15:07 |
dbs |
(this is with the master "popularity metrics" commits in place) |
| 15:08 |
dbs |
And we do have 2.4 million non-deleted bibs. but still. 21 hours for one part of an upgrade is not a great metric. |
| 15:09 |
dbs |
This is just our dev instance, happily. |
| 15:09 |
dbs |
and our production instance has the same RAM/SSD/CPU, so at least we can plan. |
| 15:15 |
|
jvwoolf joined #evergreen |
| 15:17 |
mmorgan |
dbs: curious, what do you get from select count(*) from asset.uri |
| 15:26 |
jeff |
dbs: are you using pingest to speed things along? |
| 15:26 |
dbs |
mmorgan: 2162446; |
| 15:27 |
dbs |
actually the part I'm currently on is just metabib.reingest_record_attributes(), not a full reingest. |
| 15:27 |
* jeff |
nods |
| 15:28 |
dbs |
It's the tail end of the 2.9-2.10 "reingest for 655 first, then reingest the mra's" |
| 15:28 |
dbs |
jeff: nope |
| 15:29 |
jeff |
I think it took us about 4.5 hours using pingest with --max-child 28 for probably ~450k bibs |
| 15:29 |
jeff |
that was *before* the dbwells speed fixes, though |
| 15:30 |
jeff |
./pingest.pl --skip-browse --skip-search --skip-facets --max-child 28 --batch-size 1000 |
| 15:30 |
dbs |
jeff: probably would be a good idea to make pingest a stock bin and use that instead. |
| 15:30 |
jeff |
real 275m1.341s |
| 15:31 |
jeff |
sitka did their upgrade the same weekend, and i think allocated 48h to the attr reingest. i do not recall if it took that long in the end. |
| 15:31 |
jeff |
but in both of those cases, it was pre-speed-fixes and pre-popularity-metric |
| 15:31 |
jeff |
(though i don't know without looking if the popularity metric bits would affect an attr-only ingest at all) |
| 15:32 |
dbwells |
worth noting that the "speed fixes" only get us back close to where we were circa 2.7 or 2.8, so slow -> slower -> yay, we're slow again |
| 15:32 |
* dbs |
is trying to do the 2.11 thing, both for providing actual testing and because this is probably our last upgrade for quite a while. upgrading from 2.7 |
| 15:32 |
dbs |
dbwells__ |
| 15:32 |
dbs |
dbwells++ # i meant! |
| 15:34 |
jeff |
heh |
| 15:34 |
jeff |
and then there's that moment when i confuse a mozilla bugzilla browser tab for a text editor window... |
| 15:36 |
dbs |
at least we have time-based releases, I'm dealing with another project that's still feature-based and holy hell is it madness. "Yes we've merged part of this feature but there's 10 blockers associated with it needing volunteers before we can cut the next release" |
| 15:36 |
dbs |
(and they only support the latest release, naturally) |
| 15:36 |
jeff |
naturally. |
| 15:36 |
Bmagic |
sounds like my Friday night! |
| 15:37 |
dbs |
heh |
| 15:38 |
gsams |
I'm hoping to make the jump from 2.7 upward by the end of the year, as long as things fall in place properly. |
| 15:57 |
miker |
dbs: popularity metric shouldn't interact with reingest at all |
| 16:01 |
* Dyrcona |
doesn't recall any reingest for testing popularity matrix. |
| 16:02 |
Dyrcona |
berick has suggested making pingest a standard bin. I'm for it, but my version and his have diverged a bit. |
| 16:02 |
Dyrcona |
To the point where a merge is nontrivial. |
| 16:16 |
jeff |
looking at 2.8-2.10 docs, minimum supported postgresql version has been 9.1 for a while, with the readme/install recommending 9.3 (though the 2.10 release notes recommend "9.2 or later" in mild conflict with the readme/install). this does leave us with Evergreen 2.9 and 2.10's required minimum PostgreSQL version (9.1) going EOL before the Evergreen release itself is out of support, but... we're getting better. :-) |
| 16:16 |
jeff |
(apropos of almost nothing) |
| 16:17 |
bshum |
Really? I thought we were getting better with all that. |
| 16:17 |
Dyrcona |
On th plus side, 2.11 is supposed to bump the minimum to 9.3, IIRC. |
| 16:17 |
jeff |
bshum: I just said that we were getting better. Pay attention! ;-) |
| 16:17 |
Dyrcona |
;) |
| 16:17 |
jeff |
Dyrcona: yes. |
| 16:18 |
bshum |
Oh hmm, September 2016. Good times. |
| 16:18 |
jeff |
and it isn't like we've been recommending 9.1 all this time, either. |
| 16:22 |
bshum |
Do any currently supported OSes even ship with 9.1 anymore? |
| 16:22 |
bshum |
Oh, maybe Wheezy? |
| 16:22 |
bshum |
Anywho |
| 16:23 |
bshum |
Right direction. |
| 16:23 |
bshum |
KILL IT WITH FIRE! |
| 16:29 |
* Dyrcona |
recalls needing to look at some branches that remove support for Precise Pangolin. |
| 16:41 |
dbs |
miker: yeah, just noting the currency of our test server's database schema |
| 17:07 |
|
mmorgan left #evergreen |
| 17:10 |
|
jvwoolf left #evergreen |
| 18:21 |
|
gsams_ joined #evergreen |
| 19:12 |
|
dcook joined #evergreen |
| 19:53 |
|
_adb left #evergreen |
| 19:55 |
|
_adb joined #evergreen |
| 20:11 |
bshum |
dbs: Just eyeballing your new patch for bug 1608711 and I'm thinking there isn't much harm in backporting it to all supported series. |
| 20:11 |
pinesol_green |
Launchpad bug 1608711 in Evergreen "Update "seller" property from schema.org to "offeredBy"" [Undecided,New] https://launchpad.net/bugs/1608711 |
| 20:12 |
bshum |
But if you think it should be master only, I'll keep it there. |
| 20:12 |
* bshum |
assumes someone else might get to merging it first anyways |
| 22:41 |
|
gsams joined #evergreen |
| 22:51 |
dbs |
bshum: thanks, yeah, I was being conservative, but it would be good for all series |
| 22:51 |
dbs |
28 hours and counting for this mra reingest, sigh |
| 22:52 |
jeff |
only 20 more to go. ;-) |
