| Time |
Nick |
Message |
| 00:50 |
|
eady joined #evergreen |
| 02:15 |
|
eady joined #evergreen |
| 02:50 |
|
eady joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:33 |
|
agoben joined #evergreen |
| 07:58 |
|
_bott_ joined #evergreen |
| 08:25 |
|
bos20k joined #evergreen |
| 08:34 |
|
Dyrcona joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 09:03 |
|
aabbee joined #evergreen |
| 09:08 |
|
yboston joined #evergreen |
| 09:10 |
|
tlittle joined #evergreen |
| 09:54 |
|
sandbergja_ joined #evergreen |
| 10:05 |
|
khaun joined #evergreen |
| 11:06 |
|
yboston joined #evergreen |
| 11:46 |
|
Christineb joined #evergreen |
| 11:59 |
|
yboston joined #evergreen |
| 12:42 |
|
khuckins joined #evergreen |
| 12:48 |
berick |
sandbergja++ # bug 1823041 |
| 12:48 |
pinesol |
Launchpad bug 1823041 in Evergreen "Angular dialogs should limit promise rejections to error conditions" [Undecided,New] https://launchpad.net/bugs/1823041 |
| 12:48 |
* berick |
will do rough cut of that |
| 12:54 |
|
yboston joined #evergreen |
| 12:58 |
sandbergja |
observables++ |
| 12:59 |
|
jihpringle joined #evergreen |
| 13:26 |
|
jamesrf joined #evergreen |
| 13:43 |
|
khuckins joined #evergreen |
| 14:02 |
|
sandbergja_ joined #evergreen |
| 14:07 |
JBoyer |
Does anyone have any quick recomendations on tracking down why a query takes 15x longer to plan than it does to run? |
| 14:07 |
JBoyer |
The last time I saw this it was a static query in the IDL that was easy to experiment with it, this time... it's a bib search query. :( |
| 14:15 |
JBoyer |
jeff++ # music recommendations. |
| 14:16 |
jeff |
hah! |
| 14:16 |
jeff |
glad you enjoyed. |
| 14:28 |
* jeff |
thinks about strategies for copy alerts during xul -> web transition |
| 14:40 |
Dyrcona |
@band add Observables |
| 14:40 |
pinesol |
Dyrcona: Band 'Observables' added to list |
| 14:44 |
rhamby |
shouldn't that be "The Observables" like "The Clash"? |
| 14:44 |
rhamby |
or "The Police" |
| 14:44 |
* rhamby |
may have hit the point where his music is mostly considered "classic" |
| 14:47 |
JBoyer |
ECMA Script and the Observables live tonight only at the Vogue. *snap* *snap* |
| 14:48 |
* mmorgan |
would be interested in jeff's thoughts about copy alert strategies. |
| 14:49 |
Dyrcona |
A number of bands are pronounced as "The [Something]" but "The" is not part of the name. |
| 14:49 |
Dyrcona |
And, yeah, I considered The Observables for a second before hitting enter. |
| 14:50 |
Dyrcona |
JBoyer++ |
| 14:50 |
Dyrcona |
EczemaScript? :) |
| 14:50 |
JBoyer |
Maybe if you type too much in a swamp, heh. |
| 14:50 |
berick |
The "The The" |
| 14:51 |
Dyrcona |
berick++ |
| 14:51 |
JBoyer |
berick++ |
| 14:51 |
Dyrcona |
The The has been a go to search for testing stop words. :) |
| 14:51 |
Dyrcona |
Or would that be a Go-Gos search? :P |
| 14:51 |
jeff |
mmorgan: thinking of using a database trigger to keep asset.copy.alert_message in sync with asset.copy_alert, and having staff only use one alert type for now. |
| 14:51 |
* Dyrcona |
runs and hides from the inevitable beatings. |
| 14:52 |
Dyrcona |
jeff: That sounds like a reasonable approach. |
| 14:54 |
mmorgan |
We were pondering a database trigger also to convert asset.copy.alert_message to asset.copy_alert, but not converting in the other direction. |
| 14:55 |
berick |
jeff: i was thinking something similar, but w/ additional future feature-ness. allow for a single alert type to act as a legacy alert (via a new column on copy alert type) |
| 14:55 |
berick |
that plus your trigger would mean going forward you still have a "main" copy alert |
| 14:55 |
jeff |
mmorgan: In our case, we need to support both directions, so that staff can edit the alert in xul or web. |
| 14:55 |
berick |
that appears in grids, etc. |
| 14:56 |
* Dyrcona |
just isn't going to worry about it and let the hilarity ensue. |
| 14:58 |
mmorgan |
jeff: So your database triggers would be smart enough not to endlessly convert the same alert back and forth ;-)? |
| 14:58 |
mmorgan |
We had that concern. |
| 14:58 |
jeff |
my not-yet-existing trigger approach will have to be that smart, yes! ;-) |
| 14:59 |
mmorgan |
Ideally we would want to support both directions as well. |
| 15:00 |
jeff |
or i'll have to modify the approach and do something like maintain asset.copy.alert_message from the API when a new-style alert of the proper type is set/cleared, and use the db trigger for the other direction only. |
| 15:02 |
mmorgan |
We were also considering converting just the xul to web copy alerts via a trigger, and rerunning the upgrade script just prior to cutting over to the web client for circ. |
| 15:03 |
mmorgan |
We omitted the line in the upgrade script that deleted the asset.copy.alert_message to preserve the xul alerts. |
| 15:03 |
* jeff |
nods |
| 15:03 |
jeff |
similar here. recommended the same approach others. :-) |
| 15:04 |
mmorgan |
:) |
| 15:04 |
Dyrcona |
That's the longest part of that upgrade script. |
| 15:04 |
Dyrcona |
FWIW... |
| 15:04 |
Dyrcona |
I'm leaving it in. |
| 15:05 |
Dyrcona |
That is, I'm deleting the XUL copy alerts, even considered altering the table to drop the column, but I suppose that may come later? |
| 15:06 |
jeff |
Dyrcona: you know your environment better than I. That wasn't an option for our environment. |
| 15:06 |
Dyrcona |
Have to modify the IDL, too. |
| 15:06 |
Dyrcona |
jeff: Yeah, and it's not just my decision. I mostly do what the folks in Library Applications say to do. |
| 15:07 |
* Dyrcona |
contemplates a Lp entry for 3.4 to remove the copy alert field. |
| 15:13 |
Dyrcona |
No matter what size you get, there are never enough chips in a bag. |
| 15:14 |
|
yboston joined #evergreen |
| 15:14 |
mmorgan |
:) |
| 15:39 |
jeff |
Is there a reason that system-level copy alert messages create a row in asset.copy_alert when they are ack'd? |
| 15:40 |
jeff |
It looks like they always have temp = true, create_time = ack_time, and create_staff = ack_staff. |
| 15:46 |
mmorgan |
Hmm. |
| 15:47 |
* mmorgan |
sees many rows in asset.copy alert with data like jeff describes, all have NULL in the note field. |
| 15:48 |
* jeff |
nods |
| 15:48 |
|
nfBurton joined #evergreen |
| 15:49 |
jeff |
and regarding bug 1814799, is there a scenario where you'd ever want to manually apply a copy alert that has been configured with a state value other than NORMAL? |
| 15:49 |
pinesol |
Launchpad bug 1814799 in Evergreen "State-Specific Copy Alerts Ignore State of Item" [Undecided,New] https://launchpad.net/bugs/1814799 |
| 15:53 |
jeff |
while we're on the subject, I'm also wondering about the comment in the upgrade script where the stock state <> 'NORMAL' copy alert types are enabled: |
| 15:53 |
jeff |
> Making the following copy alert types active by default; if you are not using the web staff client yet, you may want to disable them. |
| 15:55 |
jeff |
I think it might be based on the "upstream" comment: copy alerts upon checkin or renewal of exceptional copy statuses are not active by default; they're meant to be turned once a site is ready to fully commit to using the webstaff client for circulation |
| 15:55 |
jeff |
but neither is clear on the anticipated impact or reasons why you wouldn't enable them if you are not "ready to fully commit" |
| 16:02 |
|
yboston joined #evergreen |
| 16:08 |
|
sandbergja_ joined #evergreen |
| 16:22 |
|
khuckins joined #evergreen |
| 16:30 |
jeff |
in practice, turning on the stock event id 7 for alerting on checkin of DAMAGED items does not seem to impact the xul client in any observable adverse way. |
| 16:31 |
jeff |
(tested that a while ago, but just re-tested with a little more double-checking) |
| 16:33 |
mmorgan |
jeff: We seem to be accumulating rows in asset.copy_alert for checkins/checkouts in the xul client of exceptional status items. That's probably a good enough reason to disable the alerts. |
| 16:33 |
jeff |
In my observation, those rows are generated no matter if you're using the web or xul client. |
| 16:34 |
mmorgan |
Interesting. |
| 16:34 |
jeff |
...which is why I asked above if anyone knew their intent/purpose. |
| 16:34 |
* mmorgan |
obviously does not :) |
| 16:52 |
* jeff |
just spent a minute troubleshooting why a checkin alert wasn't resulting in a modal... |
| 16:52 |
jeff |
...while repeatedly scanning the item into item status instead of checkin |
| 16:54 |
mmorgan |
:) |
| 16:56 |
jeff |
ack_time is set when clearing an alert from Manage Copy Alerts, but ack_staff isn't. Looks like ack_staff is only set when an alert is "temporary" and it's cleared from the alert dialog itself. |
| 16:58 |
mmorgan |
jeff++ # sharing observables |
| 17:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-04-03T16:58:26,496333537-0400 -0> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:15 |
|
sandbergja_ joined #evergreen |
| 17:37 |
Bmagic |
I forget: is there a setting to keep a hold targeted on the first copy targeted for a certain amount of time before retargeting? But just for the first copy targeted? |
| 17:41 |
berick |
Bmagic: no such setting I'm aware of |
| 17:41 |
Bmagic |
ok thanks, I must be getting some settings crossed in my head |
| 17:41 |
Bmagic |
I think I am thinking of soft stalling |
| 17:42 |
berick |
yeah, stalling is probably the closest thing |
| 17:43 |
Bmagic |
in the case of soft stalling - the setting here is 2 days but the retarget is 1 day. So, which date is soft stalling referencing? prev_check_time? |
| 17:44 |
Bmagic |
it wouldn't make sense to be prev_check_time unless there was only a single copy that it could fill it with and no one pulled it for 2 days, then another copy was suddenly checked in after 2 days somewhere else |
| 17:51 |
berick |
stalling only affect opportunistic (checkin-time) capture |
| 17:51 |
berick |
and it's based on the hold request time |
| 19:50 |
|
bos20k joined #evergreen |
| 21:34 |
|
sandbergja joined #evergreen |
| 21:46 |
jeff |
Hrm. Managed to get a double set of holds on a patron. |
| 21:47 |
jeff |
(patron has two holds, holds tab shows each hold twice) |
| 22:19 |
|
Christineb joined #evergreen |
| 23:36 |
|
sandbergja joined #evergreen |
