| Time |
Nick |
Message |
| 00:48 |
|
beanjammin joined #evergreen |
| 07:09 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:50 |
|
bdljohn joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:38 |
|
bos20k joined #evergreen |
| 08:44 |
|
Dyrcona joined #evergreen |
| 09:13 |
JBoyer |
If anyone with some eg-grid insight sees this today, I'm getting stuck working with a grid to display overdue items. The gist is that when the interface first loads several columns are blank, and when the grid is refreshed tjey |
| 09:13 |
JBoyer |
they're filled in. |
| 09:14 |
JBoyer |
I'd like to have all visible columns displayed on first load and am having a hard time tracking down the issue. (assuming it's a race condition of some kind, which is awesome to track down.) |
| 09:18 |
JBoyer |
Looks like that's definitely the case because anything that's hidden in the template isn't fetched, while adding the required or removing the hidden attribute makes a column appear. :/ |
| 09:22 |
|
yboston joined #evergreen |
| 09:23 |
Dyrcona |
JBoyer: I'm not an eg-grid expert but I seem to recall some bugs similar to what you're talking about having been fixed in the past few months. Something to do with adding columns and the values not being filled until a reload was done. If you can find those and look at the code changes, that might help. |
| 09:24 |
JBoyer |
Dyrcona++ |
| 09:24 |
JBoyer |
I'll starting arguing with LP search. |
| 09:24 |
Dyrcona |
Good luck. |
| 09:29 |
rhamby |
JBoyer: I feel like you should receive a blessing from an old holy man for that quest |
| 09:34 |
mmorgan |
JBoyer: possibly helpful? lp 1760997 |
| 09:34 |
pinesol |
Launchpad bug 1760997 in Evergreen 3.0 "Web Client Holds Pull List - Pickup/Request Library Fields Sometimes Blank" [Undecided,Fix released] https://launchpad.net/bugs/1760997 |
| 09:37 |
JBoyer |
rhamby, I would appreciate an old man in a cave telling me it's dangerous to go alone and offering up a wooden sword. |
| 09:38 |
rhamby |
JBoyer: would MDF be close enough to wood? |
| 09:38 |
JBoyer |
mmorgan, that's definitely the same issue, but the chosen way to address it was to sprinkle 'required' all over the place. :/ That works but it's only hiding the issue. |
| 09:38 |
|
bdljohn joined #evergreen |
| 09:38 |
JBoyer |
rhamby, possibly better for smacking things. |
| 09:38 |
|
sandbergja joined #evergreen |
| 09:47 |
mmorgan |
JBoyer: Ok, so it's using MDF where wood would be better ;-). |
| 09:47 |
JBoyer |
mmorgan++ # :D |
| 10:07 |
Dyrcona |
@who had the brilliant idea for release notes in point releases. |
| 10:07 |
pinesol |
mnsri had the brilliant idea for release notes in point releases. |
| 10:08 |
Dyrcona |
@blame Dyrcona |
| 10:08 |
pinesol |
Dyrcona: Dyrcona broke Evergreen. |
| 10:08 |
Dyrcona |
:D |
| 10:10 |
|
Christineb joined #evergreen |
| 10:16 |
sandbergja |
Dyrcona++ |
| 10:20 |
berick |
JBoyer: if a grid column is hidden its data won't be fetched unless it's required. for auto/fielder grids, anyway. otherwise the amount of data per grid could be massive. |
| 10:21 |
berick |
if the column is visible, of course it should fetch/render |
| 10:24 |
JBoyer |
berick, I understand that, I was just hoping the determination of "is this visible or not" could be made after looking up the user's saved column settings. Otherwise you get a customized grid with a bunch of holes in it. |
| 10:25 |
berick |
JBoyer: oh, yeah, that should be the case. that's the intention, anyway. |
| 10:27 |
JBoyer |
I don't know if it's not happening for me on 3.2 because I'm missing something (I basically just cloned and /transit/overdue/g 'd the transit list to start) or if it's not quite ready everywhere. |
| 10:28 |
* berick |
agrees forcing fields to be required is not the ideal solution |
| 10:31 |
|
beanjammin joined #evergreen |
| 10:32 |
jeff |
speaking of required fields... |
| 10:33 |
berick |
JBoyer: sorry, just catching up, which UI? |
| 10:33 |
jeff |
Does anyone else have interest in a level of "requiredness" just below "required" for patron fields? |
| 10:34 |
jeff |
Idea being, warn on a blank field but don't force the user to enter data in it. There might be a common method of doing that now, but I don't think there is short of "recommended", which isn't quite the right fit. |
| 10:34 |
JBoyer |
A new one, I copied the transit list UI (/circ/transits/list) and am customizing it to show overdue circs instead. |
| 10:35 |
JBoyer |
I gave it a unique persist key, saving columns works, everything works fine after reload, just not custom cols on first load. |
| 10:36 |
Dyrcona |
jeff: You mean something like "recommended" or "suggested?" It would be a good idea to fill this field in, but not required to do so? |
| 10:36 |
JBoyer |
Ah, but you can see the same issue in the transits list as-is. Add Author(normalized) and then save the columns. When you first arrive at the transit list the Author column is blank, if you change the dates or otherwise trigger a refresh it will populate. |
| 10:38 |
jeff |
Dyrcona: something almost identical to "required", but without the hard stop on creating/saving. A warning dialog allowing the operation to continue or to go back and fill in the required data, as opposed to an error dialog that gives no option to proceed with the operation. |
| 10:39 |
jeff |
Dyrcona: some mail clients warn on empty subject or empty body, but you can then say okay and send the message anyway. |
| 10:40 |
Dyrcona |
jeff: If it saves without the field filled in, then it sounds like "recommended fields" to me. :) |
| 10:40 |
berick |
JBoyer: ok, good, that's helpful. |
| 10:40 |
jeff |
recommended saves silently without bringing the missing field to the user's attention. |
| 10:42 |
* Dyrcona |
forgot we had that option already. |
| 10:42 |
jeff |
so perhaps "warn on missing recommended fields" would suffice, though there are a lot of "recommended" fields that are not that important. i think most of our libraries use it as a means to cut down clutter of "seldom" fields. |
| 10:46 |
Dyrcona |
Well, we could add "suggested" or some similar wording for something in between recommended and required. |
| 10:47 |
Dyrcona |
That said some people seem to get confused enough with required fields. |
| 10:47 |
jeff |
oh, sorry. pretty sure we don't have both recommended and suggested. i was incorrectly mixing both words to describe the same thing. |
| 10:48 |
jeff |
a required field where staff does not have the information at hand to complete the field can lead to either 1) not creating/saving the patron, or 2) entering incorrect data -- which is what had me thinking about error vs warn on the subject. |
| 11:17 |
|
khuckins joined #evergreen |
| 11:21 |
|
jvwoolf joined #evergreen |
| 11:22 |
mmorgan |
Recycling a question from Friday: Does anyone have a procedure for globally removing/forgiving fines from patron accounts? |
| 11:26 |
|
sandbergja joined #evergreen |
| 11:29 |
Dyrcona |
cesardv: You know you have the power to signoff and push the fix for https://bugs.launchpad.net/evergreen/+bug/1796978, right? |
| 11:29 |
pinesol |
Launchpad bug 1796978 in Evergreen 3.2 "Web client cannot create two or more copies at the same time" [High,Confirmed] |
| 11:50 |
|
plux joined #evergreen |
| 11:51 |
|
aabbee joined #evergreen |
| 11:57 |
JBoyer |
berick, something I'm noticing is that grid.js calls grid.loadConfig() and then (hah) a .then sets $scope.columns, but that's where that chain ends. So if link() is called before that .then is called, it won't have the right list of columns. |
| 11:58 |
JBoyer |
I haven't been able to work my way around to where link() is first called on page load, so if I'm just shouting randomly into the woods don't mind me. |
| 11:59 |
berick |
JBoyer: you're def. in the right territory... |
| 11:59 |
* berick |
is unable to look at the moment, but keeping an ear open |
| 11:59 |
JBoyer |
++ |
| 12:00 |
plux |
JBoyer: That rings a bell here. Having an issue with title displaying in staff client where a. is called |
| 12:13 |
|
bdljohn joined #evergreen |
| 12:58 |
|
nfburton joined #evergreen |
| 13:03 |
|
beanjammin joined #evergreen |
| 13:33 |
|
yboston joined #evergreen |
| 13:56 |
|
jihpringle joined #evergreen |
| 13:58 |
|
jvwoolf1 joined #evergreen |
| 14:00 |
Bmagic |
It seems that the new search highlighting tt2 code may have ended up removing extended titles in the record summary page. The code prefers to display the varaiable attrs.hl.title over attrs.title_extended |
| 14:12 |
berick |
JBoyer: I have a fix for the grid display issue... |
| 14:13 |
berick |
as expected, race condition. it was always there, just more obvious now with the on-server workstation settings |
| 14:16 |
|
bdljohn joined #evergreen |
| 14:20 |
* berick |
opens bug |
| 14:42 |
mmorgan |
berick++ |
| 14:53 |
|
kmlussier joined #evergreen |
| 14:58 |
|
stephengwills joined #evergreen |
| 15:04 |
|
mmorgan1 joined #evergreen |
| 15:14 |
JBoyer |
berick++ |
| 15:14 |
JBoyer |
berick++ |
| 15:15 |
JBoyer |
I've been looking at things on and off; very glad you had time to knock it out. |
| 15:18 |
JBoyer |
I'll test that branch out, but something that occured to me when I was looking earlier is that applyControlFunctions will always only look at the default columns since it's called before the columns are loaded. |
| 15:19 |
JBoyer |
Not really knowing where those are used I'm not sure how to even verify that at the moment. |
| 15:20 |
berick |
JBoyer: that should be OK |
| 15:20 |
berick |
that's most setup for future actions |
| 15:20 |
berick |
*mostly |
| 15:21 |
JBoyer |
Sounds good then. I didn't figure it would affect this, but wondered if it would matter later. |
| 15:30 |
|
khuckins joined #evergreen |
| 16:15 |
JBoyer |
bug 1798170 is tested, signed, etc. and all around happier with the order of operations. |
| 16:15 |
pinesol |
Launchpad bug 1798170 in Evergreen "Custom grid columns fail to display on initial load" [Undecided,New] https://launchpad.net/bugs/1798170 |
| 16:31 |
* kmlussier |
shakes her head at JBoyer's Carly Rae Jepsen impersonation on bug 1798170. |
| 16:31 |
pinesol |
Launchpad bug 1798170 in Evergreen "Custom grid columns fail to display on initial load" [Undecided,New] https://launchpad.net/bugs/1798170 |
| 16:32 |
berick |
har |
| 16:37 |
berick |
can't help but read it in a Mel Brooks voice |
| 16:38 |
|
mmorgan joined #evergreen |
| 16:39 |
Bmagic |
what happened to the old copy alert in 3.1. Has anyone migrated the old alerts to the new? or did I miss that step in the postgres upgrade scripts? |
| 16:45 |
jeffdavis |
Bmagic: there is a step in the 3.1.0 upgrade script to copy asset.copy.alert_message to the new asset.copy_alert table, 1098 |
| 16:53 |
Bmagic |
ah! |
| 16:59 |
jeff |
yeah, which I recommend XUL-client-users consider deferring. :-) |
| 16:59 |
berick |
jeff: do tell... |
| 17:00 |
jeff |
going from memory, but I think the new-style copy alerts are a feature that can't straddle XUL / web. |
| 17:00 |
csharp |
JBoyer++ |
| 17:00 |
Dyrcona |
I believe that jeff is correct on that one. |
| 17:03 |
Bmagic |
yeah, I am starting to learn that |
| 17:03 |
Bmagic |
It seems possible that xul users could make the old style alert though |
| 17:03 |
Bmagic |
will the web client respect the old alert? |
| 17:04 |
jeff |
and it isn't sufficient to just hold off on using the feature in new ways. the upgrade script migrated legacy copy alerts in a way that made them at least no longer visible / editable by the xul client, even if they continued to fire. |
| 17:05 |
jeff |
i do not think we've yet tested if the code supports the legacy copy alert message in the web client, or if we need to revert/change some things there until we're off xul. |
| 17:05 |
|
mmorgan left #evergreen |
| 17:05 |
jeff |
it was a late discovery in pre-upgrade planning process for us when we jumped from 2.10 to 3.1. |
| 17:06 |
Dyrcona |
The test server isn't testing, or is it just not posting to the channel? |
| 17:06 |
berick |
jeff: are you just using the browser client for all copy-alert related stuff? |
| 17:07 |
jeff |
berick: no, we skipped the migration of copy alerts in the relevant upgrade script, so our legacy alerts remain in-table. |
| 17:07 |
|
stephengwills left #evergreen |
| 17:08 |
jeff |
i believe that i didn't also need to revert any code, but that's going from memory. i can check notes later this evening. |
| 17:08 |
berick |
jeff++ |
| 17:08 |
berick |
i'm in early stages of plottin a 2.12 -> 3.2 upgrade |
| 17:09 |
berick |
and xul will still be in play for some time anway |
| 17:16 |
* kmlussier |
confirms that the migration of copy alerts should wait until everyone in the system, particularly catalogers, are using the web client. |
| 17:17 |
|
cesardv joined #evergreen |
| 17:18 |
berick |
kmlussier: do you recall delaying having negative impacts on the browser client? |
| 17:21 |
kmlussier |
berick: Well, neither of the MassLNC consortia are on 3.1 yet, so I don't have production experience. I just know that xul catalogers won't be able to add alerts once they are upgraded. Since cataloging is one area where a lot of people are still using xul, that's a problem. |
| 17:22 |
berick |
got it, thanks kmlussier |
| 17:22 |
jeff |
I have a local todo to look into it. I have a suspicion that it might be messy. The web client probably sees the alerts at checkin/checkout but probably can't successfully modify them, at least not in a way that doesn't lead to alert message bifurcation. :-) |
| 17:31 |
|
cesardv joined #evergreen |
| 17:43 |
|
khuckins_ joined #evergreen |
| 17:57 |
bshum |
Dyrcona: I'm pretty sure the test server isn't posting to channel because phasefx has to rebuild it out of Wheezy and into Stretch or some other supported distro |
| 17:57 |
bshum |
So yeah, no telling how long it's been since the last successful test run :\ |
| 17:58 |
bshum |
I haven't run one in awhile myself. |
| 18:00 |
|
khuckins joined #evergreen |
| 18:36 |
|
nfburton joined #evergreen |
| 18:47 |
Dyrcona |
bshum: I'm just curious if it is having failures. On rel_3_0, I'm getting live_t/20-hold-targeter.t failing, on master on Ubuntu 18, live_t/09-lp1198465_neg_balances.t fails for me. |
| 18:48 |
Dyrcona |
tests+- |
| 19:15 |
Dyrcona |
OK. Tests are working for me on master after reloading concerto. |
| 21:51 |
Bmagic |
What does it mean when OpenSRF::Transport /usr/local/share/perl/5.22.1/OpenSRF/Transport.pm:83 Session Error: router private.localhost/open-ils.serial IS NOT CONNECTED TO THE NETWORK!!! ? Ejabberd is messed up? Which config should I tweak do you think? |
| 22:14 |
|
beanjammin joined #evergreen |
