| Time |
Nick |
Message |
| 00:45 |
bshum |
@later tell dbs Hmm, for some reason I'm not seeing a webstaff.pot i18n file in Launchpad translations, so I wonder if maybe the sync from your bzr in LP needs some further manual tweaking to get underway. |
| 00:45 |
pinesol_green |
bshum: The operation succeeded. |
| 01:05 |
|
Mark__T joined #evergreen |
| 01:14 |
|
ningalls joined #evergreen |
| 04:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:29 |
|
ningalls joined #evergreen |
| 06:29 |
|
kmlussier joined #evergreen |
| 06:29 |
|
bshum joined #evergreen |
| 06:29 |
|
TaraC joined #evergreen |
| 06:29 |
|
mceraso joined #evergreen |
| 06:29 |
|
ldw joined #evergreen |
| 06:29 |
|
rangi joined #evergreen |
| 06:30 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 06:32 |
|
TaraC joined #evergreen |
| 06:32 |
|
mceraso joined #evergreen |
| 06:32 |
|
ldw joined #evergreen |
| 06:32 |
|
rangi joined #evergreen |
| 07:33 |
|
rjackson_isl joined #evergreen |
| 07:38 |
|
ericar joined #evergreen |
| 08:16 |
|
Dyrcona joined #evergreen |
| 08:19 |
|
Shae joined #evergreen |
| 08:20 |
|
akilsdonk joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:47 |
|
maryj joined #evergreen |
| 08:57 |
|
akilsdonk_ joined #evergreen |
| 08:59 |
|
Shae joined #evergreen |
| 09:36 |
|
RoganH joined #evergreen |
| 09:39 |
|
sarabee joined #evergreen |
| 09:48 |
|
yboston joined #evergreen |
| 10:14 |
* dbs |
hails the supreme potatoe |
| 10:14 |
bshum |
Heh |
| 10:14 |
berick |
heh |
| 10:15 |
dbs |
lord knows we need another dan here |
| 10:15 |
Dyrcona |
dbs++ |
| 10:27 |
Dyrcona |
yboston: Any chance of lp 1484281 being fixed by Tuesday? |
| 10:27 |
pinesol_green |
Launchpad bug 1484281 in Evergreen "authority data may be deleted during propagation with current values of authority.control_set_authority_field" (affected: 1, heat: 10) [Critical,Confirmed] https://launchpad.net/bugs/1484281 - Assigned to Yamil (ysuarez) |
| 10:28 |
yboston |
Dyrcona: yes |
| 10:29 |
Dyrcona |
Also, how would I reproduce that? Just run authority_control_fields.pl? |
| 10:29 |
Dyrcona |
yboston: Cool. I can help you with that if you want. |
| 10:29 |
yboston |
Dyrcona: will try to push a fixed working branch today |
| 10:29 |
Dyrcona |
yboston++ |
| 10:29 |
yboston |
off the top of my head |
| 10:30 |
yboston |
I think if you open an authority to be edited in the MARC editor |
| 10:30 |
yboston |
lets say "miles davis" |
| 10:30 |
yboston |
if that authority record has several bib records attached |
| 10:31 |
yboston |
if for soem reason the authority record had a subfield $4 or $e set to "cmp" or "composer" |
| 10:31 |
yboston |
if I then edited out the $4 or $e, that cahnge will be propagated in all linked bibs |
| 10:31 |
yboston |
the thing is that the $4 and $e shoudl exist only in the bibs and not in the auth |
| 10:33 |
Dyrcona |
I see. |
| 10:33 |
yboston |
with the proper fix, if for some reason an auth record (incorrectly) has subfield $4 or $e, if they are removed in the auth record, it will not propagate |
| 10:33 |
Dyrcona |
Those are 100 fields in the auth, right? |
| 10:33 |
yboston |
also 110 |
| 10:33 |
yboston |
not sure about the auth see (4xx) and see also (5xx) |
| 10:33 |
Dyrcona |
Thanks. That gives mes something to look for. |
| 10:34 |
Dyrcona |
I'll see if we have any records that might be affected. |
| 10:34 |
yboston |
at this point I have two major things to do 1) fix the bad lien endings in one of my early working branch commit |
| 10:34 |
yboston |
2) write the "upgrade" code |
| 10:34 |
yboston |
I got some great information from bshum on Monday |
| 10:34 |
Dyrcona |
I could do #1 pretty quickly if you like. |
| 10:34 |
yboston |
on how to write upgrade code |
| 10:35 |
Dyrcona |
bshum++ |
| 10:35 |
yboston |
What I want to learn is what is the proper working branch live cycle |
| 10:35 |
yboston |
like, is it OK for me to just fix that commit and just destroy my branch a recreate it, when is it OK to force push a working branch |
| 10:36 |
yboston |
for now I was juts going to create a fresh branch... |
| 10:36 |
yboston |
then just cherry pick my exisitng commit; fix the bad one, then just add the upgrade code |
| 10:36 |
yboston |
I already have a pgTAP test |
| 10:36 |
Dyrcona |
It is usually OK to force push over a working/user branch. |
| 10:36 |
bshum |
I tend to force push mistakes away, as long as I haven't seen people pick my code up. |
| 10:36 |
Dyrcona |
Generally not OK on a working/collab branch. |
| 10:36 |
bshum |
And even then, I'd probably do it and tell people I did. |
| 10:37 |
bshum |
:) |
| 10:37 |
yboston |
that is what I thought |
| 10:37 |
bshum |
But yes user vs. collab like Dyrcona says |
| 10:37 |
yboston |
now if I want to do an interactive rebase, to create one nce commit for my fix? |
| 10:37 |
Dyrcona |
Yeah, good idea to follow up with a comment on the bug about a force push. |
| 10:37 |
yboston |
do I do it and then force push it to my original working branch? |
| 10:37 |
Dyrcona |
Yes. |
| 10:38 |
yboston |
or should I create a new working branch for the squashed commit? |
| 10:38 |
Dyrcona |
That's one way. |
| 10:38 |
yboston |
of course if the working branch has been around a whiel and I know peole have used it, I can see that is a good time to create a new workign branch? |
| 10:38 |
Dyrcona |
Both methods are used. |
| 10:39 |
Dyrcona |
I tend to force push over existing branches, but sometimes I make a new branch. |
| 10:39 |
yboston |
Dyrcona & bshum: good to know |
| 10:39 |
Dyrcona |
It's really up to you in your user branch. |
| 10:39 |
yboston |
I had seen the phrse (forced push) in git log; not sure if it is done by git or manually? |
| 10:39 |
dbs |
bshum: hmm, not really sure what's going on with the bzr thing |
| 10:40 |
Dyrcona |
I personally don't have a problem with making a new test branch of my own when a force push happens. |
| 10:40 |
* dbs |
will peek |
| 10:40 |
* Dyrcona |
decides not to pun on bzr/bazaar/bizarre. |
| 10:40 |
yboston |
also, I am crytal clear now that it is OK to force push on a user workign branch, though not on a collab brnach unless coordinated with others |
| 10:40 |
bshum |
dbs: Appreciate it, it looked a little weird to me |
| 10:41 |
yboston |
*crystal |
| 10:41 |
Dyrcona |
yboston: pretty much. Though most of my collab branches have not really been collabs. |
| 10:41 |
bshum |
I didn't see anything really pending in the import queue, but I wondered if there is a place we have to define new files for translation |
| 10:41 |
yboston |
Dyrcona: makes sense |
| 10:41 |
bshum |
Or if it just magically knew what the latest .pot files were... |
| 10:41 |
yboston |
they were aspirational collab branches :) |
| 10:42 |
Dyrcona |
The reasoning is partly because only the owner can push to a user branch, but anyone with working access can push to a collab branch. |
| 10:42 |
yboston |
bshum & Dyrcona: thanks for all the info |
| 10:42 |
Dyrcona |
yw yboston. :) |
| 10:43 |
Bmagic |
mmorgan: Did you get that test machine to trigger to lost? |
| 10:43 |
yboston |
Dyrcona: I knew that, but I still wanted to confirm that it is OK to force push after doign a rebase with master on my own user working branch |
| 10:43 |
dbs |
https://code.launchpad.net/~denials/evergreen/master looks like it is plugging along |
| 10:44 |
yboston |
Dyrcona: then again, even though I knew that others could push to collabs, I had not realized how it would be a much bigger no-no to push to a collab branch; thank for helping me lreaize the implications |
| 10:45 |
mmorgan |
Bmagic: Had to push it aside for a bit, so, No. Did get your message, though about the editor = 1. Thanks. I'll try looking at it this afternoon. |
| 10:46 |
Bmagic |
mmorgan: right on, I have been gone a couple of days also. Let me know how it goes. We have this code running in production |
| 10:46 |
dbs |
"The first time you import a template, or a translation whose language or template are not clear, you'll need to review it manually." -- I'll check the queue |
| 10:47 |
mmorgan |
Bmagic++ |
| 10:47 |
mmorgan |
That's Awesome! |
| 10:48 |
dbs |
AHA: https://translations.launchpad.net/evergreen/master/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot |
| 10:48 |
* dbs |
clicks "Approve" on each of those |
| 10:50 |
Dyrcona |
Bmagic: Most systems backdate book drop checkins assuming that they were dropped in yesterday after hours. |
| 10:51 |
Dyrcona |
Evergreen does the same. |
| 10:51 |
dbs |
bshum: still 145 .po files in the approval queue; not really sure why they're there though. |
| 10:52 |
dbs |
e.g. auth.properties in fr_ca appears to differ only by the header metadata (changed 2014 instead of 2009) |
| 10:53 |
Dyrcona |
dbs: The for loop given in the release instructions doesn't actually work to skip metadata changes. |
| 10:53 |
Dyrcona |
dbs: All changed files end up being added and committed anyway. |
| 10:54 |
dbs |
Dyrcona: I thought I had written to manual checking for changes; not sure if someone else tried to automate it |
| 10:55 |
dbs |
"(This part needs automation): Then, via the magic of git diff and git add, go through all of the changed files and determine which ones actually have string changes. Recommended approach is to re-run git diff after each git add." |
| 10:55 |
dbs |
http://docs.evergreen-ils.org/2.8/_updating_the_translations.html |
| 10:55 |
Dyrcona |
I'm refering to this: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:release_process:evergreen:2.8 |
| 10:55 |
dbs |
So I think berick accidentally committed the lot back in 2014 if I recall correctly |
| 10:56 |
Dyrcona |
Scroll down a bit and there's a for loop that is supposed to not commit metadata changes, but it is incorrect. |
| 10:56 |
dbs |
Dyrcona: yeah, I didn't write that |
| 10:56 |
dbwells |
The semi-automated step always seemed to work alright for me, from what I could tell. |
| 10:57 |
Dyrcona |
I wrote a python script and used it for commit 9a0d5b4bd1a365b1911713f026780d0625734fcb |
| 10:57 |
pinesol_green |
[evergreen|Jason Stephenson] Update Translations - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9a0d5b4> |
| 10:57 |
Dyrcona |
dbwells: Look at it carefully. All of the files get added, some files get added twice, none ever get reset. |
| 10:57 |
berick |
it worked for me, too |
| 10:57 |
berick |
when I used it |
| 10:58 |
dbwells |
maybe that page is wrong |
| 10:59 |
dbwells |
(didn't exist back when) |
| 10:59 |
berick |
maybe |
| 11:00 |
Dyrcona |
I know that for loop in the release instructions doesn't work. |
| 11:00 |
Dyrcona |
Anyway, I wanted to talk about why we don't add metadata changes in the po files at the developers' meeting next week. |
| 11:01 |
Dyrcona |
I'll post my Python to a gist sometime this weekend. |
| 11:01 |
dbwells |
On that page, the "git add ." shouldn't be there, I think. |
| 11:03 |
Dyrcona |
--cached would have to be removed from the next git diff in that case. |
| 11:03 |
dbwells |
or, actually, it needs to be between the update_pofiles and the newpot step |
| 11:04 |
berick |
dbwells: yes, that |
| 11:04 |
Dyrcona |
Once the files are added, a git reset $file would be needed to unstage it. |
| 11:05 |
Dyrcona |
But I just got tired of typing Return or k and then Return, so I automated it. :) |
| 11:05 |
Dyrcona |
If you look at the beta branch, you'll see the metadata changes crept in, because I didn't notice the loop wasn't working until after I was fed up. :) |
| 11:07 |
berick |
Dyrcona: you should document your script on the wiki page |
| 11:07 |
|
Shae joined #evergreen |
| 11:07 |
Dyrcona |
berick: I plan to after I add some docstrings and a copyright header/license header. |
| 11:07 |
berick |
not having to step through every modified file would be great |
| 11:07 |
berick |
Dyrcona++ |
| 11:08 |
|
vlewis joined #evergreen |
| 11:09 |
Dyrcona |
Funny thing about git: most commands have --porcelain options to feed to scripts. I found git diff easier to parse without word-diff=porcelain. |
| 11:14 |
|
Christineb joined #evergreen |
| 11:26 |
dbwells |
Dyrcona: berick: in the meantime, I have updated http://evergreen-ils.org/dokuwiki/doku.php?id=dev:release_process:evergreen:2.8 to reflect the steps and order which worked for me, and ended up with newpot changes like this: http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7d8628dfa3432ed005c0a07b3ffddf41833c68d4 |
| 11:26 |
pinesol_green |
[evergreen|Dan Wells] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7d8628d> |
| 11:27 |
|
buzzy joined #evergreen |
| 11:27 |
berick |
dbwells++ |
| 11:28 |
Dyrcona |
dbwells++ |
| 11:29 |
dbs |
dbwells++ |
| 11:30 |
dbs |
Might be nice to carve the i18n part of that wiki document out into the official docs |
| 11:34 |
|
bmills joined #evergreen |
| 11:58 |
|
jlitrell joined #evergreen |
| 12:00 |
|
rlefaive joined #evergreen |
| 12:02 |
|
Shae joined #evergreen |
| 12:29 |
|
bmills1 joined #evergreen |
| 12:33 |
|
jihpringle joined #evergreen |
| 12:57 |
|
bmills joined #evergreen |
| 13:02 |
|
bmills joined #evergreen |
| 13:23 |
* dbs |
wonders whether tonight is the night to implement in-db circ |
| 13:25 |
dbs |
reading http://docs.evergreen-ils.org/2.8/_circulation_rules.html and the db schema, it doesn't look like it's possible to set circ limits by patron profile (e.g. profs can have 50 books checked out, students get 30) |
| 13:28 |
Dyrcona |
db: It is. |
| 13:28 |
Dyrcona |
heh. |
| 13:28 |
Dyrcona |
I mean: dbs: It is possible. |
| 13:29 |
dbwells |
dbs: That's still in the penaly threshold table. |
| 13:29 |
dbwells |
or, maybe you mean using actual limit groups. If so, nevermind me. |
| 13:29 |
Dyrcona |
It's still possible with limit groups. |
| 13:30 |
Dyrcona |
make a separate matchpoint for each profile group and apply a different limit to each. |
| 13:31 |
dbs |
Thanks Dyrcona and dbwells |
| 13:32 |
Dyrcona |
We use the penalties for total items out and use limits for certain types of items, like DVDs, etc. |
| 13:36 |
Dyrcona |
In thinking about it, I'd make a matchpoint for faculty and another for students, leaving everything else blank, |
| 13:36 |
Dyrcona |
and then apply the appropriate limit to each one with fall through enabled. |
| 13:36 |
dbs |
I'm guessing permission.grp_penalty_threshold.org_unit is going to apply to actor.usr.home_ou, not asset.copy.circ_lib |
| 13:37 |
|
Callender joined #evergreen |
| 13:39 |
Dyrcona |
dbs: Yes, and it is aware of the hierarchy. |
| 13:39 |
Dyrcona |
So if the depth is 0, it applies everywhere. |
| 13:47 |
dbs |
Yeah, I think that's the opposite of what we want; university students should still be able to borrow at the medical school if they only have fines at the uni. |
| 13:47 |
Dyrcona |
But, when the checks are made in the in db circ function, it goes by action.circulation.circ_lib |
| 13:50 |
dbs |
I don't know why in-db circ makes me feel like I've lost 50 IQ points |
| 13:51 |
Dyrcona |
It's different from what you're used to. |
| 13:51 |
Dyrcona |
You could set the depth of the penalties to the branch or similar. |
| 13:52 |
Dyrcona |
Then they'd only apply locally, if I'm thinking straight. |
| 13:53 |
dbs |
Mmm, yeah, if it goes by action.circulation.circ_lib, then I think that would work |
| 13:53 |
dbwells |
This is Dyrcona explaining how to use in-db circ ;) http://devopsreactions.tumblr.com/post/42345786031/senior-developer-explaining-how-to-use-his-library |
| 13:54 |
|
Shae joined #evergreen |
| 13:54 |
Dyrcona |
That's from relatively recent memory. I was looking into the code again last week. |
| 13:54 |
bshum |
Heh |
| 13:54 |
Dyrcona |
heh. |
| 13:55 |
dbs |
hah! |
| 13:55 |
dbs |
Dyrcona++ # thanks |
| 13:56 |
Dyrcona |
I felt like I'd lost a few IQ points trying to get AWS S3 to work yesterday. |
| 13:57 |
jeff |
yesterday i ended up discovering that lxml.etree element trees do interesting things. |
| 13:57 |
jeff |
as in, given a marcxml collection with various records, and iterating over it like this: |
| 13:57 |
jeff |
for record in collection: |
| 13:58 |
jeff |
if you use record.xpath(...) to match elements, depending on how you construct your xpath you're going to get matching elements that are siblings in the larger collection object, not contained in record itself, because record contains some connection to the parent still. |
| 13:58 |
Dyrcona |
jeff: When I need to xml in Python, I pretty always use lxml. |
| 13:58 |
Dyrcona |
That's documented. |
| 13:59 |
Dyrcona |
use relative xpath to get the children. absolute xpath parses the whole document. |
| 13:59 |
* Dyrcona |
learned the "hard" way, before he found it right there in the docs. :) |
| 14:00 |
Dyrcona |
But, I prefer lxml's xpath over Python's xml xpath, because the former is more complete. |
| 14:01 |
Dyrcona |
Also faster and based on libxml2. |
| 14:01 |
jeff |
The interesting thing was that given 1000 records, it shifted over time. The first match wasn't always the first record. It changed every X or so. |
| 14:01 |
Dyrcona |
That is interesting. I never noticed that, but I wasn't parsing that many elements. |
| 14:05 |
jeff |
round tripping record to a string and back broke the association and "fixed" things. once i realized what was happening (after making a few test cases) i switched to relative xpath expressions and was happier. |
| 14:05 |
jeff |
but it was a bit confusing at first. |
| 14:05 |
jeff |
once I figured it out I recalled seeing something in the docs, but I think I just found what I was thinking of and it's almost entirely unrelated: ``Note that a string result returned by XPath is a special 'smart' object that knows about its origins. You can ask it where it came from through its getparent() method, just as you would with Elements'' |
| 14:06 |
Dyrcona |
yep. |
| 14:06 |
Dyrcona |
I'm not sure if that behavior is unique to lxml or if it comes from libxml2. |
| 14:10 |
jeff |
I still haven't found where it's documented. I'll let you know if I find out. :-) |
| 14:14 |
|
ningalls joined #evergreen |
| 14:14 |
|
bmills joined #evergreen |
| 14:27 |
jboyer-isl |
People with opinions on tests: I'm torn between simplistic "is there a row with this value in this table" vs actually testing the functionality "if you insert this record, are these fields extracted as expected?" |
| 14:28 |
jboyer-isl |
The functional tests seem more robust (if the rows or tables involved in the back end changes, the test still works) but I didn't know if there was a wider preference. |
| 14:29 |
gmcharlt |
jboyer-isl: testing intent is better than testing implementation details |
| 14:29 |
gmcharlt |
(as a rule of thumb) |
| 14:29 |
jboyer-isl |
That's what I was leaning toward. |
| 14:30 |
jboyer-isl |
I'm likely going to dump the 350+ "is there a row with these 3 fields" tests and replace them with 10-20 of the "are the correct fields extracted from this test marc" variety. |
| 14:31 |
Bmagic |
Dyrcona: About the backdating, I think the library was being misled when the message on the UI contained a date that wasn't what they entered |
| 14:33 |
tsbere |
jboyer-isl: Just ensure you test every combination already in the test set. ;) |
| 14:35 |
jboyer-isl |
tsbere: easy :p "SELECT ok((SELECT * FROM config.upgrade_log WHERE version = 'VERSION MY PATCH APPLIED'), 'fixed fields upgrade'); |
| 14:35 |
jboyer-isl |
;) |
| 14:41 |
bshum |
Bmagic: That's odd... I thought hyphens was fixed for SMS texting a couple versions ago. |
| 14:41 |
bshum |
Gibberish no, it'll die on that without fault |
| 14:42 |
Bmagic |
bshum: It might be working in the place holds interface, but not when you update the hold |
| 14:42 |
bshum |
Ahhh, updating the hold. |
| 14:42 |
bshum |
Gotcha |
| 14:42 |
bshum |
Yeah I was thinking of https://bugs.launchpad.net/evergreen/+bug/1016654 |
| 14:42 |
pinesol_green |
Launchpad bug 1016654 in Evergreen 2.3 "TPAC: System should disallow patrons from entering SMS number in wrong format" (affected: 3, heat: 20) [Low,Fix released] |
| 14:42 |
bshum |
Which was fixed back in 2.3 era |
| 14:43 |
bshum |
The fix that got pushed looks to only affect it on the A/T side of things |
| 14:44 |
bshum |
Where it'll automatically strip out hyphens |
| 14:44 |
bshum |
Presumably that means we can still input garbage into the fields. |
| 14:44 |
Bmagic |
Dyrcona https://bugs.launchpad.net/evergreen/+bug/1437109 sounds like it could be the same as https://bugs.launchpad.net/evergreen/+bug/1489915 |
| 14:44 |
pinesol_green |
Launchpad bug 1437109 in Evergreen "renew and edit due date features do not calculate correctly in web staff client" (affected: 3, heat: 14) [Undecided,Confirmed] |
| 14:44 |
pinesol_green |
Launchpad bug 1489915 in Evergreen "Back date checkin web based staff client reports conflicting date" (affected: 1, heat: 6) [Undecided,New] |
| 14:45 |
Bmagic |
bshum: Oh, so it's fixed at the AT level, interesting, So the sms will not fail. Does it strip out /\D// (any non digits)? |
| 14:46 |
tsbere |
Bmagic: $sms_notify =~ s/[- ()]//g; |
| 14:46 |
tsbere |
Assuming it matches m/^[- ()0-9]*$/ |
| 14:46 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=adc1e00adad32f1c3f9049b9417584b14aba3576 |
| 14:46 |
pinesol_green |
[evergreen|Thomas Berezansky] TPAC - SMS Number Munging - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=adc1e00> |
| 14:46 |
bshum |
That's the changeset from that bug. But yeah. |
| 14:46 |
Bmagic |
so, it will fail if you use another character? |
| 14:47 |
tsbere |
If you have a letter or other non-listed symbol it will not remove them |
| 14:47 |
bshum |
And I don't think we should automatically discount letters for the field. |
| 14:47 |
* tsbere |
frequently jams his alias in when he actually cares about getting a notification, for example |
| 14:47 |
bshum |
Yeah, what tsbere says |
| 14:47 |
tsbere |
In fact, the way my account is configured, the *digits* won't work. |
| 14:47 |
Bmagic |
gotcha |
| 14:48 |
Bmagic |
well, I suppose my bug report can be deleted then |
| 14:48 |
* tsbere |
was getting too much spam sent to the digits version |
| 14:52 |
Bmagic |
tsbere: was there a bug where you posted your code? |
| 14:53 |
tsbere |
Bmagic: I believe bshum just linked to it? https://bugs.launchpad.net/evergreen/+bug/1016654 |
| 14:53 |
pinesol_green |
Launchpad bug 1016654 in Evergreen 2.3 "TPAC: System should disallow patrons from entering SMS number in wrong format" (affected: 3, heat: 20) [Low,Fix released] |
| 14:53 |
Bmagic |
oh, I see it now, sorry about that |
| 14:53 |
bshum |
Yeah and I pulled up the exact commit hash too |
| 14:53 |
tsbere |
That too. ;) |
| 14:53 |
bshum |
I'm updating the bug that Bmagic filed |
| 14:53 |
bshum |
With a link to this log |
| 14:55 |
Bmagic |
bshum++ |
| 14:55 |
Bmagic |
tsbere++ |
| 14:56 |
jeff |
Anyone care to look at their SMS notification volume and tell me if you'd be completely opposed to paying something like $0.0075/ea? It would be nice to start to fold some of this Twilio support into Evergreen itself, or just decide that it belongs outside of Evergreen. Knowing if other Evergreen libraries are completely opposed to paying for SMS delivery would probably help there. |
| 14:57 |
hopkinsju |
+1 |
| 14:57 |
bshum |
jeff: So what's Twilio? |
| 14:57 |
* bshum |
steps back to the beginning of the story to understand jeff's question |
| 14:58 |
hopkinsju |
We get a question fairly regularly about "How do we send text messages to {{Backwater pay as you go carrier}}?" |
| 14:58 |
jeff |
one of a few providers of telephony services. they're nice, popular, offer lots of options, have a nice API. |
| 14:59 |
jeff |
bshum: the context of my question was "we don't use SMS to email built into A/T, opting instead to pay per message", and wondered if others were interested in that kind of thing, or if the price was prohibitive. |
| 15:00 |
jeff |
I could probably get more responses from a mailing list post, but since the query was somewhat topical and I was looking at irc... I asked here. |
| 15:00 |
bshum |
jeff: All things considered, I think libraries pay for lots of stuff that's pointless (cough, cough, Boopsie), so I think it's worth consideration if it gets us broader/better coverage. |
| 15:00 |
bshum |
But that being said, free is free. And if the email gateway approach works well enough for some people, I wouldn't break that in favor of whatever you're proposing to have added. |
| 15:01 |
jeff |
No, despite the very idea being a bit ugly, I don't think I could advocate removing the SMS to email gateway options entirely. :-) |
| 15:01 |
jeff |
But recommending against their use becomes easier when it's a matter of "do this instead" :-) |
| 15:02 |
bshum |
jeff: So that's 0.0075 per sms. Is that attempt or successfully sent message? |
| 15:02 |
bshum |
:D |
| 15:02 |
* bshum |
doesn't mind paying for stuff that actually works, vs. paying for every attempted sending that might be failing |
| 15:03 |
bshum |
Especially given what Bmagic noted about potential, let's call that user error :) |
| 15:03 |
tsbere |
I believe you get better "did it go through" with most services (the gateways seem to silently drop invalid numbers) |
| 15:03 |
bshum |
Hmm |
| 15:04 |
tsbere |
And with the services you don't have to worry as much about carrier. If someone takes their number to another carrier it doesn't matter |
| 15:04 |
hopkinsju |
I've received messages back from gateways - but the way our system works that would never make it all the way back to the user. |
| 15:04 |
hopkinsju |
Right. And removing the need to know carrier is a big step forward, I think. |
| 15:05 |
hopkinsju |
I think we will see more and more MVNO's out there. |
| 15:05 |
tsbere |
hopkinsju: I haven't run into many gateways that have told me the number wasn't valid. A couple, yes, but not many. |
| 15:06 |
hopkinsju |
tsbere: I don't disagree - I was more making that point that even if we *did* get a message back the user'd never see it. |
| 15:06 |
tsbere |
Well yea, but that is going to generally be the case. I would be more interested in ensuring *staff* saw it. |
| 15:07 |
hopkinsju |
One catch about using a paid option is that for consortial type environments, knowing who owes what would be tricky. |
| 15:07 |
jeff |
Yeah. That's something we're going to start working on soon -- taking action when we've gotten a STOP or when the number isn't receiving the messages. Something like removing/disabling that notification method and adding a message on the patron account, almost like the other contact invalidators. |
| 15:08 |
jeff |
bshum: to answer your question about being billed per attempt vs actual delivery, "it depends". |
| 15:08 |
hopkinsju |
And right, overisght. Currently there's really no reason not to allow anonymous users to use the email to sms option - but where it could be abused by a bot, even something as cheap is Twilio could break a small library's bank. |
| 15:09 |
jeff |
hopkinsju: sure there's reason to not use anonymous SMS -- almost the same as being an SMTP open relay. |
| 15:10 |
jeff |
hopkinsju: if you're talking about the "text this call number to me" function. |
| 15:10 |
hopkinsju |
jeff: I feel like the combination of knowing the carrier *and* the number offers some protection against that. |
| 15:10 |
jeff |
Not really. |
| 15:10 |
hopkinsju |
How so? |
| 15:10 |
jeff |
it's rather trivial to get/guess that with reasonable accuracy. |
| 15:11 |
jeff |
especially if you're targeting a single or small handful of numbers. |
| 15:11 |
hopkinsju |
I wont' speculate about the dificulty or what constitutions reasonable accuracy, but I can say that our OPAC is not required for those attempts to be made. |
| 15:14 |
jeff |
bshum: if you attempt to message an invalid number, you will not be billed. if you attempt to message a number that isn't actually capable of receiving SMS, a lot of the "will i be billed" answer will vary based on the remote provider, the nature of the "why can't this receive SMS", etc. |
| 15:19 |
jeff |
bshum: typically, and on the two tests i just did, if you're sending to a landline you will not be charged. |
| 15:19 |
jeff |
bshum: and perhaps more importantly, you'll know that the message did not go through. |
| 15:28 |
jeff |
hopkinsju: for consortial environments, as long as you didn't mind $1/mo per billed entity, and as long as you could agree on something logical like "home_ou of user pays", billing could be reasonably well sorted out. |
| 15:29 |
jeff |
bonus there would be that the messages would come from a number dedicated to the billed entity, and in the future could do things like actually receive texts, etc, etc. |
| 15:32 |
jeff |
Any other concerns/issues/challenges that come to mind? |
| 15:35 |
|
bmills joined #evergreen |
| 15:36 |
* bshum |
can't think of anything right now, but also feels that Fridays are not his best thinking days. :P |
| 15:36 |
bshum |
Especially Fridays after a nice pizza lunch |
| 15:38 |
|
bmills1 joined #evergreen |
| 15:38 |
jeff |
Hrm. Of course, the API and the docs seem to differ on whether or not I'm going to be charged for this particular SMS. |
| 15:39 |
jeff |
docs say "status of undelivered will still be charged", but the API call shows a cost of null USD :-) |
| 15:40 |
tsbere |
jeff: Undelivered to a PITA carrier = charged. Undelivered to a nice carrier = no charge? |
| 15:40 |
tsbere |
Possibly "undelivered to no carrier" not being charged... |
| 15:41 |
jeff |
"failed" is "the carrier didn't even accept this" |
| 15:41 |
jeff |
"undelivered" is "the carrier accepted this but we didn't get a confirmation that it was delivered" |
| 15:41 |
* tsbere |
also has several landlines in his text message history on his phone |
| 15:41 |
jeff |
phone phones are messy. some things are less messy with something like twilio. |
| 15:43 |
jeff |
i still have a price of null after several minutes of it being in a status of "undelivered" (as opposed to "queued" which I expect to not have a price yet) :-) |
| 15:44 |
tsbere |
jeff: What carrier did you attempt to send to? |
| 15:45 |
jeff |
a voip provider called Jive, and the local cable company (who also does voip phones), Charter/Spectrum |
| 15:45 |
jeff |
I do know that some landline carriers can/will forward SMS to landlines via some kind of voice relay. I don't have personal experience with that. |
| 15:45 |
tsbere |
Well, I know that the local cable company here not only does phones, but also text messaging for those phones. Though they usually want you to install an app on your smartphone to use that part... |
| 15:46 |
tsbere |
And at least one VOIP company in the area has text messaging as well, for that matter. But other "landline" providers in the area don't. |
| 15:47 |
Bmagic |
What would cause a transaction to stay open after it was checked in ($0 fines on the circ however it was overdue long enough to get marked lost) ? |
| 15:48 |
jeff |
one of the interesting things with a service like Twilio is that we could port our number to them and then use the library's main number for SMS :-) |
| 15:49 |
tsbere |
Bmagic: Backdating. The fact it was lost? Many little gotchas.... |
| 15:50 |
Bmagic |
The lost trigger applied the cost of the book as a line item. Checking it in, voided those, but the transaction remained open |
| 15:50 |
Bmagic |
This is happening on repeat |
| 15:51 |
Bmagic |
We want it to void the bills, and close the transaction (because it goes to 0) upon checkin |
| 15:51 |
Bmagic |
It's staying on the patrons account under "other" |
| 15:53 |
mmorgan |
Bmagic: I've seen the situation where an item is overdue, the fine is paid, then the item is marked "Lost". Fines get voided, bill gets charged, but the previous payment on the fine zeroes out the bill. Transaction remains open, item remains on patron record as "Lost" |
| 15:54 |
mmorgan |
Bmagic: What release are you on? |
| 15:54 |
Bmagic |
2.8.2 |
| 15:56 |
mmorgan |
2.8.3 for us. I would be curious to see if what you're seeing happens in 2.9, with the conditional negative balance code. |
| 15:57 |
mmorgan |
Bmagic: Have these transactions gone to Long Overdue before going to Lost? |
| 15:57 |
Bmagic |
no, just straight to lost |
| 15:58 |
mmorgan |
OK :) |
| 16:04 |
bshum |
It's not a setting right Bmagic? Like the one that doesn't auto close transactions? |
| 16:06 |
bshum |
"Close transaction when lost balance equals zero" |
| 16:06 |
bshum |
I have that set to true for our consortium, fwiw. |
| 16:06 |
bshum |
2.8-ish system |
| 16:08 |
mmorgan |
bshum: Looks like it's the opposite: "Leave transaction open when lost balance equals zero" |
| 16:08 |
mmorgan |
We have that unset, so I believe, false. |
| 16:09 |
bshum |
Right, so I mean to do what Bmagic wants, i.e. close the transaction, that should probably be set to true. |
| 16:10 |
bshum |
? |
| 16:10 |
tsbere |
bshum: Based on what mmorgan says it should be unset, or maybe outright set to false |
| 16:10 |
bshum |
mmorgan: Or wait, you mean my setting is reversed of what your setting says? |
| 16:10 |
bshum |
That's odd. |
| 16:10 |
tsbere |
Depends on who is correct as to the label, I guess. >_> |
| 16:11 |
* tsbere |
is too lazy to dig it up himself |
| 16:11 |
bshum |
Well I just typed what my label said. |
| 16:11 |
mmorgan |
bshum: Does yours really say "Close transaction when lost balance equals zero"? That IS odd. |
| 16:12 |
bshum |
mmorgan: That's what it says on my screen anyways. |
| 16:12 |
* bshum |
checks stock.. |
| 16:12 |
bshum |
Entertaining... |
| 16:12 |
* mmorgan |
wonders what version of Evergreen bshum is REALLY running ;-) |
| 16:13 |
bshum |
The special kind. |
| 16:13 |
bshum |
Don't be jealous now. |
| 16:14 |
bshum |
Oh, interesting... that's a super old setting |
| 16:15 |
mmorgan |
Bmagic: anyway, "Leave transaction open when lost balance equals zero", is unset for us, and the transaction closes when a Lost item is checked in and the bill is voided. |
| 16:16 |
bshum |
mmorgan: Well that is surprising indeed. |
| 16:17 |
bshum |
The org unit setting I have is called "circ.lost.xact_finish_on_zero" |
| 16:17 |
bshum |
And the one in stock is "circ.lost.xact_open_on_zero" |
| 16:17 |
bshum |
And I don't have that one at all. |
| 16:17 |
* berick |
has circ.lost.xact_open_on_zero |
| 16:17 |
bshum |
So that's probably why my system behaves the way I think it should |
| 16:17 |
berick |
on my dev vm |
| 16:18 |
bshum |
Cause having mine set to true is the same as having yours unset or false |
| 16:18 |
bshum |
So the default behavior would be to close the transactions. |
| 16:18 |
bshum |
I guess. |
| 16:18 |
jeff |
bshum: It'a almost as if you aren't even running Neergreve at all! What kind of bizarro world is this? |
| 16:18 |
bshum |
It's probably something that changed in master at some point. |
| 16:18 |
bshum |
And we didn't have the right upgrade script or something |
| 16:19 |
bshum |
Or maybe we used the wrong upgrade script at some point in the 2.2 era... |
| 16:19 |
jeff |
bug 793550 |
| 16:19 |
pinesol_green |
Launchpad bug 793550 in Evergreen 2.3 "xact_finish (prematurely?) set on claimed returned item if transaction balance reaches zero" (affected: 7, heat: 38) [Medium,Fix released] https://launchpad.net/bugs/793550 |
| 16:20 |
bshum |
Aha |
| 16:20 |
bshum |
jeff++ |
| 16:20 |
bshum |
Yeah it looks like I had the earlier version of the change |
| 16:21 |
Dyrcona |
I thought that sounded familiar. :) |
| 16:21 |
bshum |
Yep, it changed between iterations |
| 16:21 |
bshum |
Sigh |
| 16:21 |
bshum |
I guess I should go fix our system |
| 16:21 |
jeff |
I would expect that you have the setting but no code you're running uses the setting. |
| 16:21 |
bshum |
Yeah, pretty much |
| 16:21 |
jeff |
Effect is likely the same, but changing the setting probably wouldn't do anything. :-) |
| 16:22 |
bshum |
Indeed. |
| 16:22 |
bshum |
I should probably fix it though so that we're closer to stock... |
| 16:22 |
bshum |
So that I don't have weird moments like this. |
| 16:22 |
* bshum |
must have pushed the earlier version to production at some point during the signoff process. |
| 16:23 |
bshum |
Oh well. |
| 16:23 |
bshum |
Anyways... Bmagic should check how his system is set for that setting, the one mmorgan (and everyone else) says is the one :) |
| 16:23 |
bshum |
mmorgan++ |
| 16:23 |
hopkinsju |
mmorgan++ |
| 16:24 |
hopkinsju |
Bmagic is murdering help desk tickets right now. |
| 16:24 |
jeff |
WHY. WON'T. YOU. STAY. DEAD? |
| 16:24 |
hopkinsju |
I'll have to do the ++ing until he get's back. |
| 16:24 |
hopkinsju |
jeff++ |
| 16:25 |
mmorgan |
bshum++ #looking to settings in the first place |
| 16:26 |
jeff |
our current system has an automated update that happens on solved tickets, end result being that three or so days after a ticket has been marked as solved, i see an email notification that has that ticket's subject. sometimes it catches me off guard "what? AGAIN?" |
| 16:28 |
Dyrcona |
jeff: I would turn that off. |
| 16:30 |
jeff |
it's part of the built-in soft/hard close, request confirmation (and "rating") from user. it... dunno. i could probably take it or leave it, but i'm not sure how users feel about it. |
| 16:30 |
jeff |
probably just as annoyed as me. |
| 16:30 |
jeff |
though that might be an incorrect guess. :-) |
| 16:31 |
tsbere |
We still get "Thanks!" replies to the "the ticket was resolved" emails. And anyone replying to a ticket re-opens it... |
| 16:31 |
jeff |
yeah. i long ago looked into an RT tweak that would deal with those, but then i just started taking the time to say "You're welcome!" :-) |
| 16:31 |
jeff |
(and we stopped using RT) |
| 16:46 |
dbs |
hmm. feeling close to having our in-db rules sorted out, for the most part, but not getting the expected block on checkouts when permission.grp_penalty_threshold for PATRON_EXCEEDS_FINES is exceeded |
| 16:47 |
dbs |
PATRON_EXCEEDS_CHECKOUT_COUNT limit is being respected though. weird |
| 16:52 |
dbs |
weird, actor.user_standing_penalty.create id= set_date= usr=foobar staff= standing_penalty=1 org_unit=105 stop_date= note= isnew= ischanged= isdeleted= |
| 16:52 |
tsbere |
dbs: Are fine limits specified at multiple levels? Or, perhaps, can you see the message in the staff client about it? |
| 16:52 |
dbs |
so it looks like the standing penalty for PATRON_EXCEEDS_FINES is supposed to be set, but that doesn't block circ? |
| 16:53 |
mmorgan |
dbs: org_depth problem maybe? |
| 16:53 |
dbs |
oh that's weird |
| 16:54 |
dbs |
so, it looks like the penalty did get set, but only after I tried doing the extra checkout |
| 16:54 |
dbs |
once I refreshed the patron, then it popped up with the expected alerts |
| 16:55 |
dbs |
So I _think_ we're good. We'll see next week :) |
| 16:55 |
dbs |
thanks, tsbere++ and mmorgan++ |
| 16:55 |
dbs |
(and Dyrcona++ and dbwells++ from earlier) |
| 17:00 |
Bmagic |
bshum: mmorgan: sorry, I was on the phone. The setting is set to null for both "Leave transaction open when lost balance equals zero" and "Leave transaction open when long overdue balance equals zero" |
| 17:00 |
Bmagic |
Do those need to be "false" ? |
| 17:01 |
mmorgan |
Bmagic: For good measure, I would explicitly set them to False. |
| 17:04 |
mmorgan |
Yay! just tried the scenario from http://irc.evergreen-ils.org/evergreen/2015-08-28#i_199831 with the code from lp 1331174, and the transaction closed :) |
| 17:04 |
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 |
| 17:04 |
jeff |
mmorgan++ testing |
| 17:04 |
mmorgan |
Unfortunately, the mark lost part will need to wait until next week :-( |
| 17:13 |
|
mmorgan left #evergreen |
| 17:24 |
* dbs |
wonders if A/T needs to run to set the penalties that block circ |
| 17:40 |
jeffdavis |
dbs: I'm not 100% sure, but it sounds correct to me that the PATRON_EXCEEDS_FINES penalty isn't applied until the patron tries to do something where the penalty would matter (like checkout/renew another item). I don't think it's trigger-related. |
| 17:42 |
dbs |
jeffdavis: the problem is that the checkout that should be prevented actually succeeds; then the block kicks in |
| 17:43 |
jeffdavis |
ah |
| 17:52 |
csharp |
dbs: I'm pretty sure we saw that "off by one" problem with PINES too |
| 17:52 |
* csharp |
reviews our settings |
| 17:53 |
csharp |
our policy is $10.00 for PATRON_EXCEEDS_FINES and our setting is $10.00 |
| 17:54 |
csharp |
I don't know if that's a case of "it works as expected" or "our staff got used to how it works" |
| 17:54 |
csharp |
I do remember confusion when we made the switch, though |
| 17:56 |
dbs |
csharp: thanks, that's helpful! |
| 17:58 |
miker |
dbs: with a setting of 10.00, would you expect the block at that value? I read the setting as "max allowed fine, beyond this you're blocked" |
| 17:59 |
dbs |
dbs: our setting is $0.01 and the next checkout was allowed even though the person had a $3.50 fine |
| 18:00 |
dbs |
We just cut over to in-db, though, so if (say) the fine generator applies blocks to accounts at intervals, then that might just be a temporary glitch |
| 18:00 |
miker |
ah! I had not read up far enough |
| 18:01 |
* dbs |
heads homewards |
| 18:01 |
dbs |
thanks everyone :) |
| 18:32 |
|
bmills joined #evergreen |
| 18:55 |
|
bmills1 joined #evergreen |
| 19:03 |
|
gdunbar joined #evergreen |
| 20:31 |
|
Dyrcona joined #evergreen |
| 20:32 |
Dyrcona |
@later tell jeff I found a solution that works for connecting to S3 on FreeBSD: https://discussion.dreamhost.com/thread-146308-post-184210.html#pid184210 |
| 20:32 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 21:58 |
|
gsams joined #evergreen |
| 22:06 |
|
sbrylander joined #evergreen |
| 22:09 |
|
sarabee joined #evergreen |
| 22:13 |
|
sbrylander joined #evergreen |
| 22:16 |
|
sarabee joined #evergreen |
