| Time |
Nick |
Message |
| 00:59 |
|
sandbergja joined #evergreen |
| 01:09 |
|
sandbergja joined #evergreen |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 07:37 |
|
rfrasur joined #evergreen |
| 07:50 |
|
Dyrcona joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 08:13 |
|
alynn26 joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 09:39 |
|
collum joined #evergreen |
| 10:19 |
|
jvwoolf joined #evergreen |
| 10:29 |
|
BAMkubasa joined #evergreen |
| 10:30 |
BAMkubasa |
Is there a good quick and dirty helper table/view in the database to get title or author based on TCN? |
| 10:35 |
BAMkubasa |
Found it! reporter.super_simple_record |
| 10:39 |
csharp |
or reporter.materialized_simple_record, which is used for the "Simple Record Extracts" reports source |
| 10:48 |
BAMkubasa |
thanks Chris! |
| 11:16 |
|
collum_ joined #evergreen |
| 11:22 |
dbwells |
Another question for those using located URIs. I am finding that removing the URI (or at least the subfield 9) causes the linkage and asset.call_number row to be deleted as expected, but the asset.uri row sticks around and still has "active" set to true. Is this a known behavior of the current code? |
| 11:24 |
dbwells |
I have a feeling the "active" flag was a maybe-someday data structure, as I do not see it managed anywhere. |
| 11:27 |
berick |
JBoyer++ # meeting reminder |
| 11:51 |
|
jihpringle joined #evergreen |
| 11:51 |
|
Christineb joined #evergreen |
| 12:30 |
Dyrcona |
dbwells: Yes, I think you are correct asset.uri entries are never deleted, cf. bug 1482757. |
| 12:30 |
pinesol |
Launchpad bug 1482757 in Evergreen 3.5 "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
| 12:39 |
dbwells |
Dyrcona: Thanks, I didn't notice that bit was included in that bug. |
| 13:17 |
|
jihpringle joined #evergreen |
| 14:01 |
|
sandbergja joined #evergreen |
| 14:38 |
|
jihpringle joined #evergreen |
| 14:53 |
|
Stompro joined #evergreen |
| 14:54 |
csharp |
berick: FYI, I just opened bug 1902937 - I don't have a lot of time to devote to it right now, but we're interested on the PINES end to get something into Evergreen relatively soon |
| 14:54 |
pinesol |
Launchpad bug 1902937 in Evergreen "Wishlist: Quipu eCard Integration" [Undecided,New] https://launchpad.net/bugs/1902937 |
| 14:55 |
berick |
csharp: gotcha, thanks for heads up |
| 15:17 |
|
sandbergja joined #evergreen |
| 15:21 |
sandbergja |
Does anybody have a good list handy of Evergreen's features that make it useful for consortia? Things like shared catalog, shared patron records, org unit tree, configurable OPACs, etc. |
| 15:22 |
sandbergja |
I just got the question, and would love to point to something that already exists, rather than try to remember everything (and invariably forget) myself |
| 15:25 |
rfrasur |
I have a thing for new members of our consortium, but it's not really as technical as it sounds like you're looking for. It's more of an admin and consortial "these are some benefits" |
| 15:28 |
Dyrcona |
sandbergja: I think the main thing is that, unlike just about every other ILS, Evergreen was designed for consortia from the very beginning. Pretty much every new feature is vetted with consortial support and issues in mind. It's fundamental to the design and not something tacked on at a later date. |
| 15:29 |
Dyrcona |
So, the short answer is, "Everything." ;) |
| 15:29 |
sandbergja |
rfrasur++ |
| 15:29 |
sandbergja |
Dyrcona++ |
| 15:29 |
sandbergja |
hear hear |
| 15:29 |
rfrasur |
Dyrcona++ |
| 15:29 |
sandbergja |
rfrasur: that sounds helpful for me! |
| 15:31 |
rfrasur |
sandbergja, are you cool with me sharing my slidedeck? There's actually just one (involved) slide that includes what I'm talking about, but there might be something else in there of value. And, of note, I'm kinda cannibalizing it a little right now for an intro course, so there are hidden things you'll be able to see. And weird copy/paste things I don't usually worry about because they're in the notes area. |
| 15:32 |
sandbergja |
rfrasur: yes please! |
| 15:33 |
rfrasur |
I'm just gonna pop it in here. I edited the share settings so you can comment if you have questions or anything like that. |
| 15:33 |
rfrasur |
https://docs.google.com/presentation/d/1wiyU75ZdnTB4Ehy-6ez-CnnUppmRmSm9BDYQKCUO0Ns/edit?usp=sharing |
| 15:34 |
Dyrcona |
rfrasur++ |
| 15:35 |
sandbergja |
rfrasur: I LOVE THESE SLIDES |
| 15:35 |
rfrasur |
lol, thank you. I decided it was my living room so I could paint it however I wanted. |
| 15:59 |
|
sandbergja_ joined #evergreen |
| 16:04 |
jeff |
library thought that checkin would automatically assume in-house use if the item wasn't checked out at the time of checkin. |
| 16:04 |
jeff |
i can probably make use of the auditor table to synthesize in-house use records for them. |
| 16:05 |
jeff |
but I'm also wondering if that should be a feature... either prompt for recording in-house use on checkin of an item that wasn't checked out, or... hrm. |
| 16:15 |
collum_ |
I believe our previous ILS had a check-box option on the check-in screen. But a prompt would be better. Staff forget to un-check things. |
| 16:25 |
|
stompro_ joined #evergreen |
| 16:27 |
jeff |
i can think of several scenarios where you would not want to record in-house use for every checkin of a not-checked-out item. |
| 16:28 |
jeff |
and I also wouldn't want to prompt on every such checkin attempt. |
| 16:28 |
jeff |
i'm just not sure if a "record as ih-house use without prompting" would be... a good idea. |
| 16:33 |
mmorgan |
jeff: What about a checkin modifier that could be toggled on and off? |
| 16:43 |
jeff |
That's how I'd imagine implementing it, even if it wasn't a checkin arg. |
| 16:44 |
jeff |
with the existing in-house use screen available for "record in-house use for everything I scan", I think the checkin modifier would be something like "prompt for in-house use on non-circulating items" |
| 16:46 |
jeff |
more thought required. defaults matter a bit here, i think. :-) |
| 16:46 |
JBoyer |
jeff++ |
| 16:47 |
JBoyer |
defaults always matter, unless the default is "don't run until configured," which is unfriendly in a different way. :) |
| 16:51 |
|
stompro_ joined #evergreen |
| 17:02 |
|
mmorgan left #evergreen |
| 17:54 |
sandbergja |
jeff: Koha has that feature (a setting called RecordLocalUseOnReturn). I'd be curious what Koha libraries who have implemented that feature think of it |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:51 |
|
sandbergja joined #evergreen |
| 20:52 |
|
Stompro joined #evergreen |
| 21:41 |
|
sandbergja joined #evergreen |
| 21:51 |
|
sandbergja joined #evergreen |
| 22:42 |
|
sandbergja joined #evergreen |
