Time |
Nick |
Message |
01:59 |
|
Mark__T joined #evergreen |
07:44 |
|
rjackson_isl joined #evergreen |
07:51 |
|
ericar joined #evergreen |
07:57 |
|
jboyer-laptaupe joined #evergreen |
08:28 |
|
rlefaive joined #evergreen |
08:33 |
|
mmorgan joined #evergreen |
08:49 |
|
Shae joined #evergreen |
08:58 |
|
akilsdonk joined #evergreen |
09:01 |
|
Dyrcona joined #evergreen |
09:06 |
|
kmlussier joined #evergreen |
09:06 |
|
tsbere joined #evergreen |
09:07 |
* tsbere |
needs a vacation to recover from his vacation |
09:15 |
* jboyer-laptaupe |
is looking forward to taking a vacation to recover from. |
09:18 |
|
mrpeters joined #evergreen |
09:20 |
|
maryj joined #evergreen |
09:24 |
kmlussier |
I will be taking a vacation next week to recover from last week's vacation. :) |
09:24 |
|
jboyer-laptaupe joined #evergreen |
09:25 |
mrpeters |
Morning guys -- anyone on 2.8.2 having trouble with the Offline Transaction Management interface? Getting a dojo error "fileName":"oils://remote/js/dojo/dojo/dojo.js", "lineNumber":24 -- I saw some old messages about this regarding reciept templates, and syntax errors in them, but the JSON for the offline transactions looks well formed. |
09:32 |
|
yboston joined #evergreen |
09:34 |
mmorgan |
mrpeters: We have been on 2.8.2 since late July, and I see a few offline sessions have been created and processed by our libraries since then. I haven't gotten any reports of errors. |
09:34 |
|
mrpeters joined #evergreen |
09:39 |
|
mrpeters joined #evergreen |
09:45 |
kmlussier |
Woo hoo! The staff clients are building on my VM's again with the patch from bug 1484655. |
09:45 |
pinesol_green |
Launchpad bug 1484655 in Evergreen "ftp://ftp.mozilla.org has moved to http://archive.mozilla.org" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1484655 |
09:45 |
kmlussier |
Dyrcona++ |
09:45 |
|
RoganH joined #evergreen |
10:04 |
Stompro |
Is the code/config for Pinesol_green available anywhere? I would like to add a bit about the launchpad integration to the using pinesol_green wiki page. |
10:06 |
|
ericar_ joined #evergreen |
10:07 |
bshum |
Stompro: unfortunately not exactly. |
10:07 |
bshum |
Some things were added a bit adhoc and hastily. |
10:07 |
Stompro |
I think I found what I needed, the bot is supybot and the plugin is bugtracker. |
10:07 |
bshum |
Yes |
10:08 |
Stompro |
I should be able to find docs on bugtracker. |
10:08 |
bshum |
And bugtracker is from the Ubuntu plugins |
10:08 |
bshum |
They document their bots |
10:09 |
Stompro |
I think I found what I needed here https://github.com/mapreri/MPR-supybot/tree/master/plugins/Bugtracker |
10:20 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1484655: ftp://ftp.mozilla.org moved to http://archive.mozilla.org - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8d14cfb> |
10:21 |
bshum |
yboston: consider me always +1 to community irc activities |
10:22 |
bshum |
Stompro: I can't remember where I got the plugin, but can check more carefully on the web server where it's running. |
10:22 |
yboston |
bshum: you do realize it is all a big ploy to increse my karma |
10:22 |
jboyer-laptaupe |
use utf8; an Ode to Unic?de - a poem in 5 parts, the last 3 of which are inaccessible because of parsing errors. |
10:22 |
Stompro |
The karma must flow! |
10:24 |
bshum |
yboston++ |
10:25 |
Stompro |
bshum, I think I have enough to go off of.. There really doesn't need to be so many options , "bug xxxxxx" seems to be what is used the most. |
10:26 |
bshum |
http://ubottu.com/ |
10:26 |
bshum |
Stompro: https://code.launchpad.net/~ubuntu-bots/ubuntu-bots/devel |
10:26 |
kmlussier |
@karma |
10:26 |
pinesol_green |
kmlussier: Highest karma: "kmlussier" (88), "Dyrcona" (85), and "bshum" (59). Lowest karma: "ie" (-6), "iii" (-4), and "java" (-4). You (kmlussier) are ranked 1 out of 165. |
10:27 |
kmlussier |
yboston++ |
10:27 |
kmlussier |
@karma yboston |
10:27 |
pinesol_green |
kmlussier: Karma for "yboston" has been increased 61 times and decreased 1 time for a total karma of 60. |
10:27 |
bshum |
That's where we pulled from once upon a time |
10:27 |
Dyrcona |
kmlussier++ |
10:27 |
bshum |
We haven't updated in years though. |
10:27 |
Dyrcona |
yboston++ # Our welcoming committee. |
10:28 |
bshum |
Stompro: lp xxxx should also work |
10:28 |
bshum |
But yes I prefer bug xxxxx |
10:28 |
* Dyrcona |
usually does lp #### |
10:28 |
Dyrcona |
But, personal choice. |
10:34 |
Dyrcona |
jboyer-laptaupe: use UTF-32BE; # Make your output files as large as possible. :) |
10:34 |
Dyrcona |
With BOM, of course. |
10:36 |
|
RoganH joined #evergreen |
10:38 |
jboyer-laptaupe |
Dyrcona, I'm trying to output something that won't make yaz-marcdump throw up, I don't think that would do it. ;) |
10:39 |
Stompro |
testing multiple bugs display, sorry for the spam, bugs 1485240, 1485240 |
10:39 |
pinesol_green |
Launchpad bug 1485240 in Evergreen "Remove last vestiges of script-based circ rules" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1485240 |
10:39 |
Stompro |
testing multiple bugs display, sorry for the spam, bugs 1485240, 1484655 |
10:39 |
pinesol_green |
Launchpad bug 1484655 in Evergreen 2.8 "ftp://ftp.mozilla.org has moved to http://archive.mozilla.org" (affected: 1, heat: 6) [High,Fix committed] https://launchpad.net/bugs/1484655 |
10:40 |
Stompro |
Hmm, that didn't work. |
10:40 |
Stompro |
Unless it watches what it just did, and doesn't repeat bugs that were recently displayed. |
10:42 |
|
collum joined #evergreen |
10:42 |
jeff |
keep in mind that the docs may not match the version of the module presently loaded. |
10:43 |
Dyrcona |
jboyer-laptaupe: Fun thing, is a lot of MARC are actually ISO-8859-1 or some MS encoding when they should be MARC-8. |
10:44 |
Dyrcona |
jboyer-laptaupe: Good luck! :) |
10:44 |
bshum |
Stompro: pretty sure it doesn't repeat bugs for X time where X is beyond my recollection. |
10:45 |
Stompro |
I'm testing over at #openils-evergreen, and the multiple bug display worked fine there, so it was just refusing to display the same bug again immediatly. |
10:46 |
bshum |
Indeed |
10:48 |
jboyer-laptaupe |
Dyrcona: Hah! looks like what I'm seeing isn't my problem anyway. Just trying to use yaz-marcdump to break records into line mode and then rebuild them as marc doesn't work (at least not with these Overdrive records...) |
10:50 |
mmorgan |
Anyone seen anything like this: |
10:50 |
jboyer-laptaupe |
computers-- |
10:51 |
mmorgan |
An item that's checked out and has reached MAXFINES is marked Lost. |
10:51 |
mmorgan |
The patron is charged $9.96 for the lost item |
10:51 |
mmorgan |
A payment of $10.00 is made. |
10:51 |
mmorgan |
The item remains in the patron's list of Checked Out items and retains the status Lost. The patron's Bills screen shows a balance of $-.04 on the transaction. |
10:52 |
mmorgan |
When I try and reproduce this, I get a payment of $9.96 recorded with $.04 in change. The circulation transaction is closed, and (in our case) the item status flips to Lost and Paid. |
10:53 |
mmorgan |
After refunding the $.04, the transaction closed and the item changed to Lost and Paid appropriately. |
10:56 |
Dyrcona |
jboyer-laptaupe: I'd dump them to marcxml to look at/edit them, if you want to rebuild them later. Plus, you could just load the marcxml as is after. |
10:56 |
kmlussier |
mmorgan: Did the staff person accidentally conert the change to a patron credit? |
10:56 |
kmlussier |
convert |
10:56 |
Dyrcona |
mmorgan: Yep. Seen that before. |
10:56 |
mmorgan |
Meant to mention that we have turned off patron credits, so, no :) |
10:56 |
jboyer-laptaupe |
Dyrcona, that |
10:57 |
jboyer-laptaupe |
s not a bad idea. We still want to rebuild them as binary marc to use with the stream importer (for vandelay match/merge/etc.) but xml is a much better intermediate format. |
10:57 |
Dyrcona |
mmorgan: Hopefully, the new conditional negative balance branch fixes that. |
10:57 |
Stompro |
bshum: is the git plugin integration limited to displaying new commits? Or can someone dispaly info about an arbitrary commit by using a certain format? |
10:58 |
bshum |
Stompro: if given a commit hash, the bot will try to link to the full URL |
10:58 |
Dyrcona |
commit 8d14cfb562d8e72e25a7d90cbb5370bf904ccf1c |
10:58 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1484655: ftp://ftp.mozilla.org moved to http://archive.mozilla.org - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8d14cfb> |
10:58 |
bshum |
It parses messages in channel for that. |
10:58 |
Dyrcona |
I think the first 6 digits are enough. |
10:58 |
Stompro |
bshum, does it take a full has, or can it use a .... .thanks Dyrcona. |
10:58 |
bshum |
Sounds about right |
10:59 |
mmorgan |
Dyrcona: Yes! looking forward to that, but I'm wondering what the circumstances around this might be, and if there are other items that really should be lost and paid, but aren't. |
10:59 |
bshum |
But bear in mind it only works automatically for Evergreen master, OpenSRF master, and... |
10:59 |
Dyrcona |
git guarantees that the first so many digits of a hash are unique in a given repository, IIANM. |
10:59 |
bshum |
@git gitrepos |
10:59 |
pinesol_green |
bshum: MARC still isn't dead yet, alas |
10:59 |
bshum |
Hmm |
10:59 |
bshum |
@list git |
10:59 |
pinesol_green |
bshum: gitrehash, repolist, and shortlog |
10:59 |
jeff |
i tend to use seven chars. |
11:00 |
bshum |
@git repolist |
11:00 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
11:00 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
11:00 |
pinesol_green |
bshum: evergreen_website (Evergreen Website, branch: master) |
11:00 |
pinesol_green |
bshum: sipserver (SIPServer, branch: master) |
11:00 |
jeff |
which matches what git log --oneline uses |
11:00 |
bshum |
Those are the only branches it tracks regularly. |
11:00 |
bshum |
Working is not among them |
11:00 |
bshum |
And it'll only announce git changes for the main branch tracked |
11:00 |
bshum |
I guess it will work with commits in the repo branches. |
11:01 |
bshum |
So stuff from rel_2_8, etc. will work |
11:04 |
jeff |
neat. patron has an item on a list, can't remove it from the list. |
11:04 |
jeff |
oh. i didn't even check to see if it was on the list several times. |
11:05 |
Dyrcona |
jeff: Yeah, that's a bug. |
11:05 |
Dyrcona |
I've seen lists with the same thing on it in the database dozens of times. |
11:06 |
* Dyrcona |
wonders if he made a LP bug for that.... |
11:06 |
jeff |
yeah. we actually had an automated process that resulted in a few lists with... let's just say a non-trivial number of duplicate entries. |
11:06 |
Dyrcona |
Patrons can do it in the OPAC. |
11:07 |
jeff |
said automated process coupled with another automated process which attempted to retrieve these lists on an interval for caching a json feed. i think it got to the point where the retrieval would time out before the query completed. |
11:07 |
Dyrcona |
Largely because there's no feedback that the item was added to the list, patrons will often add it several times before they look at the list and see it is there. |
11:07 |
Dyrcona |
It only shows up once in the OPAC, but you'll see multiple entries in the database bucket. |
11:08 |
* jeff |
nods |
11:08 |
Dyrcona |
I have a local ticket that I made about it in June of last year, but never made a launchpad bug. |
11:08 |
jeff |
and indeed, this bucket has four items, but one of the items is there 15 times and the other is there 41 times. |
11:09 |
Dyrcona |
I started working on a script to clean them up and a possible solution in the UI, but other things came up. |
11:10 |
Stompro |
testing git integration, looking at commit 0f8ec1 |
11:10 |
pinesol_green |
[evergreen|Bill Ott] LP#1394989: Do not include deleted users when retrieving for Collections - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0f8ec14> |
11:10 |
|
ericar_ joined #evergreen |
11:10 |
Dyrcona |
By "started working on," I probably mean just thinking about an implementation. |
11:11 |
jeff |
Dyrcona: Did you ever come across signs of what UI-side circumstances could contribute to so many duplicate entries? |
11:11 |
Dyrcona |
jeff: Yes, the lack of a message saying the item was added to the list. |
11:11 |
jeff |
One or two duplicates due to $REASONS isn't too concerning, but when I come across 15 and 41 here, I wonder. |
11:12 |
jeff |
This particular user isn't one I normally think of as being likely to click a button 41 times because they didn't receive obvious feedback. :-) |
11:12 |
Dyrcona |
The code also doesn't check if it is already in the bucket. It gets added as often as you say to add it. |
11:12 |
Dyrcona |
jeff: You'd be surprised. |
11:12 |
* jeff |
nods |
11:13 |
Dyrcona |
A unique index /could/ fix it, but I recall discussion with miker that it could be desirable to have duplicate entries in a staff bucket under some circumstances. |
11:13 |
* jeff |
nods |
11:14 |
Dyrcona |
As I said, my looking into it stalled as vacation and other things came up. |
11:14 |
jeff |
I know the subject of duplicate bucket contents has come up here before, with at least the three of us participating. |
11:14 |
* jeff |
nods |
11:14 |
Dyrcona |
There is a launchpad bug about the lack of feedback on that interface. |
11:14 |
Dyrcona |
Fixing that would go some way toward helping. |
11:15 |
Dyrcona |
My testing didn't reveal any scenarios other than a patron clicking the button 41 times that would cause it to get added 41 times. |
11:16 |
Dyrcona |
The dates on the bucket entries also ruled out an older bug. |
11:17 |
jeff |
looks like about three dupes per second on this example here. |
11:18 |
Dyrcona |
That sounds a bit fast for a human, but not impossible. |
11:19 |
Dyrcona |
Could be double clicking involved, but that seems like a stretch. |
11:20 |
Dyrcona |
I'd have to look again, but the dupes all seemed like they were created with minutes of the original going in. |
11:20 |
Dyrcona |
And they were happening as recently as the day that I last looked into it. |
11:20 |
Dyrcona |
Usually, there were only a handful up to two dozen or so dupes. |
11:21 |
Dyrcona |
I reproduced it on my own book bags, by asking to add the books more than once. |
11:21 |
jeff |
Jun 27 and Aug 1 here. We're on 2.7. |
11:21 |
Dyrcona |
I never saw dupes when only adding it once. |
11:22 |
Dyrcona |
I saw this before we were on 2.7. |
11:22 |
jeff |
I've asked the user for more details, including if they have an unusual noscript config for our site. |
11:23 |
Dyrcona |
Maybe that has something to do with it, but I've seen it on too many different patrons to blame something like noscript. |
11:24 |
jeff |
hah. just tried to add an item to a list with chrome debug tools open and debug tools closed and my browser tab wsod'd |
11:24 |
jboyer-laptaupe |
Dyrcona: Thanks for the suggestion, using marcxml as an intermediate file works fine now. |
11:27 |
jeff |
but indeed, that single attempt to add to list resulted in a duplicate entry. |
11:27 |
jeff |
too bad dev tools went away, or i might have more clues. |
11:27 |
yboston |
for the record, it sounds like I can go ahead and book the IRC practice time next week? |
11:28 |
Dyrcona |
jeff: https://jason.mvlcstaff.org/bbag_dupes.txt |
11:29 |
Dyrcona |
That's the information from my internal ticket, fwiw. |
11:29 |
jeff |
Dyrcona: thanks |
11:29 |
Dyrcona |
If you want to make a Launchpad bug, feel free to plagiarize. |
11:29 |
jeff |
oh, well here's part of the problem. it's a GET. |
11:29 |
* jeff |
frowns |
11:30 |
Dyrcona |
You can blame me for the bugs. I wrote the bulk of that. |
11:31 |
jeff |
hrm. another instance of dev tools closing, tab ending up white. that's just... an excellent reminder that i have other things that i need to be working on at the moment. |
11:31 |
jeff |
Dyrcona++ :-) |
11:35 |
Dyrcona |
I'll have to see if I can find the script mentioned in my ticket. |
11:36 |
jeff |
this receipt printer tracks number of cuts and kilometers of paper. |
11:37 |
jeff |
well, km of thermal head use. |
11:38 |
jeff |
i don't know if it distinguishes between "printing" and "feeding without printing" |
11:39 |
Dyrcona |
Found it: https://jason.mvlcstaff.org/bucket_item_dups.sql |
11:40 |
Dyrcona |
jeff: I'll see if I can condense the stuff from the links about into a lp bug today. |
11:40 |
Dyrcona |
s/about/above/ |
11:41 |
Dyrcona |
"kilometers" of paper....I'm curious: how many kilometers has it printed? |
11:42 |
jeff |
0.044 km, 1249 cuts. |
11:42 |
jeff |
this particular model has mostly been used for testing. |
11:42 |
jeff |
and printing names for a hat for summer reading drawings. |
11:42 |
jeff |
so, lots of short jobs. |
11:42 |
Dyrcona |
ok. not as interesting as one from a circ. desk. |
11:43 |
jeff |
right. |
11:43 |
jeff |
now i wonder about the printer embedded in the self checkout kiosks. |
11:43 |
* Dyrcona |
does something useful, like open a LP bug. |
11:43 |
jeff |
this is an epson. those are not. |
11:43 |
jeff |
Dyrcona++ |
11:57 |
Stompro |
yboston: At the conference, you did a presentation on launchpad... did you have any slides that went with that, or was that all live? |
11:58 |
bshum |
yboston always has slides, cause he's that epic and awesome. |
12:01 |
yboston |
Stompro: had some slides as a back up in case the networke choked, but I can't seem to find them |
12:02 |
yboston |
it was not a lot of content, just went through each screen |
12:02 |
|
yboston left #evergreen |
12:02 |
|
yboston joined #evergreen |
12:03 |
Stompro |
Thanks for looking, I'm planning on going over Launchpad next week with our EG Community group and just wanted remember what all you covered. |
12:03 |
yboston |
there used to be a wiki page that outlined the information that should be provided in an LP ticket. I used that as a guide |
12:05 |
|
jihpringle joined #evergreen |
12:08 |
|
bmills joined #evergreen |
12:14 |
* miker |
reads up and shivers at the memory of jeff's big bucket... ;) |
12:15 |
miker |
as for a reason for containers in general to allow duplicates, it's to manage (or record) additions over time, for whatever reason, as opposed to just a "snapshot" collection of things |
12:22 |
bshum |
mrpeters: I vaguely remember a couple offline issues after we upgraded to 2.8. For us it turned out to be problems with our offline.pl file, where it was pointed at the wrong database. |
12:22 |
bshum |
mrpeters: I think it's also happened before where our permissions were off and the offline directory wasn't writeable by the open-ils processes. |
12:23 |
bshum |
mrpeters: *offline-config.pl in /openils/conf/ |
12:24 |
bshum |
When we "upgraded" we moved database servers, so the hostname, etc. were all wrong for a bit. |
12:25 |
mrpeters |
bshum: let me give that a look |
12:26 |
mrpeters |
thanks |
12:27 |
mrpeters |
well heck, i dont even have an offline-config.pl -- how did that get missed |
12:27 |
Stompro |
yboston++ just found your intro to IRC slides. |
12:27 |
mrpeters |
probably because i didnt run eg-db-config with all of the normal options |
12:28 |
bshum |
mrpeters: It gets created as part of the eg-db-config, yeah |
12:29 |
mrpeters |
yep, i left that out...great catch Ben |
12:30 |
bshum |
mrpeters: Hope that fixes it. |
12:30 |
mrpeters |
bshum++ |
12:30 |
bshum |
It might just mean we've been burned before... :) |
12:30 |
bshum |
*whistles a happy tune* |
12:32 |
mrpeters |
pretty awesome with how many verisons i had to upgrade to get to 2.8.2 that this was the only major issue! devs++ |
12:32 |
mrpeters |
(and it was completely my oversight) |
12:33 |
mrpeters |
database version-upgrades were smooth as could be, so great work there -- in the past, i've run into errors at times -- this one was awesome, all ran to perfection |
12:40 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1435938: AddedContent: Add "clearcache" functionality - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=389f904> |
12:40 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1435938: Add link to clear cache from staff client - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5866795> |
12:40 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1435938: Wrap auth check around clearcache URLs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bc44b32> |
12:40 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1435938: Set no_cache on AC clear response - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7008535> |
12:40 |
pinesol_green |
[evergreen|Ben Shum] LP#1435938: Add release note for clear Added Content cache link - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9c92ac7> |
12:42 |
bshum |
Gah, sorry Stompro, didn't edit the commit properly on that merge to include your signoff line |
12:48 |
pinesol_green |
[evergreen|Jeff Davis] LP#1433328: Add class attribute to e-resource links in TPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a1961b0> |
12:48 |
pinesol_green |
[evergreen|Ben Shum] LP#1433328: Add release note for new class attribute for e-resource links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2714518> |
12:54 |
pinesol_green |
[evergreen|Jeff Davis] LP#1178377: Expose bib source in TPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4f4c29b> |
12:54 |
pinesol_green |
[evergreen|Doug Kyle] LP#1178377: Make bib source optional element from unapi.bre - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1e4a0d8> |
12:54 |
pinesol_green |
[evergreen|Ben Shum] LP#1178377: Add release note for new bib source variable in catalog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8881b23> |
12:58 |
bshum |
Oops |
12:58 |
bshum |
Need to stamp that... |
12:58 |
bshum |
Calling 0923 |
12:59 |
bshum |
Okay, better. |
13:01 |
jeff |
Dyrcona: found at least one contributing factor. If something has eaten the Referer, adding to a list will loop. Depending on browser, you'll get X duplicates and potentially it'll retry a few times. :-) |
13:02 |
Dyrcona |
jeff: That might be related to a bug about that feature not working in the staff client. |
13:02 |
pinesol_green |
[evergreen|Ben Shum] LP#1178377: Stamping upgrade script for unapi to include bib source - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4662c52> |
13:03 |
Dyrcona |
I'm still working on a bug report. I stopped for lunch. |
13:03 |
* jeff |
nods |
13:03 |
jeff |
no rush. :-) |
13:03 |
Dyrcona |
I can't find the bug that I swear exists for there being no feedback when adding to a book bag. |
13:08 |
|
buzzy joined #evergreen |
13:08 |
Dyrcona |
So, I went to file a new bug and these were found: bug 1182547 and bug 1181018 the latter flagged as a duplicate of the former. |
13:08 |
pinesol_green |
Launchpad bug 1182547 in Evergreen "OPAC -"Add to my list" not displaying properly" (affected: 10, heat: 46) [Undecided,Confirmed] https://launchpad.net/bugs/1182547 |
13:08 |
pinesol_green |
Launchpad bug 1182547 in Evergreen "duplicate for #1181018 OPAC -"Add to my list" not displaying properly" (affected: 10, heat: 46) [Undecided,Confirmed] https://launchpad.net/bugs/1182547 |
13:09 |
Dyrcona |
ha... |
13:10 |
kmlussier |
Dyrcona: Heh, that's happened to me before. |
13:11 |
Dyrcona |
I guess pinesol is aware of duplicate bugs.... |
13:11 |
kmlussier |
Sometimes pinesol_green is too smart. |
13:13 |
jeff |
oh how i do like local::lib and/or perlbrew and cpanm |
13:13 |
|
jihpringle_ joined #evergreen |
13:14 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1485240: More Legacy Circ Script Removal - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=57b1355> |
13:27 |
|
bmills joined #evergreen |
13:28 |
Dyrcona |
jeff: lp 1485695 |
13:28 |
pinesol_green |
Launchpad bug 1485695 in Evergreen "Duplicate Record Entries in My List/Bookbag Record Buckets" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1485695 |
13:29 |
Dyrcona |
Feel free to add your findings to that. I basically used an edit version of the summary from my internal ticket. |
13:32 |
|
bmills joined #evergreen |
13:42 |
Stompro |
bshum: That isn't a big deal, I need to do things properly and create signoff branches, serves me right :-) |
13:53 |
Stompro |
miker, should the hook for lp 1124498 also be changed to au.expire |
13:53 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 6, heat: 40) [Wishlist,Confirmed] https://launchpad.net/bugs/1124498 |
13:59 |
miker |
Stompro: expire is pretty specific to patrons (today) but it would not hurt. so, +1 |
14:01 |
pinesol_green |
[evergreen|Michael Peters] LP#1361900 Move Acquistions Admin Menu - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d49f524> |
14:01 |
pinesol_green |
[evergreen|Ben Shum] LP#1361900: Add release note for Acq Admin Menu move - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6d53ac9> |
15:02 |
|
jlitrell joined #evergreen |
15:41 |
mrpeters |
Re: https://bugs.launchpad.net/evergreen/+bug/1013786 (man thats old!) -- do we want to make this a YAOUS -- or should we just enforce a strong password (what is our definition?). I forget how JSPAC acted, but I think when you logged in for the first time with your initial 4 digit pin you were prompted to change your password to one that met the requirements. Am I remembering that correctly? |
15:41 |
pinesol_green |
Launchpad bug 1013786 in Evergreen "tpac: Check for password strength at login" (affected: 7, heat: 36) [Medium,Confirmed] - Assigned to Jeff Godin (jgodin) |
15:42 |
tsbere |
mrpeters: I believe there should still be a password regex setting floating around that jspac used in the first place. |
15:43 |
mrpeters |
ah, that simplifies things a bit doesn't it |
15:43 |
tsbere |
I think there was a default as well, but I am not sure what kind of default. "If your password is all digits you have to change it" maybe? |
15:44 |
tsbere |
Actually, tpac may already be checking the regex when you change your password.... |
15:45 |
mrpeters |
hmm, filtering on "password" in Library Settings Editor I don't see one regarding strength. There is a "Password format" though |
15:45 |
mrpeters |
Regular expression defining the password format |
15:46 |
tsbere |
mrpeters: Looks like the default has generally been "digit, letter, and 7 characters", per comments in Account.pm. And I think in this case "password format" is what you are looking for. |
15:46 |
tsbere |
global.password_regex |
15:46 |
* jeff |
nods |
15:46 |
mrpeters |
yeah, that rings a bell |
15:47 |
jeff |
and of course part of the idea here is to ensure that the patron knows what the requirements are. |
15:47 |
mrpeters |
and i think that is indeed the YAOUS |
15:47 |
jeff |
the text explaining that probably belongs in config.tt2 |
15:47 |
jeff |
at least, that's what i had in mind. |
15:47 |
mrpeters |
absolutely, would need to add that to the change password page |
15:47 |
tsbere |
The default regex in Account.pm uses negative lookahead to implement the rules. (?=.*\d+.*)(?=.*[A-Za-z]+.*).{7,} |
15:49 |
jeff |
tmux does... interesting things with env variables. |
15:49 |
mrpeters |
anyone want to collaborate on this? I can help with the template modifications I think, but might struggle a bit with pulling global.password_regex from the database and into the change password page. |
15:49 |
mrpeters |
be nice to put a 3 year old "bug" to bed |
15:49 |
jeff |
mrpeters: sure. please add your thoughts/input to the bug. i'll be sure to take a look! |
15:49 |
jeff |
or if you'd just like to sign off / review, that's great also. |
15:49 |
tsbere |
mrpeters: What do you mean "pull from the database and into the change password page"? |
15:50 |
mrpeters |
we would want the change your password page to use the strength requirement from global.password_regex right? |
15:50 |
tsbere |
It already does use that, actually. |
15:50 |
mrpeters |
so its configurable and not hard coded onto that page |
15:51 |
mrpeters |
ok, so maybe this is just a matter of explaining that on the page |
15:51 |
tsbere |
There is a "you didn't set global.password_regex, so here is a reasonable default regex" but if you set the regex it uses it. |
15:51 |
mrpeters |
hmm, that complicates things a bit. Putting a note on the page would vary from location to location. Maybe that's why it wasn't done. |
15:52 |
jeff |
mrpeters: the code i have currently directs you to the change password page with a given message suggesting that your change your password. memory serves, the holdup (other than perhaps some strings) was that some people thought it important to FORCE password change. |
15:53 |
mrpeters |
right -- i know i originally was one who thought it was important to continue forcing the change because I always considered the 4 digit pin as "temporary" but after more years, i see more and more libraries who just use that pin forever |
15:53 |
mrpeters |
so I'm not sure I have the same stance today |
15:54 |
mrpeters |
I like your thought of "We reccomend that you set a new password" message, but if what tsbere says is true, they would never see that since their password would have to match the regex if one is set |
15:55 |
tsbere |
mrpeters: The idea being "check what they input against the regex, if their password doesn't match the regex force them to the change password page after login instead of to where they were originally going with the message showing" |
15:56 |
mrpeters |
myself and Dyrcona were the only voices (on the bug page, at least) with an opinion -- and mine certainly has changed over time. Perhaps the functionality we have now is sufficent. If libraries are saavy enough to set the regex, they are likely saavy enough to set a message about the requirements. |
15:56 |
Dyrcona |
We recommend that you pick a random page from a random book to copy and paste as your password. Anything less than 255 characters is too short to provide any sort of security. |
15:56 |
mrpeters |
Perhaps we could adjust the description for that YAOUS to include a note to modify the tt2 to inform patrons what the requirements are? |
15:57 |
tsbere |
set the default message in the tt2 to "This system has not yet set their password strength hint, so maybe you should assume it is set to 'insane'." :P |
15:57 |
mrpeters |
:) |
15:59 |
jeff |
my approach is default text that explains the known default regex in human terms, and a fallback to something vague / empty. either could be overridden by config.tt2. |
15:59 |
jeff |
this should give the best bang for the buck, while still avoiding text that doesn't match the setting. |
15:59 |
mrpeters |
i dont think there is a default though... |
16:00 |
mrpeters |
i just looked at actor.org_unit_setting in my master server and i dont see anything set for global.password_regex |
16:00 |
tsbere |
mrpeters: I threw the default up a few minutes ago. |
16:00 |
tsbere |
mrpeters: The code uses a "letter, number, and at least 7 chars" default regex if global.password_regex isn't set |
16:01 |
mrpeters |
ah, so it does use that one from the perl module if you don't set it. OK, I misunderstood. |
16:01 |
mrpeters |
but that only occurs if you try to change your password, correct? you're never "forced" to do so |
16:02 |
tsbere |
Currently, which is part of the problem ;) |
16:02 |
jeff |
that is the proposed change, yes. |
16:02 |
mrpeters |
i would support that |
16:03 |
mrpeters |
we can only do so much to encourage strong passwords, we're giving out 4 digit pins as defaults, maybe we need to rethink the default password generation code to make it stronger and meet the default regex |
16:03 |
mrpeters |
i know thats extra work, but, thinking of all possible angles for solving this |
16:05 |
hopkinsju |
Hi. I'm new here. |
16:06 |
hopkinsju |
I've also thought that the 4 digit pin seemed at odds with the settings for password strength. |
16:06 |
mrpeters |
:P hey justin |
16:07 |
hopkinsju |
Like "Hey, since it's easier on us, here's a 4 digit pin. When you get home to change the password - which we totally know you're gonna do - you have to come up with somethign complicated" |
16:07 |
hopkinsju |
Hi Mike! |
16:07 |
tsbere |
Then there is the "we want people to have strong passwords! But we don't want the default to ever be anything other than the last 4 digits of their phone number because we might have to tell them the password otherwise...." |
16:07 |
mrpeters |
so, maybe we should postpone this and consider giving out stronger passwords that meet the requirements from the start, and then let people change them as they like, within the requirements |
16:07 |
Bmagic |
passwords-- |
16:08 |
Bmagic |
retinascan++ |
16:08 |
mrpeters |
i think the original intent of the 4 digit pin was that it was "temporary" and you were forced to change it upon first login with jspac -- in that respect, i think the 4 digit pin was fine |
16:08 |
jeff |
mrpeters: i support the idea of generating stronger default/initial passwords, but not ones that are permitted to bypass the reminder/requirement to change. |
16:08 |
hopkinsju |
Should we talk about using a method of looking at password "strength" other than meeting a regex or having some number of characters from different sets? |
16:09 |
mrpeters |
but i think more libraries than we think are now using the pin as permanent passwords |
16:09 |
jeff |
mrpeters: that is beyond the scope of the current bug, but since you asked and since i've given it thought before, i think i'll create a new bug for that particular issue. |
16:09 |
hopkinsju |
mrpeters: I think you're definitely right there. |
16:10 |
mrpeters |
sorry jeff, don't mean to blow this wide open into something so big, but i saw this one in the list, and then saw i was the main one to complain about it so i figured i better speak up and try to help fix it after all of this time |
16:10 |
hopkinsju |
Personally, I just wandered into a wall of text from mrpeters and thought I better chime in. |
16:11 |
mrpeters |
So I guess the question is -- do we want to resolve the current bug for 2.9 -- by adding a message to the change password page explaining the strength requirements? |
16:11 |
jeff |
there is of course the option of not giving out an initial password at all, and jumping right to the password reset via email method to gain access. |
16:11 |
mrpeters |
jeff++ i like that |
16:11 |
hopkinsju |
jeff++ |
16:11 |
jeff |
mrpeters: that is my intent, yes. sorry if i hadn't made that clear so far. |
16:11 |
hopkinsju |
Libraries will hate that though |
16:11 |
mrpeters |
you think they will? |
16:12 |
hopkinsju |
I hear from various libraries all the time that "not everyone has an email address" |
16:12 |
mrpeters |
true |
16:12 |
mrpeters |
but if they dont have an email, are they likely using the OPAC much? |
16:12 |
hopkinsju |
Seems like a simple enough problem to remedy, but... |
16:12 |
Dyrcona |
No email address? You don't exist. |
16:12 |
hopkinsju |
mrpeters: I don't diasgree with your correlation of lack of email -> lack of OPAC use, but that doesn't prove it true. |
16:13 |
mrpeters |
couldn't the library use an email address internally to set passwords for those fringe cases? |
16:13 |
jeff |
i would not recommend that. |
16:13 |
hopkinsju |
And I still like the idea - I'm just putting it out there that some libraries *will* complain. Doesn't mean we shouldn't value security over that particular concern, though. |
16:13 |
tsbere |
I know of several people that fall into the "don't have an email address" category. They overlap 100% with the "don't have a library card" category though. |
16:13 |
mrpeters |
do we make an email a requirement for getting an opac account? |
16:14 |
jeff |
anyway, glad to see interest and agreement in this regard. |
16:14 |
mrpeters |
i mean, you can't register for online banking, message boards, etc. without an email account these days |
16:14 |
mrpeters |
you wouldnt be prevented from using the library, you just can't take advantage of the features provided by the My Account feature of the OPAC without providing a valid email address...seems fair |
16:15 |
mrpeters |
an email address is so easy to get, even if you only use it that one time to set your password |
16:16 |
mrpeters |
i'm honestly racking my brain trying to think of something I do online where i didn't have to provide an email address to sign up and use more than "basic" features. IRC, thats about all I'm coming up with. |
16:18 |
jeff |
while i agree that email addresses are easier to come by these days and that they are required for many things (including NickServ registrations on many large IRC networks), I'm not sure I can support the idea of requiring an email address to use the catalog. |
16:19 |
mrpeters |
taking away features at this point would be a negative, i agree |
16:20 |
mrpeters |
but, that shouldn't mean we can't evolve moving forward. is there a middle ground where we use an email first, and then if none is available, provide a fallback such as a postcard in the mail? |
16:21 |
mrpeters |
could create an A/T event to generate PDF's daily that would create postcards that the library could print and mail...though that costs money |
16:22 |
mrpeters |
another option would be an automated phone call, but not everyone would have the technology to do that. SMS to default phone number could work, since you can text to a landline (for a fee) but again, could get costly |
16:23 |
hopkinsju |
mrpeters: Don't you mention using A/T to generate PDF's again, buddy! Somebody mod me. I may need to kick/ban |
16:23 |
mrpeters |
haha :) |
16:23 |
hopkinsju |
;-) |
16:24 |
dbs |
My kids have email addresses of a sort, but I think many wouldn't |
16:25 |
mrpeters |
but you'd probably allow them to use one of yours for that purpose, right dbs? |
16:25 |
hopkinsju |
I set up an email address for my daughter - I use it to set up things for her. And when she's old enough, she can take the account over, change the password, etc. |
16:25 |
mrpeters |
but you raise a good point |
16:25 |
dbs |
(and my 9yo just spammed the small circle of aunts, uncles, and grandparents in her contacts list with a LinkedIn invite, so she's getting a break from computers for a bit) |
16:25 |
hopkinsju |
hahha |
16:25 |
hopkinsju |
LinkedIn. |
16:25 |
mrpeters |
hah! 9 and on LinkedIn!? Impressive!!! |
16:25 |
hopkinsju |
Good one, dbs |
16:26 |
dbs |
to be fair, she had 4 invites from one of her aunts so she finally broke down and joined LinkedIn |
16:26 |
dbs |
what wasn't very funny was seeing the email go out after she clicked on the "Connect with people you know!" that identified her full name and the public school that she attends |
16:27 |
hopkinsju |
*facepalm* |
16:27 |
dbs |
(her aunt also gets sucked into the same "Connect!" bait, clearly) |
16:27 |
mrpeters |
oh no! |
16:27 |
dbs |
anyway, I think it would be a tough sell for a lot of parents to require email addresses for their kids |
16:28 |
mrpeters |
i think you're right dbs -- but if we could come with a "fallback" option for those without email, I think the idea of taking the password part of registration out of staff hands would be welcomed. |
16:29 |
mrpeters |
After registration, you get an email telling you to visit the password reset URL and set your initial password. That would be nice. |
16:29 |
hopkinsju |
Let's table this for now guys. Revisit in 5 years when all infants are born with an email address? |
16:29 |
tsbere |
Default to no password at all, and leave the "generate" button as an option for staff? |
16:30 |
mrpeters |
tsbere: that could work -- could we force the staff to "generate" if no email is present? |
16:30 |
mrpeters |
or rather, should we |
16:30 |
berick |
hopkinsju++ |
16:31 |
tsbere |
There are a lot of options. I refuse to comment on what the best ones are. I also refuse to say what our librarians would prefer as they likely wouldn't agree on any one anyway. ;) |
16:31 |
dbs |
"Here's your library card, which is also a FIDO usb key" |
16:31 |
hopkinsju |
I'm going to start sharpening the pitchforks. Let me know what you decide. |
16:31 |
hopkinsju |
dbs++ |
16:33 |
mrpeters |
so, for the purposes of 2.9 beta -- should i create a branch that puts a message such as "Password requires 7 characters, and at least one numeric character" to the reset page? |
16:41 |
jeff |
Hrm. Using a trusty rusty export script, not sure why I only have 95k records exported after >1h runtime. |
16:42 |
jeff |
CPU bound for the most part. Perhaps it's just that this VM is more constrained than similar VMs in the past. |
16:42 |
mrpeters |
Would an error like " open-ils.trigger [WARN:47187:SendEmail.pm:74:] SendEmail Reactor: failed email template" be indicative of the SMTP host denying relay access? |
16:43 |
mrpeters |
i'm 99% sure that's what the problem is (new server, the ISP likely didn't update the allowed relay hosts) but wanted to make sure it wasn't possibly a problem with the template for this A/T event (which worked prior to the move to a new IP) |
16:45 |
dbs |
mrpeters: pro of adding that specific message being that that matches the default regex, con being that any site that changes the regex now has another template to update? |
16:46 |
mrpeters |
yep -- agreed |
16:46 |
mrpeters |
to repeat my thought from earlier, however, anyone who is saavy enough to set a new regex, probably knows to update that template |
16:49 |
dbs |
mebbe update http://docs.evergreen-ils.org/2.8/_settings_overview.html to add a note like "If you change this from the default, you will also need to override the password_reset.tt2 template" or something like that |
16:50 |
mrpeters |
i could make that happen |
16:50 |
mrpeters |
I also think we should update the description of that YAOUS to include the same note |
16:50 |
dbs |
Because we have lots of savvy people, but trying to hold too many details in your head, inevitably some things slip |
16:50 |
jeff |
Hrm. Only 1674 matches for WHERE marc LIKE '%�%' |
16:50 |
jeff |
still depressing, but not as bad as i thought. |
16:50 |
mrpeters |
no doubt! reminders are not a bad thing, in my eyes |
16:50 |
dbs |
mrpeters++ # sounds good |
16:52 |
mrpeters |
i'll have a branch tomorrow then to add the message, update that documentation (i'll coordinate with someone from DIG on that) and then an SQL script to change the description of the YAOUS (unless that isn't permitted at the beta stage) |
16:52 |
mrpeters |
or maybe that's not even in the database |
16:53 |
mrpeters |
ah yes, it is -- config.org_unit_setting_type |
16:56 |
mrpeters |
so i'd propose a simple UPDATE config.org_unit_setting_type SET description = 'Regular expression defining the required password format when resetting passwords. Note: Adjust description in config.tt2 to suit your requirements.' WHERE name='global.password_regex'; if that kind of database change is permitted at this stage in the game |
16:58 |
Stompro |
yboston, the subject of your email to the dig list about the irc practice has a different date & time than the body. Subject says 26th 3pm eastern, body says June 24th 2pm est. |
17:01 |
yboston |
Stompro: that is what I get for copy pasting |
17:06 |
yboston |
Stompro: I also has the date wrong from the text I pasted |
17:07 |
yboston |
Stompro: BTW, we shoudl coordinate to sign-off on each other's PGTAP tests at soem point this week |
17:08 |
|
mmorgan left #evergreen |
17:10 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:12 |
jeff |
Additional error details: |
17:12 |
jeff |
fatal: remote error: |
17:12 |
jeff |
Storage server temporarily offline. See https://status.github.com for GitHub system status. |
17:12 |
jeff |
Return Value = 1 |
17:21 |
|
_bott_ joined #evergreen |
17:26 |
Stompro |
yboston, yes to the pgtap signoffs, later this week works for me. |
19:01 |
|
jacobsd joined #evergreen |
19:03 |
|
jacobsd joined #evergreen |
21:16 |
pinesol_green |
[evergreen|Liam Whalen] LP1483509: tests for xml_famous5_to_text - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ff8d9d1> |
21:16 |
kmlussier |
Does bug 1331174 meet the criteria of requiring a new test before it can be merged? |
21:16 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
21:17 |
kmlussier |
I'm probably addressing the question to an empty room, but I see from my email that gmcharlt is still working. :) |
21:20 |
gmcharlt |
kmlussier: if nothing else, it meets the condition of being in a functional area where clear unit tests would be very, very nice :) |
21:20 |
kmlussier |
gmcharlt: Thanks! |
21:34 |
pinesol_green |
[evergreen|Bill Erickson] LP#483502 PGTAP test for evergreen.xml_escape(TEXT) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7fec477> |
21:46 |
pinesol_green |
[evergreen|Josh Stompro] LP#1478123: fix leak of file descriptors by Apache workers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ded781a> |
22:02 |
pinesol_green |
[evergreen|Josh Stompro] LP#1463097 - eg_db_config.in help text fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fa312e5> |
22:08 |
pinesol_green |
[evergreen|Josh Stompro] LP#1468404: Fix typo and ommissions in action_trigger_aggregator.pl help - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=88ae6a4> |