| Time |
Nick |
Message |
| 01:40 |
|
sandbergja joined #evergreen |
| 07:02 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
Dyrcona joined #evergreen |
| 07:59 |
|
awitter joined #evergreen |
| 08:04 |
|
awitter joined #evergreen |
| 08:13 |
|
collum joined #evergreen |
| 08:36 |
|
awitter joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:41 |
|
bos20k joined #evergreen |
| 08:55 |
|
mdriscoll joined #evergreen |
| 09:01 |
|
tlittle joined #evergreen |
| 09:07 |
|
jvwoolf joined #evergreen |
| 09:08 |
|
yboston joined #evergreen |
| 09:14 |
|
cmalm joined #evergreen |
| 09:24 |
|
mmorgan1 joined #evergreen |
| 10:06 |
Dyrcona |
jeff: Something tells me that you might have an opinion on a feature that I just thought of (again). I wonder is a remote PIN would be useful. This would be a numeric code that the patron can use with 3rd party vendors. It would avoid the issue of patrons giving their passwords to vendors, and it would also help with those vendors who cannot deal with actual passwords. |
| 10:07 |
Dyrcona |
I was reminded of it because of a ticket someone opened on our internal ticket system. |
| 10:10 |
|
sandbergja joined #evergreen |
| 10:11 |
jeff |
yes, that and/or a "card number" that's actually for e-resource vendor auth only. |
| 10:19 |
Dyrcona |
I don't know how seriously we're going to pursue this, but I think it would be useful, too. |
| 10:20 |
jeff |
related but possibly different, i'd like to support patrons being able to require a pin to use selfcheck, but something that's not their password. |
| 10:20 |
jeff |
that will require vendor support. i don't recall if we've had a conversation with the vendor yet. |
| 10:20 |
Dyrcona |
Yeah, that's more or less what I was thinking. It would be useful with Overdrive and NCIP, too. |
| 10:21 |
jeff |
have to be careful to avoid too much complexity / too many passwords and PINS. |
| 10:21 |
jeff |
the vendor support required on the SIP side would be adding essentially the equivalent of HTTP 401 logic. |
| 10:22 |
Dyrcona |
Well, I was thinking just 1 PIN. |
| 10:22 |
jeff |
try to fetch the patron without a PIN, only on failure prompt the patron for their PIN. |
| 10:22 |
jeff |
*nod* |
| 10:22 |
JBoyer |
jeff, depending on how it's done you might not need vendor support. If SIPServer sees a valid match in the config config file listing, could it use the auth_internal API to just force the login? (I don't recall if SIPServer is on the correct side of OpenSRF for that off hand though) |
| 10:23 |
Dyrcona |
JBoyer: Part of the point is forcing the PIN to be used because some services currently work on barcode only. |
| 10:25 |
jeff |
JBoyer: the vendor support would be required on the SIP client side to support prompting for the PIN only when the ILS said it was required (by way of saying "pin's wrong") |
| 10:25 |
JBoyer |
Ah, no getting around that without the vendor being involved. |
| 10:26 |
jeff |
JBoyer: currently, the SIP clients either prompt for a PIN and send the PIN and care about the "PIN correct?" flag in the response, or they do none of the above. |
| 10:26 |
JBoyer |
I read that initially as "we want to stop people giving their password to all and sundry" rather than "our vendors love giving access to anyone who can guess a card number!" |
| 10:26 |
jeff |
JBoyer: we could fake it by accepting any PIN value when the patron-level setting was set to not require a PIN for selfCheck, but then that's pretty crummy UX. |
| 10:27 |
JBoyer |
As someone who is involved in a service that does exactly that I 100% agree... |
| 10:27 |
Dyrcona |
JBoyer: This would attempt to address both of those. It changes the risk factors somewhat. |
| 10:27 |
jeff |
We're more comfortable with vendors giving access based on just a valid card number than we are with patrons sending their library credentials to not-the-library. |
| 10:28 |
Dyrcona |
I agree with jeff, but adding a PIN that the patron can change at will would make me more comfortable. |
| 10:28 |
* Dyrcona |
imagines the actor.usr_setting table filling up with values of '5555' :) |
| 10:29 |
jeff |
In parallel, I'm also looking at throwing up a SAML IdP for SSO for some, since that's a bit more common and widely supported than EZproxy SSO, which really only has three vendors and a "generic" mode, with the generic mode not supporting token patron IDs. |
| 10:29 |
JBoyer |
Surely you mean 1234. ;p |
| 10:29 |
Dyrcona |
:) |
| 10:30 |
JBoyer |
I like something more like SAML/OAuth/etc., just because the more complicated it gets the more likely the 555/1234 (with matching password, natch) becomes. |
| 10:30 |
Dyrcona |
SSO would be cool both as a provider and consumer. |
| 10:31 |
Dyrcona |
Well, there's limited entropy in 4 digits. |
| 10:31 |
JBoyer |
Dyrcona, I just meant people would make their pin/pwd match as much as local policy allows. |
| 10:31 |
jeff |
the one vendor we're interested in that supports SSO with SAML sounded like they would do it reluctantly for a library customer, at a price 10x what they had originally said. |
| 10:32 |
JBoyer |
I wish I had some stats on Windows 10's PIN feature. I wonder what %-age of users actually turn it on. |
| 10:33 |
jeff |
setting the "let patrons require a PIN for selfcheck" aside for the moment, I like the idea of "this is your virtual card number and PIN. use it only for access to some electronic resources", with clear indications on the EZproxy or other SSO page saying "this isn't where you use your virtual card, you need your real credentials here!", but... it's still less than optimal. |
| 10:34 |
jeff |
btw, if you ever hear me advocating for secret question/answer pairs, you'll know i'm communicating under duress and attempting to signal for help without alerting my captors. |
| 10:35 |
JBoyer |
Heh, like some of the digital credit card services there could be a button in the opac that you click to get a new virtual card when you fear the previous one is burnt. |
| 10:35 |
JBoyer |
jeff, I did come >< that close to building a feature that adds a "must change pwd on login" flag to actor.usr... |
| 10:36 |
jeff |
JBoyer: right, or one per vendor if you want to get really complex. |
| 10:37 |
jeff |
JBoyer: in some cases, that can be abused to subvert per-patron usage limits with CPC vendors, though. |
| 10:37 |
jeff |
good thing that MBNA/BofA's patent on virtual credit card numbers is probably due to expire soon, eh? :P |
| 10:37 |
JBoyer |
I also expect the uptake on anything that complex to be on the order of a half percent or 15% of the users that have a password manager, whichever is lower. ;) |
| 10:38 |
Dyrcona |
heh... |
| 10:39 |
* Dyrcona |
has a password manager. |
| 10:39 |
Dyrcona |
I think adding a PIN field as a user setting is a good first start. Virtual barcodes can come later. :) |
| 10:39 |
JBoyer |
Same. And I probably still wouldn't bother with a vcard.:) |
| 10:41 |
JBoyer |
(That "Same" referred to the use of a PW manager. I take my library card security slightly less seriously than the other things in there.) |
| 10:41 |
Dyrcona |
Yeah, I understood, but logs.... :) |
| 10:46 |
Dyrcona |
One thing I want to state publicly about my thoughts around the PIN: It will never work for OPAC logins. It's meant to be used only with 3rd party products. |
| 10:49 |
JBoyer |
+1 Good point. |
| 10:54 |
jeff |
one challenge for me is vendors that want to use the library card number and pin for login, not just verification of library patron-ness. |
| 10:55 |
jeff |
in those situations, i wouldn't want to have sequential card numbers and four digit pins be the only thing protecting that account. |
| 10:58 |
jeff |
but yes, I don't think anywhere in this conversation we've been suggesting making the PIN take the place of a password when logging into Evergreen as a patron. |
| 11:00 |
jeff |
another challenge is "library PIN or password" as a label on some vendor sites. |
| 11:00 |
JBoyer |
jeff, absolutely. But there is some value in making sure it's clear in the logs that no one discussing it would ever want it to work that way. I would imagine the first naive attempt to implement it would. "AND (pwd = ... OR pin =... )" |
| 11:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:01 |
Dyrcona |
I also imagine there will be some confusion among staff and patrons when such a feature is rolled out. |
| 11:04 |
Dyrcona |
I imagine we should call it "Remote Access PIN" or something like that. I don't know what would make the most sense to the most people. Maybe "Third Party PIN"? |
| 11:04 |
Dyrcona |
Now, we just have to code it up and write release notes! :P |
| 11:08 |
JBoyer |
Ooh, third party is a good name for that. Makes plain the intent. |
| 11:08 |
JBoyer |
"There are 2 difficult problems in computer science, concurrency and naming things." - someone I have paraphrased poorly. |
| 11:10 |
Dyrcona |
Actually, that's a pretty good paraphrase. |
| 11:12 |
jeff |
I'm partial to: "There are two difficult problems in computer science: cache invalidation, naming things, and off by one errors." |
| 11:12 |
Dyrcona |
:) |
| 11:17 |
JBoyer |
jeff++ |
| 11:18 |
|
mmorgan joined #evergreen |
| 11:33 |
jeff |
various other plays on the phrase, including "There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery" |
| 11:33 |
jeff |
https://martinfowler.com/bliki/TwoHardThings.html |
| 11:49 |
|
yboston joined #evergreen |
| 12:06 |
|
yboston joined #evergreen |
| 12:18 |
|
sandbergja joined #evergreen |
| 12:23 |
Bmagic |
Why does Evergreen prompt the staff for a billing type when marking it damaged? Shouldn't it just use billing ID 7 "Damaged Item" - Also, the action does not bill the patron for the Damaged processing fee, is that a bug? |
| 12:26 |
JBoyer |
Bmagic, I suspect because the xul feature to mark damamged with a custom price allowed the user to choose a billing reason (mistakenly? It just re-used the add a bill window...). Since I had long-since torn out that feature and forced it to only ever use 7 I didn't think to ask about it on here / LP. |
| 12:29 |
mmorgan |
Bmagic: Also, library setting circ.charge_on_damaged controls whether to charge the patron at all. We don't have that option set, so have not run across your issue. |
| 12:31 |
|
collum_ joined #evergreen |
| 12:37 |
pinesol |
[evergreen|Dan Wells] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=580a6af> |
| 12:37 |
pinesol |
[evergreen|Dan Wells] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=22589de> |
| 12:38 |
JBoyer |
mmorgan, out of curiosity, since we normally only charge for damage when the item is to be discarded it's so bad what do you do locally? Mark it lost before checkin, bill them separately as a grocery transaction, something else? |
| 12:41 |
Bmagic |
mmorgan dbwells: Hmm, we have circ.charge_on_damage set to true. And after checking an item in, we see it in the grid. Right click and mark item damaged. We receive a dialog to confirm, then a second dialog that is exactly the same as the billing dialog. Complete with note field and dropdown for billiing type and amount |
| 12:46 |
mmorgan |
JBoyer: I think it depends on the situation. When an item is returned damaged, libraries generally leave it checked out until the patron is contacted about the issue. The problem they had with charging was that the item no longer showed as checked out, just in bills. |
| 12:47 |
mmorgan |
Bmagic: I think the mark damaged process checks to see if the item is checked out, and if so, checks it in. The rest of the process is the same. |
| 12:51 |
|
jihpringle joined #evergreen |
| 13:01 |
|
yboston joined #evergreen |
| 13:08 |
|
khuckins joined #evergreen |
| 13:11 |
* Dyrcona |
recently made some changes to the mark items functionality that is going into 3.4. It may resolve/change some of that behavior. |
| 13:13 |
jeff |
Dyrcona: have a bug number on that? |
| 13:14 |
jeff |
tacking on to the conversation above, we mark damaged after checking in. in many cases, the item has already been checked in automatically by a book return. |
| 13:14 |
mmorgan |
lp1779467 |
| 13:14 |
jeff |
bug 1779467 |
| 13:14 |
pinesol |
Launchpad bug 1779467 in Evergreen "Enhance Mark Item Discard/Weed Functionality" [Wishlist,Fix committed] https://launchpad.net/bugs/1779467 |
| 13:15 |
Dyrcona |
:) |
| 13:15 |
jeff |
mmorgan++ thanks |
| 13:15 |
Dyrcona |
jeff: I don't think it changes anything significant in the backend code. I reorganized it a little, but the functionality is the same. I deliberately tested it to make sure. |
| 13:16 |
Dyrcona |
I don't recall if I tested with a damaged fee, though it did charge the price of the item when the settings were correct. |
| 13:17 |
Dyrcona |
Others can answer for their testing of it. :) |
| 13:18 |
jeff |
I wasn't too concerned with regression, just didn't realize that that bug had evolved beyond its title (though it was my first guess when you mentioned "recently made some changes to the mark items functionality"), and I'm curious to see if it interacts with some changes we've been using for Missing Pieces. |
| 13:18 |
Dyrcona |
Ah, cool. |
| 13:18 |
jeff |
There are things in Missing Pieces that I'd like to rip out, but I suspect would need to be placed behind an OU setting or flag. |
| 13:18 |
Dyrcona |
OK. |
| 13:19 |
mmorgan |
jeff: what things would you rip out? |
| 13:19 |
Bmagic |
It seems the only place I can mark something damaged is from the check-in interface. I still can't get the system to charge the damaged processing fee automatically. |
| 13:19 |
jeff |
like the logic for "check this item back out to the patron. if this item is needed for a hold, make it due today." |
| 13:19 |
jeff |
(i'd like to rip out the second part of that) |
| 13:20 |
jeff |
no matter your notification method for Missing Pieces, starting to charge daily overdue fees the day after you mark it Missing Pieces seems a bit... unfriendly. |
| 13:20 |
* mmorgan |
agrees with removing the check back out part |
| 13:20 |
jeff |
Especially since the item may have been returned many days before the due date. |
| 13:21 |
mmorgan |
Yes, or many months or years :) |
| 13:21 |
jeff |
We're actually okay with the "check back out" part, though I'd like to synthesize it as a "renewal" or at least part of the same circ chain. |
| 13:21 |
jeff |
mmorgan: you have years+ circ durations? |
| 13:22 |
* mmorgan |
meant that an item sitting on the shelf for years could get marked missing pieces and checked out to the patron that returned it years ago. |
| 13:23 |
jeff |
ah. yes, I'd like a prompt for confirmation / hard error for "when did the item check in?" |
| 13:24 |
jeff |
"checked in more than a few days ago? are you sure you want to do this?" |
| 13:24 |
jeff |
"checked in more than HARD LIMIT ago? error, don't do this." |
| 13:24 |
Dyrcona |
Bmagic have a look at the code from the bug mentioned earlier. |
| 13:24 |
Bmagic |
will do |
| 13:25 |
Dyrcona |
It may not fix your damaged processing fee issue, but it expands the mark item functionality a bit. |
| 13:25 |
mmorgan |
+1 to a limit beyond which the checkout would not be allowed. Or not be allowed without permission. |
| 13:26 |
Dyrcona |
I don't recall if it adds more places to mark items damaged or if there were already more places to do so. I'm pretty sure you can do it from Item Status, for instance. |
| 13:27 |
jeff |
mmorgan: generally if we find something is incomplete on the shelf, we mark damaged. we only use Missing Pieces when during the checkin/reshelving process it's found to be missing pieces. |
| 13:28 |
jeff |
(so in that case, we pretty much always want to go back to the patron who just returned it and notify them, then bill them, etc.) |
| 13:28 |
jeff |
i should probably also fold our "mark it damaged after X days on the missing pieces shelf" into an A/T or something. |
| 13:30 |
mmorgan |
jeff: Makes sense. But I'm still wary that the scan as missing pieces can run on any item. We've removed that option from the circulation menu, and only have it available in checkin. |
| 13:31 |
mmorgan |
That goes against my principles though, because it requires a checkin before marking missing pieces, and it really shouldn't be checked in if it's missing pieces. |
| 13:34 |
jeff |
since items here are most often already checked in before they are found to be missing pieces, that matters less here. |
| 13:34 |
jeff |
i don't recall if we more often scan as missing pieces or do it from checkin. |
| 13:34 |
jeff |
and i don't remember without looking if it's available from item status. |
| 13:36 |
jeff |
damaged items are checked in first. sometimes we full or partial bill the patron. sometimes we don't bill the patron. depends on the situation/damage. |
| 13:37 |
jeff |
missing pieces are generally checked in before being marked missing pieces, at which time they're checked back out for a week to the patron, the patron is notified, etc, and then at the end of the week a process checks the items in and marks them damaged, bills the patron, notifies the patron. |
| 13:38 |
jeff |
to ensure that the price of the item reflects what we plan to charge, a report each day goes out to departments with the items that were marked missing pieces (and will be billed soon) the previous day. |
| 13:39 |
jeff |
i don't remember without looking at docs what we did for "we're only going to charge them for a missing disc replacement fee, not the full price" -- i think it was "do that before the system bills full price". pretty sure we didn't suggest that the item price be adjusted down to the partial amount. that would have been silly of us. |
| 13:48 |
|
jonadab joined #evergreen |
| 13:59 |
|
sandbergja_ joined #evergreen |
| 14:24 |
pinesol |
[evergreen|Dan Wells] LP#1796945 Reporter cloning and creation fixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6cdbb3d> |
| 14:24 |
pinesol |
[evergreen|Dan Wells] LP#1796945 Match new path_label/alias standard - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=53e4550> |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:18 |
|
khuckins joined #evergreen |
| 15:57 |
|
jvwoolf left #evergreen |
| 16:22 |
|
mmorgan joined #evergreen |
| 16:26 |
|
JBoyer joined #evergreen |
| 16:31 |
|
mdriscoll left #evergreen |
| 16:49 |
|
sandbergja_ joined #evergreen |
| 16:58 |
|
nfBurton joined #evergreen |
| 16:58 |
pinesol |
[evergreen|Andrea Buntz Neiman] docs: error correction to 3.1.14 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=43413aa> |
| 17:13 |
|
mmorgan left #evergreen |
| 17:16 |
pinesol |
[evergreen|April Durrence] Docs: add info about merge tracking - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4ac25f> |
| 17:26 |
pinesol |
[evergreen|dluchenbill] Docs: add checkin trigger holds and cancel transit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9bf8d67> |
| 17:28 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.1.14 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3d5b1d0> |
| 17:28 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.2.8 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fabf404> |
| 17:28 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.3.3 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1eaf0e3> |
| 17:38 |
|
khuckins joined #evergreen |
| 17:46 |
pinesol |
[evergreen|Derek C. Zoladz] Docs: LP #1803415: Location of MARC Editor 'Delete' Button - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7223710> |
| 17:46 |
pinesol |
[evergreen|Jane Sandberg] Docs: adding alt text to MARC Editor chapter images - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5489249> |
| 20:18 |
|
Dyrcona joined #evergreen |
| 22:59 |
|
sandbergja joined #evergreen |
| 23:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
