| Time |
Nick |
Message |
| 01:03 |
|
dbs joined #evergreen |
| 07:28 |
|
collum joined #evergreen |
| 07:49 |
|
rjackson_isl joined #evergreen |
| 08:12 |
|
akilsdonk joined #evergreen |
| 08:27 |
|
ericar joined #evergreen |
| 08:27 |
|
mrpeters joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:36 |
|
Shae joined #evergreen |
| 08:40 |
|
Dyrcona joined #evergreen |
| 08:44 |
|
sarabee joined #evergreen |
| 08:52 |
|
eg_dw joined #evergreen |
| 09:13 |
|
maryj joined #evergreen |
| 09:14 |
|
Shae joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 09:31 |
|
krvmga joined #evergreen |
| 09:58 |
Bmagic |
Goooooooood Morning (vietnam) |
| 10:14 |
kmlussier |
berick: You might be right. Let me check. |
| 10:16 |
kmlussier |
berick: Yup, you are right. I must have been confusing it with the staff view of the catalog. I'll add a comment to the bug. |
| 10:16 |
berick |
kmlussier: ok, great, thanks for confirming |
| 11:22 |
|
mllewellyn joined #evergreen |
| 11:29 |
|
gsams joined #evergreen |
| 12:01 |
Bmagic |
@coffee [someone] |
| 12:01 |
* pinesol_green |
brews and pours a cup of El Salvador Pacamara Los Planes, and sends it sliding down the bar to Callender |
| 12:03 |
berick |
@coffee my-belly |
| 12:04 |
* pinesol_green |
brews and pours a cup of Colombia Pitalito Estate, and sends it sliding down the bar to my-belly |
| 12:04 |
Bmagic |
haha, glad someone is alive! I figured we need some coffee up in thie mug! |
| 12:05 |
berick |
hah, yeah, slow start for everyone, it seems |
| 12:42 |
* Dyrcona |
has been working on a monthly report most of the morning. |
| 12:44 |
dbs |
Dyrcona: once it takes you a month to produce, then you're set for the rest of your career |
| 12:46 |
Dyrcona |
heh |
| 12:46 |
Dyrcona |
dbs++ |
| 12:47 |
Dyrcona |
Well, if I spend a lot of time editing it to remove unnecessary verbiage, etc. |
| 12:47 |
Dyrcona |
Not "if", I do spend that time. |
| 12:47 |
Dyrcona |
Sometimes, the brain is faster than the fingers. |
| 13:00 |
jeff |
anyone here using opt-in settings for Action/Trigger notifications in production? |
| 13:01 |
jeff |
I don't know how common user opt-in setting use is for those doing SMS or voice calls. |
| 13:17 |
tsbere |
jeff: MVLC uses them for a number of settings. |
| 13:18 |
tsbere |
Certain email notifications just being one of them, though we don't for voice calls at all (we don't automate those currently) |
| 13:21 |
|
eg_dw joined #evergreen |
| 13:25 |
|
afterl joined #evergreen |
| 13:47 |
jeff |
tsbere++ thanks! |
| 13:54 |
|
ericar_ joined #evergreen |
| 14:09 |
Bmagic |
Anyone have thoughts about loading an OPAC cookie with ALL of the bookbag lists for a logged-in user? Would that be a bad idea/dangerous/slow? We want the OPAC to inform the users which bibs are in their lists while viewing search results. |
| 14:10 |
Bmagic |
The other thought is to have the server cross reference all of the lists before sending the search results back, and flagging the bibs for the templates to display differently. I figured that would have a harder impact than letting the browser do it with javascript. |
| 14:10 |
Dyrcona |
Bmagic: One of the goals of the template toolkit OPAC is to keep JavaScript out of it. |
| 14:11 |
tsbere |
Bmagic: I can think of a couple of options for that kind of thing, memcache could help as well. |
| 14:11 |
Dyrcona |
Yep, I was thinking of memcached, too. |
| 14:11 |
jeff |
Bmagic: starting with your first question -- what would the cookie value look like? |
| 14:11 |
Bmagic |
interesting |
| 14:11 |
Bmagic |
it would have to be an array of some kind |
| 14:12 |
Dyrcona |
I've given it a little thought, but not a whole lot. |
| 14:12 |
Bmagic |
bbagid => [bibid1,bibid2....] |
| 14:12 |
jeff |
and addressing the general "keep javascript out of the OPAC" idea -- I suspect that we may want to re-evaluate that soon. It does strike me that the pendulum swung WAY far away from the "must have javascript enabled JSPAC". :-) |
| 14:13 |
jeff |
Bmagic: i think you'd end up with size issues, especially with list-heavy patrons. you would reach an upper limit where you could not handle the data, and i'm not sure how you'd best degrade in a way that didn't look unreliable to the user. |
| 14:13 |
Dyrcona |
jeff: While doing some Angular tutorials recently, I thought it might be "fun" to implement the OPAC with Angular. |
| 14:14 |
jeff |
Bmagic: also, if the server is going through the trouble of generating the data for that cookie, it could just as easily stuff it somewhere (like memcache) other than the browser's cookie store. |
| 14:14 |
Dyrcona |
Yep, I think that is best handled by the server. |
| 14:14 |
jeff |
there is logic currently (iirc) to handle "you've checked this item out" in search result pages -- look there for some ideas? |
| 14:15 |
Bmagic |
If we don't deliver the data to the client, then the server needs to do all of the work. The idea was to keep the CPU load low and response times low, so cookies came to mind. |
| 14:15 |
Dyrcona |
Bmagic: Just cache the book bag data along with the patron's other session data. |
| 14:17 |
Dyrcona |
If you run into a patron with so much in their lists that they cause a problem for the server, they very likely would have caused a problem with cookies, too. |
| 14:17 |
tsbere |
Bmagic: I would grab a hash of record id => [bookbag ids] - Then you can easily flag the records without having to walk over the bookbag arrays. |
| 14:18 |
Bmagic |
tsbere: that's an idea |
| 14:19 |
Bmagic |
That wouldn't point out which list but rather "item is on one of your lists" |
| 14:19 |
tsbere |
Bmagic: Er, the [bookbag ids] bit would let you look up which list(s). :P |
| 14:19 |
Dyrcona |
Bmagic: You could just as easily stash the book bag object. |
| 14:20 |
Dyrcona |
And, Perl will use references, so you won't be using tons more RAM, either. |
| 14:27 |
Bmagic |
tsbere++ jeff++ Dyrcona++ |
| 14:34 |
jeff |
Dyrcona: regarding your earlier ``might be "fun" to implement the OPAC with Angular,'' I'm happy to hear that there's non-zero interest. :-) |
| 14:36 |
* berick |
thinks we might be implementing a mini-opac within the angular client before it's all over |
| 14:36 |
Dyrcona |
And, oddly enough, my thoughts about Angular in the OPAC had to do with book bags. |
| 14:36 |
Bmagic |
ha |
| 14:36 |
Dyrcona |
My first thoughts any way. |
| 14:36 |
Dyrcona |
And placing holds. |
| 14:37 |
jeff |
heh |
| 14:38 |
jeff |
so, i've received a handful of use cases around support for per-hold notification methods and notification destinations (for phone and sms -- email is single-destination). i'm interested in more, if anyone has more. i'll still solicit same from the list at some point. |
| 14:42 |
|
afterl joined #evergreen |
| 14:46 |
Dyrcona |
jeff: I don't think that I have any to add beyond what tsbere mentioned to you earlier. |
| 14:49 |
jeff |
tsbere++ Dyrcona++ thanks! |
| 14:52 |
eeevil |
Bmagic: you might want to look at the "you've already checked this out" code. it does the same, but for circs for a user instead of container listings |
| 14:53 |
Bmagic |
eeevil: yeah, that is a good idea |
| 14:53 |
eeevil |
(not sure if that's been mentioned ... didn't read entire wall of text ;) ) |
| 14:53 |
jeff |
mentioned, but worth re-mentioning. :-) |
| 14:56 |
pinesol_green |
[evergreen|Ben Shum] LP#1463145 - Debian Jessie needs libexcel-writer-xlsx-perl - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=71addb1> |
| 14:58 |
|
buzzy joined #evergreen |
| 14:58 |
bshum |
StomproJ++ Dyrcona++ |
| 14:58 |
Dyrcona |
StomproJ++ bshum++ |
| 14:59 |
Dyrcona |
I was just going through signed off, but not fix committed bugs on Friday and thought I'd pick up where I left off. |
| 14:59 |
Dyrcona |
I'm not sure about some of the others at the moment. |
| 15:05 |
|
Newziky joined #evergreen |
| 15:07 |
Dyrcona |
So, I'm looking at committing the fix for lp 902255. I think that should be targeted all the way back to rel_2_7, but solicit opinions. |
| 15:07 |
pinesol_green |
Launchpad bug 902255 in Evergreen "possible to double-scan an item during check-in and have it captured by two holds" (affected: 10, heat: 54) [Low,Confirmed] https://launchpad.net/bugs/902255 |
| 15:08 |
* mmorgan |
would agree it should be backported. |
| 15:09 |
eeevil |
Dyrcona: it picks clean for me, fwiw |
| 15:09 |
Dyrcona |
eeevil mmorgan: Good 'nuf for me. I'll add the targets to the bug and backport. |
| 15:17 |
pinesol_green |
[evergreen|Mike Rylander] LP#902255: Protect against hold double-capture - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=32e415a> |
| 15:17 |
pinesol_green |
[evergreen|Mike Rylander] LP#902255: Correct "ILS Event at check in" logic - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cc2c1ec> |
| 15:17 |
pinesol_green |
[evergreen|Mike Rylander] LP#902255: Use simple alert box - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=37b2d38> |
| 15:19 |
Dyrcona |
crap. missed the upgrade scrip before pushing. |
| 15:20 |
Dyrcona |
grabbin 0920 |
| 15:25 |
Dyrcona |
rush, rush, rush.... |
| 15:27 |
pinesol_green |
[evergreen|Jason Stephenson] LP 902255: Stamping upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2ca895b> |
| 15:47 |
|
ericar joined #evergreen |
| 16:15 |
Dyrcona |
eeevil: So, after looking more closely, I notice that the fix for LP 902255 that I already pushed fails to commit. |
| 16:15 |
pinesol_green |
Launchpad bug 902255 in Evergreen "possible to double-scan an item during check-in and have it captured by two holds" (affected: 10, heat: 54) [Low,Fix committed] https://launchpad.net/bugs/902255 |
| 16:16 |
Dyrcona |
Specifically, I get this: psql:/home/opensrf/Evergreen/Open-ILS/src/sql/Pg/upgrade/0920.schema.disallow-double-capture.sql:10: ERROR: CREATE INDEX CONCURRENTLY cannot run inside a transaction block |
| 16:16 |
Dyrcona |
So, we've tried two options and both seem to work: |
| 16:17 |
Dyrcona |
1. remove the begin/commit from the script (which bshum says was also done in 0782). |
| 16:17 |
Dyrcona |
2. remove the concurrently keyword. |
| 16:17 |
Dyrcona |
eeevil: Do you have a preference for one or two? |
| 16:19 |
bshum |
If we do put it outside the transaction, I think we'll need a note for release cutters to make sure we check the upgrade script carefully when we do the maintenance releases. |
| 16:19 |
Dyrcona |
I'm in favor of #2, myself, unless there's a compelling reason to keep concurrently. |
| 16:22 |
* eeevil |
looks up |
| 16:23 |
eeevil |
Dyrcona: I'd prefer #1, as it doesn't lock the table during the index build, which means it can be applied without the possibility of erroring to staff (or patrons, for renew) due to transaction timeout from the UI's perspective |
| 16:24 |
eeevil |
Dyrcona: that said, it's not a particularly strong preference |
| 16:24 |
eeevil |
so, if you're more comfortable with #2, I won't complain |
| 16:24 |
jeff |
hah. if the user editor shows a user opt-in setting, it forces it to a checkbox even if the underlying setting type is a string. |
| 16:25 |
Dyrcona |
OK. I'll do number 2. It will save us pain when doing releases. |
| 16:25 |
jeff |
i haven't actually looked at what A/T does when you have a string user setting for opt-in -- i was intentionally abusing the mechanism, so i'm not too surprised that i got this result. |
| 16:26 |
mmorgan |
jeff: Are you exploring the use of opt-in action triggers to replace the in-hold notification settings? |
| 16:27 |
jeff |
mmorgan: i was experimenting with a fast way to get an arbitrary user setting to show up in both the staff client and patron account interfaces. |
| 16:28 |
* mmorgan |
has only played around with opt in triggers enough to see a user setting appear in the client. Never saw it in the patron account interface. |
| 16:32 |
jeff |
hrm. |
| 16:32 |
jeff |
i defined two new user settings. one is a string, one is a bool. created a dummy A/T event def referencing each. set both as opac visible. |
| 16:33 |
jeff |
in the staff client, both appear by name, but are both checkboxes (see previous lack of surprise, since in theory only the use of boolean config types is supported here) |
| 16:34 |
jeff |
in tpac, only one of the config types appears, and it's the one that's a string -- and it has a checkbox. |
| 16:34 |
* jeff |
looks |
| 16:35 |
pinesol_green |
[evergreen|Jason Stephenson] LP 902255: Fix upgrade script. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=640e344> |
| 16:38 |
|
sarabee joined #evergreen |
| 16:38 |
jeff |
yup, open-ils.actor.event_def.opt_in.settings only returns one of them. |
| 16:39 |
jeff |
because one of the event defs wasn't enabled. |
| 16:42 |
mmorgan |
jeff++ # thinking out loud. |
| 16:49 |
Dyrcona |
Fun typo: newtworking for networking. |
| 16:50 |
mmorgan |
:) |
| 16:52 |
|
afterl left #evergreen |
| 16:53 |
jeff |
Since the list of user setting types to display in the user editor is hardcoded, and the only ones that are dynamic are opt-in settings, it's also no surprise that the default widget is a checkbox. |
| 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:11 |
* mmorgan |
opts out. Good Evening, all! |
| 17:12 |
|
mmorgan left #evergreen |
| 17:19 |
|
buzzy joined #evergreen |
| 17:36 |
Bmagic |
Anyone seen opac results with details show parts for items when there are no parts on the bib at all? |
| 17:41 |
Bmagic |
Nevermind, it's our opac customizations, it's not happening on stock |
| 18:13 |
|
akilsdonk_ joined #evergreen |
| 18:15 |
|
Stompro_home joined #evergreen |
| 18:15 |
Stompro_home |
Is unapi.info down for anyone else? |
| 18:47 |
|
wlayton joined #evergreen |
| 19:04 |
|
Sato joined #evergreen |
| 19:47 |
|
dcook joined #evergreen |
| 20:04 |
|
Stompro_home joined #evergreen |
| 20:18 |
|
akilsdonk joined #evergreen |
