| Time |
Nick |
Message |
| 00:06 |
|
Keith_isl joined #evergreen |
| 04:08 |
|
phasefx joined #evergreen |
| 04:08 |
|
abneiman joined #evergreen |
| 04:08 |
|
miker joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
collum joined #evergreen |
| 07:32 |
|
mantis joined #evergreen |
| 08:23 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 09:33 |
|
terranm joined #evergreen |
| 09:38 |
mantis |
We're on 3.6.5. With the security update that prevents old staff logins, does this also affect old/expired barcode logins with patrons? We're getting patrons at select libraries calling in saying they can't log into their accounts. When staff check their accounts, their username is filled in with an old barcode that doesn't match their current one. We think it's just user error in not updating the patron information. |
| 09:54 |
jeff |
if you have a value in the username field that "looks like" a barcode (matches your barcode regex, i believe) and that "barcode" is not an active card on the account in question, you will have issues logging in. |
| 09:54 |
jeff |
I don't think that that has changed recently. |
| 09:55 |
jeff |
you can probably search the database for those users and reset their username from a barcode-looking value to one of their actual barcodes, but that won't help the user if they're trying to use the value to log in. |
| 09:56 |
jeff |
but it can help you find a subset of affected users, and you can decide where to go from there. |
| 09:57 |
mmorgan |
mantis: I'm pretty sure the expired staff login block wouldn't affect patrons, though I haven't actually looked :) |
| 09:57 |
jeff |
and yes, I don't think that the changes for bug 1844121 would have made this become a new issue for you from a patron / opac POV |
| 09:57 |
pinesol |
Launchpad bug 1844121 in Evergreen 3.6 "Able to login to staff client with old card number" [High,Fix released] https://launchpad.net/bugs/1844121 |
| 09:58 |
terranm |
I just tested on a 3.8 test box with the default settings and if you have 333 as a barcode and 222 as a user name, the 333 will work and the 222 won't. |
| 09:58 |
mmorgan |
It's not uncommon in our libraries that the primary barcode in a patron record gets changed when a patron gets a new barcode, but the username does not. |
| 09:59 |
mmorgan |
Then the patron can't login with the username because that "barcode" is inactive, as jeff describes. |
| 09:59 |
terranm |
If I replace the 333 barcode with 444, then the 333 no longer works. |
| 10:01 |
mmorgan |
terranm: Interesting. So a patron can login to the catalog using barcode OR username unless that username was previously their barcode? |
| 10:02 |
terranm |
I think it is as Jeff said above, that it "looks like" a barcode, so it's only checking against valid barcodes. |
| 10:05 |
mantis |
mmorgan: right, we were wondering if this was from user error, but suddenly after the upgrade, a couple of libraries were stating patrons were having issues logging in |
| 10:05 |
mantis |
One claims that the username field got changed somehow to an old barcode |
| 10:06 |
terranm |
For that one, the username probably never got updated to the new barcode. |
| 10:07 |
terranm |
The patrons may have their old barcodes stored in their browsers, too, so even if staff updated the username, patrons will still need to enter their new barcode when they log in. |
| 10:09 |
mantis |
We did have an upgrade over the weekend and particular patrons were reporting issues afterwards |
| 10:10 |
mantis |
I just don't understand how during the upgrade process a username field can populate with another barcode or an older barcode |
| 10:11 |
jeff |
that is unlikely. |
| 10:11 |
jeff |
but if you want to look for signs of it, check your auditor.actor_usr_history table entries for the user in question. |
| 10:13 |
jeff |
it's more likely that 1) the issue was happening before the upgrade also, or 2) there was an unintentional change/side effect in code or config, but unlikely "the upgrade scripts changed the value of some users' usrname field |
| 10:13 |
jeff |
but the auditor table should help narrow things down. |
| 10:13 |
jeff |
what version were you on prior to the upgrade? |
| 10:14 |
mantis |
jeff: we were on 3.5.4 |
| 10:28 |
jeff |
a simple query to look at usrname over time for a given user (if you have their database id) would be: |
| 10:28 |
jeff |
select audit_time, audit_user, audit_ws, usrname from auditor.actor_usr_lifecycle where id = 1 order by audit_time desc; |
| 10:28 |
mantis |
jeff++ |
| 10:29 |
jeff |
I'd look at the example from "One claims that the username field got changed somehow to an old barcode" to see when the change was made and who made it. |
| 10:30 |
|
Christineb joined #evergreen |
| 10:31 |
Dyrcona |
I've seen usrname change to an old barcode when staff are messing around, i.e. they make a mistake and try to fix it themselves. |
| 10:35 |
Dyrcona |
I've also seen it not change when a new barcode is added. I don't think I've bugged it on LP because I don't know the exact steps to reproduce it, but I have seen patrons with usrnames that are barcodes, but the barcode is not on this patron, or even in the database at all. |
| 10:35 |
Dyrcona |
I usually only find out about that one when staff try to assign that barcode to another patron and it fails because the usrname is in use. |
| 10:35 |
Dyrcona |
Anyway.... |
| 10:36 |
Dyrcona |
mantis: Good luck! |
| 10:40 |
mantis |
Dyrcona++ |
| 10:40 |
mantis |
I'm also airing on the side of user error but the timing of the upgrade is making me curious |
| 11:04 |
terranm |
Of course, we always get a few reports from libraries that an upgrade has broken something when it works the same as it always did and staff are just hypervigilant and looking at things they weren't looking at before. |
| 11:13 |
* jeff |
nods |
| 11:13 |
jeff |
this has been discussed here before. :-) |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:33 |
terranm |
berick: Have you, by any chance, had time to look at https://bugs.launchpad.net/evergreen/+bug/1956626 or |
| 12:33 |
terranm |
https://bugs.launchpad.net/evergreen/+bug/1956790? |
| 12:33 |
pinesol |
Launchpad bug 1956626 in Evergreen "Shelving locations in holdings editor only workstation library" [High,New] |
| 12:33 |
pinesol |
Launchpad bug 1956790 in Evergreen "Holding template with item alert breaks save" [High,New] |
| 13:45 |
|
jvwoolf joined #evergreen |
| 13:46 |
miker |
jeff: IIRC, you were involved in diagnosing the issues with various email-sending issues, and switching from Email::Simple to Email::Send in the a/t reactor, is that a false memory? |
| 13:52 |
JBoyer |
miker, I think Dyrcona may have also been involved in that discussion back in the day |
| 13:55 |
jeff |
I helped diagnose, yes. |
| 13:55 |
jeff |
I don't think I advocated for the change in libraries one way or the other. |
| 13:56 |
jeff |
Noticed the discussion yesterday, was going to poke around when I had time (I have not yet). |
| 14:12 |
jeff |
From memory, the original SendEmail reactor broke because of a change in Encode.pm which caused a MIME encode call on headers that shouldn't be MIME encoded to fail. Previously it had either passed the value through unchanged, or had done a best-effort. |
| 14:16 |
miker |
ah, thanks for that. the header handling is different between the two (including some RFC-compliance changes in the reactor), so I'm inclined to just make the opac code look more like the reactor, as it's more modern |
| 14:19 |
miker |
Dyrcona: do you have clear memories of the email work? git-blame says you did the mime-related changes in 2019, but that was in the Before Times... |
| 14:21 |
miker |
jeff: and, btw, past-miker was the one that used Email::Send in the reactor (from, it looks like, the very beginning), and also the person that used Email::Simple in the OPAC code. so... thanks a lot, past-miker |
| 14:30 |
|
Keith__isl joined #evergreen |
| 14:31 |
|
jvwoolf1 joined #evergreen |
| 16:30 |
|
rfrasur joined #evergreen |
| 17:23 |
|
mmorgan left #evergreen |
| 17:26 |
|
jvwoolf1 left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
