| Time |
Nick |
Message |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 08:17 |
|
collum joined #evergreen |
| 08:36 |
|
Jillianne joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:42 |
|
collum_ joined #evergreen |
| 08:53 |
|
bos20k joined #evergreen |
| 09:06 |
|
maryj joined #evergreen |
| 09:09 |
|
kmlussier joined #evergreen |
| 09:10 |
|
jvwoolf joined #evergreen |
| 09:15 |
|
Dyrcona joined #evergreen |
| 09:23 |
|
terran joined #evergreen |
| 09:36 |
|
RBecker joined #evergreen |
| 09:41 |
|
mnsri_away joined #evergreen |
| 09:42 |
|
sandbergja joined #evergreen |
| 09:56 |
|
jvwoolf1 joined #evergreen |
| 10:17 |
pinesol_green |
[evergreen|Christine Morgan] LP1670448 - Move View/Place Orders to Record Summary - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ae0e16a> |
| 10:17 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1670448: Rearrange space for bib record action buttons - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb05739> |
| 11:37 |
|
_adb joined #evergreen |
| 11:59 |
|
Christineb joined #evergreen |
| 12:12 |
|
yboston joined #evergreen |
| 12:24 |
kmlussier |
If anyone from ESI is around, it looks like somebody changed the admin password for demo.evergreencatalog.com. |
| 12:26 |
kmlussier |
phasefx gmcharlt abneiman ^^ |
| 12:29 |
kmlussier |
Ugh, actually, it looks like it also might need autogen run too. errors about the org tree when I try registering a workstation. |
| 12:32 |
Dyrcona |
Ah, the joy of public demo servers. |
| 12:32 |
* Dyrcona |
is having fun with pgbench. |
| 12:37 |
bos20k |
Hello Everyone. I am having trouble figuring something out. In the XUL Staff Client on the patron edit and patron registration screens, I am trying to hide/remove the 'Email checkout receipts by default?' setting in the User Settings section. We don't want people to be able to set that. I thought that commenting/removing things in templates/staff/circ/patron/t_edit.tt2 would do it but that doesn't seem to be working. I'm |
| 12:37 |
bos20k |
not seeing anywhere else that this could be done. Any thoughts on how to acheive this? |
| 12:37 |
bshum |
bos20k: Well the path you describe sounds more like the files for the web client |
| 12:38 |
bshum |
Than the XUL client |
| 12:38 |
bshum |
For the old XUL patron editor, you're looking for something dojo |
| 12:38 |
bshum |
So that'd be in like... Open-ILS/js/ui/default/staff/something |
| 12:38 |
bshum |
I think |
| 12:38 |
bos20k |
That makes sense why my changes weren't showing up. |
| 12:38 |
bshum |
But as a setting |
| 12:39 |
bshum |
I think there's some javascript that just goes through all the user settings to retrieve them for view / use |
| 12:39 |
mmorgan |
bos20k: bshum: The email checkout receipts by default is an opt-in action trigger, actually. |
| 12:39 |
bos20k |
Oh, that's probably why my greps didn't turn anything up there. |
| 12:39 |
bshum |
Open-ILS/web/js/ui/default/ |
| 12:39 |
bshum |
actor/user |
| 12:40 |
bshum |
register.js |
| 12:41 |
bshum |
I'm trying to remember where the other bits live |
| 12:41 |
* mmorgan |
believes that disabling the action trigger should make it disappear from the patron edit screen. |
| 12:42 |
bos20k |
mmorgan: Would that also disable the ability for the patron to request an e-mail receipt at checkout when they do selfcheck though? |
| 12:43 |
mmorgan |
But now I'm seeing that our trigger is disabled, but it's still displaying in our patron edit screen :-( |
| 12:43 |
* bshum |
coughs, "bug!" *cough, cough* |
| 12:43 |
mmorgan |
bos20k: Is that the native evergreen selfcheck? |
| 12:44 |
bshum |
(I mean, probably, maybe not fully designed) |
| 12:44 |
bos20k |
mmorgan: I believe so. I haven't had much to do with selfcheck yet myself. |
| 12:44 |
csharp |
possibly relevant: |
| 12:44 |
csharp |
https://bugs.launchpad.net/evergreen/+bug/1643694 |
| 12:44 |
pinesol_green |
Launchpad bug 1643694 in Evergreen "Patron Self Registration - Email checkout receipts checkbox doesn't carry through" [Undecided,Confirmed] |
| 12:44 |
csharp |
oh - nevermind - that's self-reg |
| 12:44 |
|
jvwoolf joined #evergreen |
| 12:45 |
* csharp |
didn't mean to muddy the water |
| 12:45 |
* csharp |
slouches away |
| 12:46 |
bshum |
bos20k: I think the rest of the stuff is in Open-ILS/src/templates/actor/user/register.tt2 |
| 12:46 |
mmorgan |
bos20k: If it's the evergreen self check, the emailed checkout receipt is a different trigger, so printing from the selfcheck should be unaffected. |
| 12:46 |
bshum |
and register_table.tt2 |
| 12:47 |
bshum |
The release notes didn't say anything about the selfcheck getting email receipt option. It might not be supported yet. |
| 12:47 |
bshum |
> |
| 12:47 |
|
sandbergja joined #evergreen |
| 12:47 |
bshum |
Oh wait it does |
| 12:47 |
* bshum |
is blind |
| 12:51 |
* mmorgan |
agrees with bshum there's a bug in that the opt-in trigger still displays when it's disabled. |
| 12:51 |
mmorgan |
all of our other opt-in disabled triggers don't display in the editor. |
| 12:52 |
bshum |
bos20k: For the selfcheck, this commit might be helpful in pointing out where to go: http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=92f1bdb26d0027b52b3b3db84ff3d52104d6b1fe |
| 12:52 |
pinesol_green |
bshum: [evergreen|Mike Rylander] LP#1356477: update selfcheck interface - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=92f1bdb> |
| 12:53 |
bshum |
I think that if one were to edit the Open-ILS/src/templates/circ/selfcheck/summary.tt2 ; you could remove the option to email receipt without touching the javascript bits |
| 12:53 |
bshum |
But of course that's local custom stuff |
| 12:54 |
bshum |
Based on what I saw there, I think the checking is based on if the user has the setting enabled and an email address |
| 12:54 |
bshum |
And not based on whether the trigger is enabled, etc. |
| 12:54 |
bos20k |
bshum: We actually want to allow the option to have a receipt e-mailed on the selfcheck, but we don't want people setting it so they always get e-mail receipts for checkouts. |
| 12:55 |
* bshum |
hasn't used the selfcheck lately to know if it works that way or not |
| 12:56 |
bshum |
I don't know if it supports one-by-one cases |
| 12:56 |
bshum |
Or if it just assumes that once you set the choice, that's how you'd like it |
| 12:57 |
* bshum |
wanders off to prep for his next meeting |
| 12:57 |
bshum |
Good luck bos20k |
| 12:57 |
bos20k |
Thanks! |
| 12:58 |
|
jihpringle joined #evergreen |
| 13:03 |
mmorgan |
bos20k: Here's what made the "Email checkout receipts by default?" disappear from the patron editor on a test system: |
| 13:04 |
mmorgan |
In the "Email Checkout Receipt" Action trigger... |
| 13:04 |
mmorgan |
Blank the Opt-In Setting Type field. |
| 13:04 |
mmorgan |
and save the trigger. |
| 13:05 |
csharp |
mmorgan++ |
| 13:05 |
bos20k |
That makes sense based on the code I'm looking at in register.js |
| 13:05 |
bos20k |
mmorgan++ |
| 13:05 |
mmorgan |
For reference, the default value in that field is circ.send_email_checkout_receipts |
| 13:05 |
kmlussier |
@praise mmorgan |
| 13:05 |
* pinesol_green |
Shall I compare mmorgan to a summer's day? mmorgan is more lovely and more temperate. |
| 13:05 |
csharp |
awww |
| 13:05 |
bos20k |
lol |
| 13:06 |
* mmorgan |
has rarely been described as lovely and more temperate than a summer's day ;-) |
| 13:06 |
csharp |
@weather 30345 |
| 13:06 |
pinesol_green |
csharp: Atlanta, GA :: Clear :: 89F/32C | Heat Index: 94F/34C | Tuesday: Cloudy skies. A stray afternoon thunderstorm is possible. High around 90F. Winds SW at 5 to 10 mph. Tuesday Night: A stray shower or thunderstorm is possible early. Partly cloudy skies. Low 72F. Winds light and variable. |
| 13:07 |
* csharp |
thinks Shakespeare musta lived in a different latitude |
| 13:07 |
mmorgan |
@weather 01923 |
| 13:07 |
pinesol_green |
mmorgan: Danvers, MA :: Overcast :: 64F/18C | Tuesday: Sun and clouds mixed. High 67F. Winds NE at 5 to 10 mph. Tuesday Night: Partly cloudy skies. Low near 55F. Winds light and variable. | Updated: 14m ago |
| 13:08 |
csharp |
mmorgan: that's definitely lovely and temperate :-) |
| 13:08 |
kmlussier |
Lovely and temperate would be something in between the two forecasts, IMO. |
| 13:08 |
mmorgan |
Summer has taken a vacation in these parts. |
| 13:09 |
* mmorgan |
visits launchpad to open a bug. Re: the trigger, not the weather. |
| 13:11 |
abneiman |
kmlussier: thanks for the heads up, I'll look into it |
| 13:14 |
kmlussier |
abneiman: Thanks! |
| 13:27 |
bos20k |
Hmmm, it didn't work. I set the opt_in_setting to NULL in the database for the Email Checkout Receipt action trigger and also disabled it. Still shows in the patron edit/reg screens. |
| 13:31 |
Dyrcona |
bos20k: You quit the client and sign in again after? |
| 13:31 |
bos20k |
Dyrcona: yup. restarted EG on the test system too. |
| 13:31 |
bos20k |
Cleared the cache as well. |
| 13:33 |
mmorgan |
bos20k: Hmm. Close out and login again? I made the change in the client and no logout or cache clearing was necessary. |
| 13:33 |
Dyrcona |
Well, the trigger would have nothing to do with the client view. I'm not sure if the opt-in setting does either. I'd have to check. |
| 13:35 |
* mmorgan |
is working on 2.12 FWIW. |
| 13:36 |
bos20k |
2.12.3 here |
| 13:36 |
mmorgan |
2.12.2 here, to be precise. |
| 13:40 |
kmlussier |
I just followed mmorgan's steps on the 2.12.3 MassLNC demo server and was able to remove the setting from the patron registration form. |
| 13:41 |
bos20k |
Are you editing the action trigger in the database directly or somewhere else? When I was looking at the action trigger in the staff client I didn't see where to remove the Opt-In Setting Type |
| 13:42 |
bos20k |
So I did what I thought was correct in the database directly. |
| 13:42 |
* mmorgan |
just tested on a couple of other opt in triggers. It looks like Enabled needs to be unchecked and the opt-in setting type needs to be NULL. |
| 13:43 |
mmorgan |
I edited the action trigger under Admin - Local - Notifications/Action triggers. |
| 13:44 |
mmorgan |
the Opt-In Setting Type dropdown is 3 fields above the template. I selected and deleted the text in the Opt-In Setting Type field and saved. |
| 13:45 |
mmorgan |
When I next loaded a clean patron registration form, the preference did not display. |
| 13:46 |
kmlussier |
I was editing in the staff client too. |
| 13:47 |
bos20k |
I had forgotten about the need to double click on the action trigger instead of the link... I hate that. |
| 13:48 |
mmorgan |
Oh, yes, been there, done that, too :) |
| 13:48 |
kmlussier |
I always pick the wrong action. Same thing happens in the acq admin interfaces. |
| 13:51 |
bos20k |
Ugh, still there even after doing it the staff client way. |
| 14:08 |
* mmorgan |
needs to run out, but here's a gui view of the email checkout receipt action trigger that is not displaying in the client - minus the template field. https://www.screencast.com/t/Q0gZ18wwQ7 |
| 14:10 |
bos20k |
I was able to get rid of it by editing register.js Not ideal but it will work for us for now. |
| 14:11 |
bos20k |
Thanks everyone for all of your help. |
| 14:12 |
Dyrcona |
bos20k: Could be the settings are cached in memcached. |
| 14:13 |
bos20k |
Darn memcached. I should try that to be sure I'm not crazy... |
| 14:17 |
bos20k |
Nope, restarted memcached, EG, apache and staff client. Still there. I'll go with the register.js solution. Modifying register.js also means we don't have to worry about remembering how to turn it back on. Just remove our change and it is back to normal. |
| 15:07 |
|
barbara joined #evergreen |
| 15:20 |
mmorgan |
I'm looking for the best options for hold targeting regarding library closures. Any advice? |
| 15:20 |
mmorgan |
We want a library's own items to fill their own holds, but when a library is closed for a day, other libraries get targeted. |
| 15:22 |
mmorgan |
We currently have the option to target when closed when the pickup library matches the copy circ lib, but holds placed the evening before the day they are closed get retargeted the next evening. |
| 15:22 |
mmorgan |
I'm wondering if stalling would help with this, or if there are options with the new hold targeter that would help. |
| 15:29 |
miker |
mmorgan: stalling might help, but I think what we'll really want (and would be a general improvement) is to have the hold targetter look into the future, in a way related to the retargetting interval, and adjust its targetting based on the projected closedness of libraries |
| 15:30 |
miker |
so a targetting run today could, say, skip a library that will be closed tomorrow if the retargetting interval means the pull list likely won't be used |
| 15:32 |
miker |
right now that's approximated by running the targetter after midnight and having "today" be "tomorrow" in human terms, but it's only accurate for 1-day retargetting intervals. which, of course, is the most common, but not the only value in wide use |
| 15:32 |
* miker |
has closings and holds on the brain for other reasons ATM |
| 15:36 |
mmorgan |
A one day targeting interval could work fine if the targeter was smart enough to know that the pickup library was closed for two days, and not to retarget until the library had a chance to do the pull list on the next day they are open. |
| 15:38 |
JBoyer |
Should we look at incorporating TensorFlow into holds targeting? |
| 15:38 |
JBoyer |
;) |
| 15:40 |
mmorgan |
:) |
| 15:41 |
berick |
mmorgan: nothing in the new targeter w/ that level of sophistication. so, what miker said. |
| 15:43 |
mmorgan |
Ok, thanks for confirming |
| 15:43 |
berick |
there is a new runtime option --next-check-interval that lets you specify when you expect the targeter to run again, thus which date to check for closed days, but that affects all holds. |
| 15:48 |
mmorgan |
Ok, so if there was a time period where all libraries were closed (which never really happens in our case), that option might be useful? |
| 15:48 |
mmorgan |
Just let the holds sit tight while everyone is closed. |
| 15:51 |
|
maryj_ joined #evergreen |
| 15:51 |
berick |
maybe, but probably better to just disable the targeter for a few days in that case. |
| 15:53 |
berick |
of course, new and manually retargeted holds would continue like usual. changing that would require more smarts. |
| 15:53 |
mmorgan |
So in what sort of situation would the --next-check-interval be used? |
| 15:54 |
mmorgan |
New and manually retargeted holds don't seem to be big factors in this problem. It's just the automatic retargetting. |
| 15:56 |
berick |
mmorgan: one sec, have to remind myself what it's doing :) |
| 15:56 |
mmorgan |
:) |
| 16:05 |
abneiman |
kmlussier et al., re demo.evergreencatalog.com, autogen has been run and admin's normal PW restored. I was able to successfully register a workstation but I don't have time today to do really heavy prodding, so ping me if anything else is broken. |
| 16:05 |
berick |
mmorgan: traditionally the targeter looks at the retarget interval (e.g. 24 hours), adds that amount to "now", then checks to see if a library is closed that day (i.e. tomorrow) to see if that lib's copies should be used for targeting. |
| 16:06 |
berick |
mmorgan: but if you have a retarget interval of 40 hours (not a multiple of 1 day) then the match doesn't quite work. you want to push that closed branch check out to 2 full days from now. |
| 16:06 |
berick |
s/match/math/ |
| 16:07 |
mmorgan |
Ok, so if you're not using the standard 24 hour retarget interval, it's useful. |
| 16:07 |
berick |
in some cases, depending on how often the targeter is run and when you run it. |
| 16:07 |
berick |
it could still be smarter, too |
| 16:09 |
berick |
e.g. if you target at 5am you might want to check today's closed dates, but if you target at 5pm, you'd want to check tomorrow's. |
| 16:11 |
miker |
and some sites run it constantly (like, every 15 mins) with a 24hr retarget interval to make the pull lists as up to date as humanly possible and refresh potentials lists a quickly as it can |
| 16:12 |
berick |
yeah |
| 16:16 |
mmorgan |
Ok, so the targeter figures out which libraries are closed and won't use those copies (assuming no ou settings to the contrary are set). Does it then use proximity to decide which hold targets which copy next? |
| 16:17 |
miker |
mmorgan: yes. adjusted proximity. note: it tries /not/ to target the same copy twice in a row |
| 16:17 |
miker |
nor target copies that are already targetted by any other hold |
| 16:18 |
miker |
and, remember, targetting a copy just gets it onto the pull list. it does /not/ mean that copy will go to the targetting hold |
| 16:19 |
mmorgan |
Yes - adjusted proximity, and yes, just what shows on the pull list. |
| 16:20 |
miker |
yay holds |
| 16:21 |
mmorgan |
So if my patron places a hold on Friday night, targeting my library's copy, and my library is closed on Saturday and Sunday, is it likely, or possible that when my patron's hold is retargeted on Sunday evening, that it will choose my library's copy again? |
| 16:22 |
mmorgan |
And yeah, yay holds! |
| 16:23 |
mmorgan |
We're targeting when closed if the copy and pickup lib match. |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:37 |
kmlussier |
abneiman++ |
| 16:51 |
|
Jillianne joined #evergreen |
| 16:57 |
|
jvwoolf joined #evergreen |
| 17:00 |
|
mmorgan left #evergreen |
| 17:32 |
|
jwoodard joined #evergreen |
| 19:52 |
|
_adb joined #evergreen |
| 20:02 |
|
deep-book-gk_ joined #evergreen |
| 20:04 |
|
deep-book-gk_ left #evergreen |
| 20:15 |
|
_adb joined #evergreen |
| 20:51 |
|
dbwells_ joined #evergreen |
| 20:54 |
|
_adb joined #evergreen |
| 22:19 |
|
genpaku_ joined #evergreen |
