| Time |
Nick |
Message |
| 00:35 |
|
boson joined #evergreen |
| 03:29 |
|
Jillianne joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
agoben joined #evergreen |
| 08:17 |
* csharp |
wonders how many other gmail users end up on the Italian Linux Society's website when clicking git.evergreen-ils.org links that break across mulitple lines |
| 08:26 |
jeff |
yeah, bug 28649 from 2011 |
| 08:26 |
pinesol_green |
Launchpad bug 28649 in Launchpad itself "mail word wrapping breaks urls and other words" [Low,Triaged] https://launchpad.net/bugs/28649 |
| 08:26 |
jeff |
i suspect the fastest way to fix would be to have an alternate url for git branches and start using it more frequently in lp comments, etc. |
| 08:27 |
jeff |
or, continue with the status quo and the occasional lament. |
| 08:27 |
csharp |
very interesting - I thought it was Gmail - I don't recall this issue when using our organzation's Zimbra instance before |
| 08:28 |
csharp |
it's not that big a deal |
| 08:28 |
csharp |
though I wonder if the ILS wonders why so many North Americans are so interested in their page now :-) |
| 08:30 |
jeff |
it's a combination of Launchpad breaking the URL across multiple lines, and some mail clients (including gmail) turning url-looking strings in text messages into links. |
| 08:31 |
csharp |
ah - that makes sense |
| 08:32 |
jeff |
so the first part of the url gets linked beause it starts with http://, and the second part gets linked presumably because it starts with a domain-looking string and in all other ways looks like a url where someone didn't include the leading "http://" |
| 08:38 |
JBoyer |
miker, good call on the TT fixes on lp 1274999, but now I'm stuck on something else; the Next link isn't appearing anymore. I tested this thing multiple times (it was annoying looking for titles with exactly 10 copies, etc...) can you see anything obviously wrong? |
| 08:38 |
pinesol_green |
Launchpad bug 1274999 in Evergreen "Next 10 Link erroneously available at the end of holdings in OPAC, intermittent " [Undecided,Confirmed] https://launchpad.net/bugs/1274999 |
| 08:39 |
JBoyer |
Or anyone else that would like to poke at templates! Feel free to tell me how I've err'd, because this is maddening. :/ |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:42 |
JBoyer |
D: The worst! Works as expected on a migration server, falls over on dev and production. Sparta? This is madness! |
| 08:44 |
csharp |
JBoyer: is there a good concerto record to test on? |
| 08:45 |
csharp |
nevermind - I found one |
| 08:46 |
JBoyer |
You need a couple, one with exactly copy_limit (usually 10) copies, and one with more than that |
| 08:48 |
Stompro |
jeffdavis, is the Sitka new items carousel for wordpress plugin available for others to use? |
| 08:52 |
csharp |
JBoyer: with miker's branch I'm not seeing the "Next X" link either, if that helps |
| 08:55 |
JBoyer |
csharp, miker, even with my branch they're not working correctly on 2/3 servers here. For instance: http://evergreen.lib.in.us/eg/opac/record/8205944 has no link, but 15 copies. Put mig. in from of evergreen and it does work. :( |
| 08:55 |
csharp |
actually, I'm not seeing it with your branch either |
| 08:55 |
JBoyer |
Same changes! |
| 08:55 |
csharp |
yeah - I can confirm that behavior on my master test server |
| 08:56 |
csharp |
if I revert both commits, it works |
| 08:56 |
JBoyer |
Well, "works," that's where you need a record with total copies == copy_limit. |
| 08:57 |
csharp |
well, I mean that the link reappears |
| 09:00 |
JBoyer |
Well that's embarrassing... The mig server where I monkey patched this to test has ctx.copy_offset + ctx.copy_limit < total_copies, but my patch has ctx.copy_offset + ctx.copy_limit > total_copies which is completely backward... |
| 09:00 |
JBoyer |
csharp++ for looking. |
| 09:01 |
* JBoyer |
goes to fix the branch, and our servers. |
| 09:02 |
csharp |
JBoyer: happy to help! |
| 09:05 |
miker |
JBoyer: sorry for not testing the branch, I just wanted to clean up the syntax. feel free to squash my commit into yours if you keep it |
| 09:06 |
JBoyer |
I'm definitely making your changes also. And it's evident *I* didn't fully test the branch either, so no harm there. :/ |
| 09:07 |
JBoyer |
I'll probably force update my branch to have a single commit that matches your changes (AND work), but if you'd like to sign off on it after that that would be great. |
| 09:21 |
|
yboston joined #evergreen |
| 09:28 |
|
kmlussier joined #evergreen |
| 09:29 |
csharp |
jeff: I got curious about the launchpad mail URL wrapping issue - apparently the python library they use *should* be accommodating long URLs with hyphens: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/doc/textformatting.txt |
| 09:29 |
csharp |
so it's probably someone calling the wrong function or not calling it the right way |
| 09:29 |
csharp |
and with that, I step away for a few hours |
| 09:29 |
csharp |
(http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/doc/textformatting.txt#L247 is the key line) |
| 09:43 |
|
Christineb joined #evergreen |
| 10:07 |
|
_adb joined #evergreen |
| 10:09 |
|
abowling1 joined #evergreen |
| 10:28 |
_adb |
does srfsh take any command line options? i haven't found a manpage and passing --help didn't output anything |
| 10:28 |
miker |
_adb: it does have a few options. sec... |
| 10:30 |
miker |
well, one |
| 10:31 |
miker |
so, it can take a --safe option, which disables the in-shell ! command. works like ! in vim, and executes an external shell (bash, etc) command and displays the results |
| 10:31 |
miker |
and it can take a file name, which it will read for srfsh commands and execute them in sequence |
| 10:31 |
_adb |
ok, thanks |
| 10:31 |
_adb |
right |
| 10:31 |
miker |
which lets it be used as a #! line in an executable script |
| 10:32 |
miker |
well, the stdin reading lets it do that, I guess |
| 10:33 |
_adb |
alright that's all i needed, thank you, miker++ |
| 10:37 |
|
bmills joined #evergreen |
| 11:40 |
jeffdavis |
Stompro: it's not publicly available at the moment. I'll poke one of the developers about that when he's around. |
| 11:45 |
Stompro |
jeffdavis, thanks |
| 12:04 |
|
sandbergja joined #evergreen |
| 12:37 |
mmorgan |
Has anyone seen a problem where the notification fields in some holds are blank when they should not be? |
| 12:37 |
mmorgan |
These are title level holds, and the majority are staff placed. |
| 12:40 |
|
jihpringle joined #evergreen |
| 12:41 |
|
brahmina joined #evergreen |
| 12:43 |
jeff |
a long time ago there was at least one bug where the notification prefs of the staff user were used, not the patron user. assuming the hold requests are not several years old, it's probably not that specific bug, but perhaps similar? |
| 12:43 |
jeff |
or, are you certain that the holds don't pre-date a preference change by the patron? |
| 12:44 |
rjackson_isl |
any chance the patron accounts were updated AFTER the holds were generated? |
| 12:44 |
jeff |
are you able to reproduce at all? |
| 12:44 |
rjackson_isl |
I have found that to be true on several tickets reporting holds missing the correct email/phone notification info |
| 12:44 |
jeff |
since we ignore the hold-level prefs we might be seeing the same thing here and just haven't noticed it. |
| 12:44 |
mmorgan |
We certainly have the situation where the patron account is update post hold, and those issues are easy to explain. |
| 12:45 |
mmorgan |
I have not been able to reproduce it. |
| 12:47 |
rjackson_isl |
any possibility of tracing an example hold thru the logs and see if it started out bad or changed later? |
| 12:48 |
mmorgan |
It's not possible to know what's clicked on the hold screen at the time the hold is placed, but I have seen holds without phone_notify when there was an existing phone number in the patron record. |
| 12:48 |
jeff |
can you reproduce with the same patron and same staff member as one of the suspect holds? |
| 12:48 |
mmorgan |
We hide the hold notify checkbox and check it by default. |
| 12:50 |
mmorgan |
I've been able to explain away some instances by going through the logs. But there are enough reports that I can't explain to make me think something's going on. I was wondering if others saw something similar. |
| 12:51 |
mmorgan |
jeff: I have not actually tried with the same staff user and the same patron, that might be a thing to try. |
| 12:52 |
jeff |
i'd try to reproduce with the same patron, then ask the staff member in question to try if reproducing it as myself was unsuccessful. |
| 12:52 |
jeff |
could be worth the effort. |
| 12:52 |
mmorgan |
It's happened with multiple holds/patrons with one staff member, but we couldn't pin down anything different in the workflow. |
| 12:53 |
jeff |
over time, users have been created with empty / missing / null / different hold notification settings, and you might be running into a bug that relies on the patron or staff having been created / last updated under one of the former environments/situations. |
| 12:53 |
|
book` joined #evergreen |
| 12:54 |
jeff |
if there's a bug, that's one of the first things i'd suspect. |
| 12:55 |
jeff |
the other would be a failure of the javascript to poll prefs in the hold placement interface, possibly due to token eviction, though i suspect that would prevent the hold from being placed in the first place. |
| 12:55 |
jeff |
(eviction was less common for us than 'another tab triggering a tpac logout in the staff client', and that was fixed a while ago) |
| 12:57 |
* mmorgan |
will keep sleuthing. Thanks for the suggestions! |
| 12:57 |
mmorgan |
jeff++ |
| 12:57 |
mmorgan |
rjackson_isl++ |
| 13:03 |
rjackson_isl |
mmorgan another somewhat related issue we ran into was 7 digit phone numbers resulting in no calls - but this doesn't explain blank fields! |
| 13:06 |
mmorgan |
Interesting! We use TNS by Human (when necessary), so hopefully they're able to deal with 7 digit numbers :) |
| 13:08 |
rjackson_isl |
lucky you! ours requires the area code to function :( |
| 13:08 |
rjackson_isl |
makes migrations more exciting... |
| 13:13 |
bshum |
mmorgan: are you using KPAC in any way? Cause there was a time when KPAC holds didn't add those notification settings |
| 13:14 |
* bshum |
re-read the backlog and isn't sure his idea applies, meh |
| 13:15 |
mmorgan |
bshum: No, we're not using KPAC. Mostly these are staff placed holds. |
| 13:15 |
bshum |
And they're title holds you said, not copy ones |
| 13:15 |
jeff |
it's also possible that the problem is related to how the UI bits have been hidden in your local system. |
| 13:15 |
bshum |
There is that XUL place hold interface |
| 13:16 |
bshum |
That was broken for a time too I think |
| 13:16 |
bshum |
I think people still have access to it for recall/force holds, but those are more copy type holds, not title based, hmm |
| 13:19 |
mmorgan |
I do know about that "Request Item" function, and that it does not set notifications. AFAIK, these holds were not placed that way. |
| 13:29 |
rjackson_isl |
There is still an open bug where SMS carrier can be left blank and have Hold Notification Format set to SMS with a Defalt SMS/Text Number entered - bug 1098685 |
| 13:29 |
pinesol_green |
Launchpad bug 1098685 in Evergreen "User can select SMS notify without providing a valid address" [Undecided,Confirmed] https://launchpad.net/bugs/1098685 |
| 14:16 |
bshum |
well, for giggles, Debian Stretch (9.0) testing has not yielded a working OpenSRF. It blows up with the libraries and can't find the stuff to start up opensrf.math or dbmath processes. So I guess that's changed somewhere, somehow. |
| 14:20 |
bshum |
On the plus side, the ejabberd 16.x stuff we wrote for Xenial seemed to work, along with the basic packages from xenial too for defining what to install. |
| 14:47 |
Stompro |
rjackson_isl, I hate that bug. |
| 15:16 |
|
bmills joined #evergreen |
| 16:08 |
kmlussier |
@dessert [someone] |
| 16:08 |
jeffdavis |
Stompro: did you get a response about the wordpress carousel? |
| 16:08 |
* pinesol_green |
grabs some Boston Cream doughnuts for ldw |
| 16:11 |
Stompro |
jeffdavis, yes, thank you again. |
| 16:41 |
|
_adb1 joined #evergreen |
| 16:42 |
|
dkyle1 joined #evergreen |
| 16:43 |
|
_bott_1 joined #evergreen |
| 16:53 |
|
Jillianne joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:05 |
Bmagic |
I just received a feature request where the staff would like to be able to place a copy level hold on a copy from the item status screen. Any thoughts on that idea? |
| 17:29 |
Stompro |
Bmagic, I think you can already do that, right click -> request item. |
| 17:46 |
Bmagic |
ha! |
| 17:47 |
Bmagic |
Shows you how little I use the staff client |
| 17:54 |
abneiman |
Bmagic: be aware that holds placed in this manner will skip any automatic notifications like email or SMS |
| 17:54 |
Bmagic |
abneiman: ah, good to know |
| 18:02 |
|
_adb1 left #evergreen |
| 18:46 |
pinesol_green |
[evergreen|Linda Jansova] Docs: end-user documentation for Obalkyknih.cz added content - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0eadb29> |
| 18:46 |
pinesol_green |
[evergreen|Jane Sandberg] Merge branch 'master' of git.evergreen-ils.org:Evergreen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b16321> |
| 19:55 |
|
brahmina joined #evergreen |
| 21:25 |
|
Jillianne joined #evergreen |
