Evergreen ILS Website

IRC log for #evergreen, 2022-01-13

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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>

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat