| Time |
Nick |
Message |
| 00:53 |
|
gsams joined #evergreen |
| 02:03 |
|
Bmagic joined #evergreen |
| 02:03 |
|
hopkinsju joined #evergreen |
| 02:12 |
|
hopkinsju joined #evergreen |
| 02:13 |
|
Bmagic joined #evergreen |
| 05:39 |
|
gsams_ joined #evergreen |
| 06:01 |
|
phasefx joined #evergreen |
| 06:01 |
|
miker joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:36 |
|
mrpeters joined #evergreen |
| 07:45 |
|
kmlussier joined #evergreen |
| 08:14 |
|
ericar joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:47 |
|
rlefaive joined #evergreen |
| 08:51 |
|
Dyrcona joined #evergreen |
| 09:08 |
|
bos20k joined #evergreen |
| 09:21 |
|
maryj joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 09:54 |
|
ericar_ joined #evergreen |
| 10:10 |
|
jwoodard joined #evergreen |
| 10:11 |
* mmorgan |
has always been curious about this: What is the purpose of the script_test field in config.circ_matrix_matchpoint? |
| 10:12 |
berick |
mmorgan: it does nothing today. the hope was to support optional/additional script-based tests, to cover logic that's not supported directly in the circ matrix. |
| 10:13 |
berick |
similar to the old-school circ rules, which were script based and quite powerful IF you knew what you were doing |
| 10:13 |
tsbere |
I was once going to code that in when I re-wrote things (probably as a "call this DB function" instead though) but I am not likely to re-write circ stuff anytime soon. If ever. |
| 10:14 |
mmorgan |
Ah. I was wondering if it was a vestige of the past, or a placeholder for the future. A little bit of both, I guess! |
| 10:20 |
jeff |
plv8! |
| 10:27 |
JBoyer |
Re: circ_matrix_matchpoint, I'm thinking of adding item stat cat and values to allow more attributes (like new (separate from an item's age, don't care about replacement copies for instance), or "on a bestseller list", that kind of thing). Anyone have an opinion on that before I get too deep into it? |
| 10:27 |
JBoyer |
I'm also planning an LP bug, but since it's already come up today... |
| 10:30 |
jeff |
Is the goal to make it as difficult as possible for staff and patrons to understand circulation policies? ;-) |
| 10:30 |
bshum |
Maybe having that description field added would be handy |
| 10:30 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1545115 |
| 10:31 |
pinesol_green |
Launchpad bug 1545115 in Evergreen "config.circ_matrix_matchpoint and config.hold_matrix_matchpoint need a description field" [Wishlist,New] |
| 10:31 |
bshum |
Still wip by rhamby, but if we're all thinking about touching the matrix tables |
| 10:32 |
rhamby |
That was a bit while bach bshum but at that time it tested fine in master for me but I don't think anyone else test drove it. |
| 10:32 |
rhamby |
back even. Though some bach would make good listening right now. |
| 10:34 |
rhamby |
jeff: I thought about making a patch to change all circ matrix rules match strange unicode and require people to use a 1956 new york phone book as a key to decrypt it but never got around to it |
| 10:36 |
jeff |
JBoyer: joking aside, what did you have in mind for applying the new feature? |
| 10:38 |
tsbere |
JBoyer: I personally think you are going to have issues there, but I have ideas for how to implement. But I suspect other things already there would be better choices. <_< |
| 10:38 |
JBoyer |
jeff, Currently we have multiple circ mods like so: dvd, dvd new, dvd r-rated, dvd r-rated new, and so on. I want to remove the new-ness and r-rated-ness and make them stat cats that can just be applied to a 'dvd' circ mod'd item. |
| 10:39 |
JBoyer |
Same for bestseller. Bestselling what? book, audiobook, etc? the circ mod would be the actual item type and the stat cat would say it's a bestseller. |
| 10:40 |
tsbere |
JBoyer: If your circ rules depend on the info then I think the circ mod is the way to go, honestly. If it is just for reporting go nuts with stat cats. |
| 10:41 |
JBoyer |
tsbere, yeah, it's the circ rules. No one seems to want to fool with stat cats for reporting purposes, and I'm not going to try to make them. :-/ |
| 10:42 |
jeff |
JBoyer: so it's mostly driven by a desire to avoid circ modifier bloat? |
| 10:43 |
JBoyer |
Basically. |
| 10:43 |
tsbere |
JBoyer: Do you have copy locations that could help with some of that? I believe they are already in the circ rules. |
| 10:43 |
jeff |
that was going to be my next question, but i was checking to see if we currently match on location. :-) |
| 10:43 |
* mmorgan |
just wanted to mention, it would be most useful for any changes made to circ_matrix_matchpoint to also be made to hold_matrix_matchpoint |
| 10:44 |
JBoyer |
tsbere, we have a single, shared set of ccmm's for all 110 libraries, so I can't use any locations. |
| 10:44 |
tsbere |
JBoyer: Given that generally libraries can mess with the contents of stat cats as well I would think that could be problematic as well, though. So... |
| 10:44 |
JBoyer |
mmorgan, I figured. ;) (There's also 'bestseller no hold' whose very existence has infuriated me to no end...) |
| 10:45 |
JBoyer |
tsbere, ah, but since I make all of the rules, the only stat cats that count are the ones specified at the consortium level and that don't allow free-text. :) |
| 10:45 |
JBoyer |
(no one has access to ccmm editing here) |
| 10:45 |
tsbere |
JBoyer: Well, given that you are talking asset stat cats and all they all don't allow free-text ;) |
| 10:46 |
JBoyer |
Ah, it's been a while. I didn't realize they didn't allow that. Just as well! |
| 10:47 |
tsbere |
Makes implementation easier in some ways, but I still think you should stick with circ mods. Circ mod bloat is, IMO, much better than adding stat cats into the mix on circ rules. |
| 10:51 |
JBoyer |
Possibly. When only allowing 3-4 options it wouldn't be so bad, though I suppose it could cause complete confusion at those locations where each library is allowed to do their own thing... |
| 10:59 |
|
rlefaive joined #evergreen |
| 11:00 |
jeff |
would pattern matching on circ modifier help? |
| 11:01 |
jeff |
(without regard to current implementation constraints) |
| 11:02 |
jeff |
i think the closest thing we have here is a proliferation of FOO + FOO-JUVENILE, where the only difference at this point is the daily fines. |
| 11:03 |
jeff |
we could probably do that differently even with the current implementation, but i haven't looked into it lately. |
| 11:05 |
* tsbere |
wanted to implement regex matching on circ mods in his likely not going to happen rewrite too |
| 11:05 |
mmorgan |
How about a circ modifier hierarchy? |
| 11:05 |
tsbere |
Though I wanted it for "I don't care about the holdable flag at the end in the circ matrix or anything before that in the hold matrix" purposes |
| 11:07 |
JBoyer |
I'm not sure regex matching would help. |
| 11:08 |
JBoyer |
mmorgan, what would that look like, multiple circ mods on items or something else? |
| 11:09 |
tsbere |
JBoyer: I think she means "dvd is the parent of dvd-bestseller, so dvd-bestseller implies dvd" type deal |
| 11:09 |
mmorgan |
JBoyer: Just brainstorming, but you could have Book at the top of the hierarchy, and a level below that: Bestseller, Local History, etc. |
| 11:10 |
* tsbere |
would think the regex would be better: '^.*bestseller.*$' matches any with bestseller, '^.*dvd.*$' matches any with dvd, so dvd-besteller would fall under both categories |
| 11:12 |
mmorgan |
You could have a general rule for Book, but add rules for special cases. Summer Reading is a good example. |
| 11:13 |
jeff |
what would you use a summer reading circ modifier for? |
| 11:13 |
kmlussier |
mmorgan's multiple circ modifier idea also popped into my mind when people started talking about a regex. |
| 11:13 |
JBoyer |
This change wouldn't really simplify our ccmm that much, because there isn't a single duration rule used for all new or bestseller items. it would still depend on the combination of circ mod (book) plus stat cat/sub-circ mod/etc. (bestseller) |
| 11:14 |
miker |
JBoyer: crazy thought ... controlled "tags" on copies. that is, something halfway between org-owned containers and stat cats. mentioning because of reasons... |
| 11:14 |
tsbere |
jeff: From talking with people our libraries have considered locally holdable and slightly shorter/longer duration (depending on their view), and sometimes "not renewable". |
| 11:14 |
mmorgan |
jeff: Summer Reading items circulate differently - in the summer. Shorter loan periods, no holds, or no transits for holds. But they're still books. |
| 11:15 |
jeff |
interesting. |
| 11:16 |
jeff |
I'm brought back to my earlier offhand remark about making things as difficult to understand as possible... |
| 11:16 |
* tsbere |
wonders if he is going to have issues with PG 9.5 on this secondary DB server |
| 11:16 |
mmorgan |
jeff: Surely a circ modifier hierarchy would help in that regard ;-) |
| 11:17 |
tsbere |
mmorgan: Personally, I think a circ modifier hierarchy would make things *worse*. :P |
| 11:18 |
mmorgan |
We already make use of the hierarchical structure of org units and users in our circ policies, so I can see how it would fit in some cases. |
| 11:18 |
mmorgan |
Not advocating for it necessarily. |
| 11:19 |
tsbere |
mmorgan: yea, but do bestselling dvds belong under "Bestseller" or "DVD"? The "likely belongs to multiple groups" aspect makes things more confusing, not less, IMO. |
| 11:20 |
JBoyer |
miker, Your ideas are intriguing to me and I wish to subscribe to your newsletter. |
| 11:20 |
* mmorgan |
would put bestseller under dvd. |
| 11:21 |
mmorgan |
But then, we come from a history of format based "circ modifier" type objects. |
| 11:25 |
mmorgan |
Libraries like to get stats based on circ modifier. Right now we have modifiers like Book, Rental Book, Summer Reading... to accomodate different circ rules. |
| 11:26 |
JBoyer |
mmorgan, the only trouble I see with a hierarchy is that there could be a lot of repetition. book/bestseller book/new audiobook/bestseller audiobook/new etc. |
| 11:27 |
JBoyer |
duplication, I mean. |
| 11:27 |
|
maryj_ joined #evergreen |
| 11:29 |
mmorgan |
JBoyer: True. How do folks generally handle rules for new, bestseller in different formats currently? |
| 11:31 |
miker |
JBoyer: this is derived from the upcoming plan for "digital book plates". a new construct that looks like the container infrastructure (specifically, item containers) but the owner is an org instead of a user. call them "tags" for the purpose of this. the tag is "applied" to items by a mapping table (/a la/ a container.copy_bucket_item analog), with integration in the copy editor, and maybe some sort of batch UI that accepts a file of barcodes. tags |
| 11:31 |
miker |
have types, like buckets, and names that may be searchable (will be, for digital book plates). behavior is tied to the tag type, so imagine a circ (or hold, or circAndHold) tag type, with tags applied to copies. then, circ/hold rules allow match constraints to sets of tags. I think ANDed is enough, personally. that would work in a way similar to the config.circ_mod_test infrastructure, but without the items_out stuff (so, simpler. just tag inclusion) |
| 11:35 |
JBoyer |
mmorgan, we have just plain bestseller with no further specification, and book new, dvd new, audiobook new, etc. :-/ |
| 11:35 |
miker |
and, of course, the config.circ_matrix_circ_mod_test stuff is post-match ... this would be pre-match, or, "must have these tags to use this rule" |
| 11:38 |
JBoyer |
miker, I assume children ou's be able to see and apply a parent's tags? |
| 11:38 |
miker |
right |
| 11:38 |
|
bmills joined #evergreen |
| 11:39 |
|
Christineb joined #evergreen |
| 11:40 |
JBoyer |
That sounds like it would pretty much fit the bill, yes. What's the ETA on these? (and I assume the ccmm addon isn't currently a part of it, or is it coming at the same time?) |
| 11:41 |
JBoyer |
I had heard of the digital bookplates thing, but don't remember any details. |
| 11:45 |
miker |
1) hopefully for 2.12 (or whatever it's called) and 2) no, it's not part of the planned dev, that was OTTOMH just now, but the infrastructure is meant to support tag-ish stuff |
| 11:52 |
|
jvwoolf joined #evergreen |
| 11:52 |
|
JBoyer_alt joined #evergreen |
| 12:00 |
|
ericar_ joined #evergreen |
| 12:02 |
|
mdriscoll joined #evergreen |
| 12:03 |
|
JBoyer joined #evergreen |
| 12:04 |
|
brahmina joined #evergreen |
| 12:10 |
|
rlefaive joined #evergreen |
| 12:37 |
|
jvwoolf1 joined #evergreen |
| 12:40 |
|
kmlussier joined #evergreen |
| 12:50 |
|
jvwoolf1 left #evergreen |
| 13:02 |
|
hbrennan joined #evergreen |
| 13:21 |
jeff |
i like crossing off webstaff issues that turn out to not be webstaff issues. |
| 13:26 |
|
Dyrcona joined #evergreen |
| 13:42 |
|
jvwoolf joined #evergreen |
| 13:46 |
miker |
jeff: I like when you do that, too :) |
| 13:49 |
|
kmlussier joined #evergreen |
| 13:58 |
|
Christineb joined #evergreen |
| 14:01 |
|
jvwoolf joined #evergreen |
| 14:59 |
kmlussier |
FWIW, I think csharp's branch is the one that addresses the original issue reported by mmorgan in bug 1306666 and not the other way around. However, as long as both issues are addressed, I guess it doesn't matter. |
| 14:59 |
pinesol_green |
Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get Reshelving status." [Low,Confirmed] https://launchpad.net/bugs/1306666 |
| 14:59 |
kmlussier |
But the description for bug 1306666 should probably be updated accordingly. |
| 15:00 |
Dyrcona |
kmlussier: I don't know. Perhaps I still read too much of the problem as I see it into the bug description. :) |
| 15:02 |
JBoyer |
Dyrcona, I was looking at marc_export with an eye toward making its holdings export format match the format output by the Z39.50 server with holdings enabled, but they're pretty different. Where did you find the mapping you used for the 852? |
| 15:03 |
Dyrcona |
JBoyer: That was how many years ago? |
| 15:03 |
Dyrcona |
;) |
| 15:04 |
JBoyer |
More than 1, less than 4? :D |
| 15:04 |
Dyrcona |
Honestly, I don't remember, but I would not be surprised if that was what the original marc_export did, or maybe I just made it up. |
| 15:05 |
Dyrcona |
I can check git for the former. |
| 15:05 |
JBoyer |
I was poking around the LOC site to see if there's anything defined for the various subfields since only a couple match. |
| 15:06 |
JBoyer |
I wouldn't be surprised if it was the same as the old thing, I wouldn't waste much time looking for it, I just didn't know if anything stood out in your memory. "Ugh, that. LOC had this silly mapping that included this thing no one else uses and not this thing everyone wants..." |
| 15:07 |
jeffdavis |
JBoyer: does it match the mapping in the sru_search function in OpenILS/WWW/SuperCat.pm? |
| 15:07 |
bshum |
I thought they were more similar, but I guess all those x subfields get pretty special in marc_export |
| 15:08 |
JBoyer |
Nope. It does appear to map to this though: http://www.loc.gov/marc/holdings/hd852.html |
| 15:09 |
JBoyer |
Unless our sru_export is using a customized 852 format, but I don't know why it would be, holdings exports weren't enabled in Z39.50 unles last month. |
| 15:09 |
JBoyer |
Er, until last month. |
| 15:09 |
miker |
IIRC, the marc_export format was originally made up from whole cloth, for use with OCLC uploads maybe? perhaps based on [VENDOR_NAME_REMOVED]'s format? and yes, it has special stuff in "note" subfields |
| 15:10 |
Dyrcona |
JBoyer: Well, MVLC has been doing holdings with Z39.50 since forever, but..... |
| 15:11 |
JBoyer |
miker, Dyrcona, it looks like it's supposed to be close to LOC's 852 holdings format. (The --location param to marc_export references this: http://www.loc.gov/marc/organizations/orgshome.html and the value supplied is used as $a) |
| 15:11 |
JBoyer |
Dyrcona, but the place you're exposing those holdings to lets you choose how to map them on their end.. ;) |
| 15:12 |
Dyrcona |
Piecing it together from this: http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2c28f9b728425e46e00c3ff11583206b9f1ca14c;hp=1108b8b634cf60cedf9bb7e722146a9ea08e1dd2 |
| 15:12 |
pinesol_green |
Dyrcona: [evergreen|Jason Stephenson] LP1223903 - Rewrite marc_export.in in support-scripts. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c28f9b> |
| 15:12 |
pinesol_green |
Dyrcona: [evergreen|Jason Stephenson] LP1223903 - Add indexes to authority.record_entry. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1108b8b> |
| 15:13 |
Dyrcona |
It looks like I copied what marc_export was doing already. |
| 15:14 |
Dyrcona |
But the relevant chunks are far apart in the diff. |
| 15:22 |
Dyrcona |
JBoyer: If you want to change either holdings format or both to be more "standard," I won't mind. :) |
| 15:27 |
JBoyer |
We'll see where that rabbit hole goes. |
| 15:27 |
JBoyer |
I run into any hooka-pulling caterpillars and I'm out. |
| 15:28 |
kmlussier |
JBoyer: But that's when the fun begins! |
| 15:28 |
JBoyer |
I may listen to what he has to say first. |
| 15:28 |
Dyrcona |
Just remember what the dormouse said. |
| 15:31 |
JBoyer |
I'd ask her to repeat it but I suspect it would be different each time! |
| 15:35 |
Dyrcona |
It is fun, and somewhat appropriate, to run the text of Alice in Wonderland through a Markov chain algorithm and then use that to generate a new text. |
| 15:41 |
jeff |
now i want to do that, but mix in just the pennywise dialog from It. |
| 15:42 |
jeff |
(of which there may not be enough to make a difference.) |
| 15:42 |
jeff |
for another time. |
| 15:43 |
Dyrcona |
jeff: I've done it with both Alice in Wonderland and Through the Looking Glass, also selected works of Shakespeare. |
| 15:43 |
Dyrcona |
Putting the first two together is interesting. |
| 15:53 |
|
bmills joined #evergreen |
| 16:44 |
phasefx_ |
kmlussier: another good humble book bundle going on :) |
| 16:45 |
kmlussier |
phasefx_: I saw something come into my Inbox earlier, but didn't have a chance to look at it. :) |
| 16:45 |
phasefx_ |
Haskell and Erlang books.. I'm getting this one |
| 16:52 |
kmlussier |
phasefx++ |
| 16:52 |
jeffdavis |
Is anyone currently working on an interface for batch patron imports? |
| 16:52 |
jeffdavis |
I know it's been brought up before by the Academics working group (and a lot of us have custom local solutions), just not sure if there is work underway |
| 16:58 |
kmlussier |
jeffdavis: I don't know of work that's underway, but I know mdriscoll created some really good project requirements that are on the wiki. |
| 16:58 |
jeffdavis |
yup thanks, I'm looking at http://wiki.evergreen-ils.org/doku.php?id=evergreen_for_academics:batch_patron_functions |
| 16:59 |
kmlussier |
jeffdavis: That's the one! |
| 16:59 |
|
berick joined #evergreen |
| 16:59 |
* kmlussier |
was hoping to put some attention towards academic development this summer, but the summer is quickly coming to an end. |
| 17:01 |
jeffdavis |
It goes fast, doesn't it? :/ |
| 17:01 |
kmlussier |
jeffdavis: It sure does! |
| 17:05 |
kmlussier |
miker: The webclient code you've been merging - does that make it on to webby? |
| 17:05 |
miker |
kmlussier: it can, but it's not there yet |
| 17:06 |
miker |
kmlussier: I'll push it out now |
| 17:06 |
kmlussier |
miker: Thanks! |
| 17:07 |
|
mmorgan left #evergreen |
| 17:07 |
kmlussier |
Actually, I guess I wasn't so much asking about the merged code as the code that's being added to the sprint 3 branch. Because the merge code doesn't need testing, does it? |
| 17:07 |
* miker |
tells bower to do its thing |
| 17:08 |
miker |
kmlussier: it doesn't hurt for more eyes to be on it |
| 17:08 |
kmlussier |
true enough |
| 17:09 |
* mdriscoll |
has a bunch of student files in her inbox and wishes there was an interface for batch patron import |
| 17:11 |
miker |
arg ... I did something wrong on install... CLEAN UP ON AISLE SIX |
| 17:14 |
miker |
https://cdn.meme.am/instances/500x/71099098.jpg |
| 17:16 |
miker |
all better |
| 17:21 |
hbrennan |
Is anyone using Porteus for OPACs? |
| 17:22 |
Stompro |
@seen dperl |
| 17:22 |
pinesol_green |
Stompro: I have not seen dperl. |
| 17:22 |
jeff |
hbrennan: we are not. the most recent release appears to be december 2014, which makes me think it may be unmaintained. |
| 17:22 |
Stompro |
@seen dpearl |
| 17:22 |
pinesol_green |
Stompro: dpearl was last seen in #evergreen 1 week, 0 days, 1 hour, 12 minutes, and 46 seconds ago: <DPearl> kmlussier++ |
| 17:24 |
hbrennan |
jeff: An IT friend said he's using it currently, but I hadn't heard of it yet. I was pretty committed to forking over the money for Chrome management |
| 17:24 |
jeff |
hbrennan: i keep seeing good things about webconverger, but i've not made time to play with it myself: https://webconverger.com/ |
| 17:24 |
hbrennan |
PINES can't be wrong with 1000 machines in operation |
| 17:24 |
jeff |
what does PINES have in operation? |
| 17:25 |
hbrennan |
Chromeboxes for OPACs, with chrome management |
| 17:25 |
jeff |
(that you're referencing with the 1000 machines comment) |
| 17:25 |
jeff |
yeah. |
| 17:25 |
jeff |
got it. :-) |
| 17:27 |
hbrennan |
Sad that I'm debating whether to save $6/year per OPAC (we only have four total, too) |
| 17:27 |
Stompro |
Has anyone had any issues with the circ history sorting? I cannot get it to work on our test system. I have 226 items in my history, and that seems to be too much for it to handle. |
| 17:28 |
hbrennan |
jeff++ I'll check out Web Converger after lunch |
| 17:40 |
jeffdavis |
Stompro: that rings a bell, but I can't recall any details or find a record of the problem in our ticketing system |
| 17:40 |
jeffdavis |
</unhelpful> |
| 17:43 |
|
jvwoolf left #evergreen |
| 18:05 |
|
bmills joined #evergreen |
| 18:25 |
|
rhamby_ joined #evergreen |
| 18:26 |
|
barbara joined #evergreen |
| 19:27 |
|
mrpeters joined #evergreen |
| 19:38 |
|
gsams joined #evergreen |
| 22:45 |
|
eady joined #evergreen |
| 23:39 |
|
VonBraun joined #evergreen |
