| Time |
Nick |
Message |
| 00:54 |
|
sandbergja joined #evergreen |
| 01:06 |
|
eady joined #evergreen |
| 01:12 |
|
gmcharlt_ joined #evergreen |
| 01:13 |
|
pastebot0 joined #evergreen |
| 01:35 |
|
troy__ joined #evergreen |
| 01:52 |
|
eady joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:59 |
|
agoben joined #evergreen |
| 07:06 |
|
gsams__ joined #evergreen |
| 07:31 |
|
dwgreen joined #evergreen |
| 07:32 |
|
bdljohn joined #evergreen |
| 07:43 |
|
rlefaive joined #evergreen |
| 08:06 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 09:01 |
|
rlefaive joined #evergreen |
| 09:03 |
|
lsach joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 09:32 |
|
tlittle joined #evergreen |
| 09:44 |
pinesol_green |
Showing latest 5 of 8 commits to Evergreen... |
| 09:44 |
pinesol_green |
[evergreen|Dan Wells] LP#1715697 Refactor empty volume adding - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0ec789d> |
| 09:44 |
pinesol_green |
[evergreen|Dan Wells] LP#1773417 Relabel "Add Volumes" button - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f74185f> |
| 09:44 |
pinesol_green |
[evergreen|Dan Wells] LP#1773417 Improve empty volume handling - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=98a2ff8> |
| 09:44 |
pinesol_green |
[evergreen|Dan Wells] LP#1773417 Revamp item and call number tranfers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cbf7073> |
| 09:44 |
pinesol_green |
[evergreen|Mike Rylander] LP#1773417: Use CN owning lib when adding copies - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0747572> |
| 09:51 |
miker |
dbwells++ |
| 09:53 |
JBoyer |
dbwells++ |
| 09:53 |
JBoyer |
miker++ |
| 09:57 |
csharp |
miker++ |
| 09:57 |
dbwells |
miker++ , testers++ |
| 09:57 |
csharp |
dbwells++ |
| 09:57 |
csharp |
that's a nice start to a Wednesday :-) |
| 09:58 |
* csharp |
adds to breaking news chyron on PINES network news channel |
| 09:59 |
berick |
miker++ dbwells++ |
| 10:00 |
|
jvwoolf joined #evergreen |
| 10:00 |
JBoyer |
<MARQUEE>Cataloging fixes enter codebase, catalogers take to the streets for impromptu parade; more as the situation develops</MARQUEE> |
| 10:00 |
csharp |
JBoyer++ |
| 10:02 |
abneiman |
miker++ dbwells++ testers++ |
| 10:04 |
|
rlefaive joined #evergreen |
| 10:20 |
|
rlefaive joined #evergreen |
| 10:20 |
|
remingtron joined #evergreen |
| 10:53 |
|
jonadab joined #evergreen |
| 10:53 |
|
khuckins joined #evergreen |
| 11:02 |
|
kmlussier joined #evergreen |
| 11:09 |
|
mmorgan1 joined #evergreen |
| 11:16 |
|
rlefaive joined #evergreen |
| 11:47 |
Dyrcona |
Hm... Looks like libmarc-xml-perl is gone on Bionic. |
| 11:48 |
|
khuckins_ joined #evergreen |
| 11:50 |
|
rlefaive joined #evergreen |
| 11:56 |
|
Christineb joined #evergreen |
| 12:09 |
|
mmorgan joined #evergreen |
| 12:12 |
bshum |
Dyrcona: Well that's special... |
| 12:12 |
bshum |
I guess I hadn't gotten that far in my testing yet, since I couldn't get OpenSRF working, I ended there |
| 12:13 |
Dyrcona |
I wasn't even trying to install Evergreen. I just wanted MARC::File::XML to run a script. |
| 12:13 |
Dyrcona |
Looks like someone (me?) joins Masters of the Universe and repackages it, or we're back to using CPAN for more things. |
| 12:19 |
|
rlefaive joined #evergreen |
| 12:40 |
|
khuckins joined #evergreen |
| 12:55 |
|
beanjammin joined #evergreen |
| 13:07 |
|
rlefaive joined #evergreen |
| 13:30 |
|
rlefaive joined #evergreen |
| 14:01 |
|
hbrennan joined #evergreen |
| 14:06 |
hbrennan |
An intern is doing inventory and just hit Audiobooks, which all have copy alerts reminding staff to count discs. It's driving her nuts. Any way to suppress Copy Alerts during check in? Thought it was an option under Checkin Modifiers but it's not |
| 14:06 |
hbrennan |
Would Suppress Holds and Transits work... ? |
| 14:06 |
hbrennan |
(thinking out loud while I test ) |
| 14:10 |
csharp |
hbrennan: rings a bell, but I'm not sure what the solution is :-/ |
| 14:10 |
JBoyer |
hbrennan, are these the new hotness alerts or the plain old style? |
| 14:10 |
hbrennan |
csharp: Right? Seems there should be a way to suppress without messing with org settings |
| 14:10 |
hbrennan |
JBoyer: Old style |
| 14:11 |
hbrennan |
We're not using webby in production. Staff other than the intern don't know about it. |
| 14:11 |
JBoyer |
Ah. I think it might be possible to suppress the new stuff, not so sure about the old. |
| 14:11 |
JBoyer |
(I mean, it IS, but I've not played with it enough to really get used to it anyway) |
| 14:12 |
hbrennan |
I am very excited about all the new options |
| 14:12 |
csharp |
@band add New Hotness Copy Alerts |
| 14:12 |
pinesol_green |
csharp: Band 'New Hotness Copy Alerts' added to list |
| 14:13 |
hbrennan |
Suppressing Holds and Transits doesn't do it |
| 14:13 |
JBoyer |
Yeah, looks like the old style are just going to get loud at them for a bit. :/ |
| 14:14 |
hbrennan |
:( Ok I'll tell her to take breaks from that section |
| 14:14 |
JBoyer |
csharp, I initially read that as New Hostess Copy Alerts. Ding! Swiss Rolls are here! |
| 14:17 |
csharp |
JBoyer: :-) |
| 14:18 |
kmlussier |
Even with the new copy alerts, I'm pretty sure there's no way to suppress a checkin alert. Suppression works for system alerts like 'you just checked in a missing item' and things like that. |
| 14:20 |
Dyrcona |
hbreenan: You can't suppress the old style copy alerts without modifying code. |
| 14:21 |
Dyrcona |
heh... hbrennan^^ |
| 14:22 |
hbrennan |
Thanks, all! |
| 14:22 |
hbrennan |
Didn't want to give her the bad news without checking here |
| 14:32 |
|
rlefaive joined #evergreen |
| 14:35 |
|
collum joined #evergreen |
| 14:56 |
Dyrcona |
Related: The COPY_ALERT_MESSAGE also requires an override if you're trying to mass check in copies via some Perl code. So, it's annoying even if you don't see it. :) |
| 15:00 |
hbrennan |
huh. Interesting. |
| 15:02 |
Dyrcona |
Since I'm deleting the copies after, I'm not too worried about it, but I had the script dump the exceptions to the screen while it's running. |
| 15:03 |
Dyrcona |
Probably won't bother with dumping the exceptions when I run it for real. |
| 15:04 |
Dyrcona |
Suppose I could also do the override checking with override => all. :) |
| 15:17 |
Bmagic |
I had a library change the "Prohibit Negative balances" setting to true one month ago but didn't set the "Lost negative balance interval" setting - According to the code, it seems that without the second setting, it will still VOID the bills upon checkin lost and pad items, therefore going negative? |
| 15:17 |
|
khuckins joined #evergreen |
| 15:18 |
|
rlefaive joined #evergreen |
| 15:22 |
mmorgan |
Bmagic: We have "Prohibit Negative Balances on bills (DEFAULT) set to True for the consortium, no interval set, and we don't get automatic voids. |
| 15:24 |
|
khuckins joined #evergreen |
| 15:24 |
Bmagic |
mmorgan: that's encouraging. Can anyone help me find the line of code that proves that the system will not allow bills to go negative without the lost interval setting? |
| 15:24 |
Bmagic |
I'm looking at CircCommon.pm and void_or_zero_bills_of_type |
| 15:26 |
Bmagic |
There is an if statement that requires two criteria, both the prohibit setting and the results of another subroutine _has_refundable_payments which # for now, just short-circuit with no interval |
| 15:26 |
|
terran joined #evergreen |
| 15:31 |
Dyrcona |
So, if the interval is not set, the adjustment code runs. |
| 15:32 |
Dyrcona |
Notice the ! in front of the _has_refundable_balances check. |
| 15:33 |
Dyrcona |
Also, the checks for the settings use the ancestor settings function, so if any ou higher up the tree has an interval set, it will us the interval. |
| 15:36 |
mmorgan |
Bmagic: Also, in case it matters, the copy.circ_lib's ou settings are consulted for this rather than the circulation.circ_lib. |
| 15:37 |
Dyrcona |
yeah. |
| 15:37 |
Dyrcona |
That could matter. |
| 15:37 |
Bmagic |
good point |
| 15:37 |
|
rlefaive joined #evergreen |
| 15:48 |
csharp |
okay - in the xul standalone days, offline xacts were stored in a file on the filesystem, so being able to move that file around for exports, etc was possible - we have a library whose client is white-screening (probably Hatch/Java path-related), so they can't get to the UI to upload xacts |
| 15:49 |
csharp |
maybe a corner case, but we're trying to figure out a way to preserve the data and it doesn't look like Chrome's devtools do more than view-only |
| 15:49 |
Dyrcona |
May I suggest a pencil and some paper? |
| 15:49 |
Dyrcona |
Or, you could try copy and paste. |
| 15:54 |
Dyrcona |
I've not tried copying and pasting from the local storage, but if that doesn't work, you may have to copy things down on a piece of paper. |
| 15:56 |
berick |
csharp: maybe disable hatch in localStorage. IIRC, you can just delete a value. then see if the white screen is fixed. |
| 15:58 |
|
khuckins joined #evergreen |
| 16:00 |
Dyrcona |
Good luck, csharp! |
| 16:00 |
* Dyrcona |
is signing off. |
| 16:02 |
csharp |
Dyrcona: berick: thanks! |
| 16:02 |
* csharp |
will pass on recommendations |
| 16:03 |
|
rlefaive joined #evergreen |
| 16:06 |
jeffdavis |
Backing up offline xacts to a file on Save Transactions might be a good feature request. |
| 16:07 |
jeffdavis |
I don't know how much overhead would be required to implement that though. |
| 16:14 |
* jeffdavis |
guesses the answer is "a lot" |
| 16:33 |
|
yboston joined #evergreen |
| 16:49 |
jeffdavis |
Is there any more info on the use case for bug 1769744 ? |
| 16:49 |
pinesol_green |
Launchpad bug 1769744 in Evergreen "Make Evergreen interact with Innovated Interfaces INNREACH API" [Wishlist,Confirmed] https://launchpad.net/bugs/1769744 |
| 16:50 |
jeffdavis |
What sort of changes/additions would be involved on the EG side? |
| 16:51 |
jeffdavis |
Bmagic: ^ that's probably a question for you |
| 16:52 |
|
yboston joined #evergreen |
| 16:56 |
jeff |
heh... |
| 16:57 |
jeff |
jeffdavis: Do you have interest in interoperability with INN-Reach or another similar system? |
| 16:58 |
jeffdavis |
jeff: actually I'm looking at patron authentication against EG for various external services and wondering if there is any potential overlap. |
| 17:00 |
jeff |
Potentially, but that might depend on what you have in mind. |
| 17:00 |
jeff |
(he said, somewhat vaguely) |
| 17:02 |
jeff |
I have interest in both topics, as you might suspect. |
| 17:03 |
jeff |
What do you have in mind for patron auth? |
| 17:03 |
jeff |
(changes/enhancements for auth of external services) |
| 17:03 |
jeffdavis |
So we have a lot of different vendors that need to authenticate library patrons. It would be nice if we could offer a straightforward API that could handle that without leaking excessive patron information or requiring a lot of EG-specific overhead on the vendor side. |
| 17:04 |
* jeff |
nods |
| 17:04 |
jeffdavis |
Ideally, a RESTful API, maybe with configurable profiles for different clients who have different needs. |
| 17:04 |
jeff |
that seems to exceed the capabilities of most vendors we've attempted to work with, but I'm still listening... |
| 17:04 |
|
mmorgan left #evergreen |
| 17:05 |
jeff |
most we work with are either 1) ezproxy IP auth to establish an external account or ezproxy SSO for Overdrive, 2) emulating the III PatronAPI, or 3) pass barcode via HTTPS, receive success/failure |
| 17:06 |
|
khuckins_ joined #evergreen |
| 17:06 |
jeff |
making an OAuth provider was next on our list, though we don't have much in the way of vendors likely to support it yet. |
| 17:07 |
jeff |
We do not have patrons provide their library account password to vendors. |
| 17:07 |
jeff |
We attempt to tie a unique ID to an account so that patrons don't have to worry about things like getting a new library card resulting in a duplicate/disconnected account on the vendor side. |
| 17:08 |
jeff |
and/or an opaque per-vendor ID that doesn't change -- that really only works with Overdrive at this point, and they seem to be surprised every time they realize we're using it. |
| 17:12 |
|
jvwoolf left #evergreen |
| 17:13 |
jeff |
we're also about to start generating a virtual library card for those patrons who don't have a library card number on file (where they use their driver license to check out books), since we don't use those as external identifiers. |
| 17:15 |
jeff |
I've been tempted to generate a virtual token/card number per vendor, but the UI/UX there is a little tricky, especially with most vendors wanting to use flows like "JUST GIVE US YOUR LIBRARY CARD NUMBER AND 'PIN'" |
| 17:16 |
jeff |
A general "external identifiers" table is something we've also talked about -- we had a need to give a tagged email address to an external system, then act on emails sent to that tagged address in a way that would let us take action needing us to know the patron it was intended for. |
| 17:28 |
jeffdavis |
We've been talking about multi-protocol SSO support. I figure an SSO server would also benefit from having a simple patron auth API to talk to. |
| 17:30 |
jeffdavis |
e.g. https://www.apereo.org/projects/cas could talk to a REST API backend |
| 17:51 |
|
khuckins joined #evergreen |
| 18:30 |
* jeff |
nods |
| 18:30 |
jeff |
do you have any vendors currently that are willing to talk CAS? |
| 18:30 |
jeff |
or OAuth / OpenID Connect for that matter? |
| 18:31 |
jeff |
I think RA21 stuff is leaning OpenAthens, to the chagrin of some folk in the academic library world. |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:52 |
|
beanjammin joined #evergreen |
| 19:01 |
jeffdavis |
I'm not sure about CAS specifically. I understand Lynda.com supports SAML and OAuth (among other things) and Overdrive can talk SAML. |
| 19:03 |
jeff |
Overdrive being able to talk SAML is interesting news. Do you have a ref on that? |
| 19:05 |
jeffdavis |
I have a one-page "Authentication Options" document from their auth support people that claims support for "Federated Authentication via SAML v2.0." Whether it is actually usable is another question, of course. |
| 19:05 |
jeff |
Though in many cases, the weak part becomes the app -- we can't chain EZproxy login through Google OAuth within the Overdrive Libby app, because Google rejects -- the idea being "you're on Android, you shouldn't use the in-app browser for this, you should modify your app to use the proper APIs" -- which fails on a few parts, like how we're not the ones who control the app. :-) |
| 19:06 |
jeff |
The likely solution we were going to use there was to have a device-style flow for the app: here's a token you enter after you sign in elsewhere, since you can't sign in here... |
| 19:07 |
jeff |
But several of these things are least-worst, rarely ideal. |
| 19:08 |
jeff |
And while we've been able to implement or think up things that can work, some of them are not something I think I could implement with a straight face. |
| 19:08 |
jeff |
A conversation I had in the past with a developer regarding why they used SIP2 for auth: simple business decision. Their customers (libraries) wanted it. |
| 19:17 |
jeffdavis |
We'll see how things go, but that attitude may slowly, finally be changing in BC. |
| 19:17 |
jeffdavis |
There's been some discussion among library folks in the region recently where they're realizing that SIP is not OK for auth. |
| 19:19 |
jeff |
Good! |
| 19:31 |
|
bshum joined #evergreen |
| 20:06 |
hbrennan |
Searching for bug because it's so annoying it MUST be recorded already.. but cannot find..... |
| 20:07 |
hbrennan |
swear I've seen it too |
| 20:41 |
|
rlefaive joined #evergreen |
| 21:05 |
jeff |
which bug? |
| 21:07 |
hbrennan |
oh hey Jeff |
| 21:07 |
hbrennan |
can't click on item barcodes in OPAC view |
| 21:08 |
hbrennan |
it's .. kinda major |
| 21:08 |
hbrennan |
jeff: ^ |
| 21:09 |
hbrennan |
All "links" for barcodes are just javascript:void(0) |
| 22:03 |
|
sandbergja joined #evergreen |
