| Time |
Nick |
Message |
| 00:25 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:19 |
|
agoben joined #evergreen |
| 07:48 |
|
gsams__ joined #evergreen |
| 07:58 |
|
collum joined #evergreen |
| 08:09 |
csharp |
at some point, I'd like some pointers about core committer guidelines/expectations... I have a couple of basic workflow questions: |
| 08:10 |
csharp |
1) when I'm the person who signs off on a bug should I also be the person who commits the change? Or should I wait for a third person to do that? |
| 08:11 |
csharp |
2) what are the criteria for picking a change into currently supported releases? I can infer some of this from example, but didn't want to assume I was correct. |
| 08:11 |
csharp |
if there are docs around for this, I haven't seen them before |
| 08:22 |
|
rlefaive joined #evergreen |
| 08:28 |
|
rlefaive joined #evergreen |
| 08:52 |
|
mmorgan joined #evergreen |
| 08:54 |
|
rlefaive joined #evergreen |
| 08:57 |
|
lsach joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:00 |
|
idjit joined #evergreen |
| 09:12 |
dbwells |
csharp: I am not aware of docs, but I'll answer best I can. 1) No third person is needed, unless you think the patch could use a third signoff. 2) If it is a bugfix and it merges cleanly, I almost always backport. If it is borderline or the merge isn't easy/obvious, I'll try to create a branch with the edited backport commit, but will leave it to the release maintainer or others to push in. |
| 09:15 |
Dyrcona |
Additional sign offs are encouraged if there are no tests or test plan. |
| 09:16 |
dbwells |
csharp: For 3.1 webstaff fixes in particular, I am going to lean in the direction of calling things bugfixes (and therefore backport) unless it is very obviously a new feature. |
| 09:16 |
|
kmlussier joined #evergreen |
| 09:17 |
Dyrcona |
I'll usually backport if it is a bugfix, the bug is targeted, and any merge conflicts are obvious to resolve. |
| 09:20 |
|
yboston joined #evergreen |
| 09:29 |
|
littlet joined #evergreen |
| 09:30 |
csharp |
dbwells: Dyrcona: thanks! |
| 09:31 |
kmlussier |
I concur with everything Dyrcona and dbwells said. Additionally, there are times when a branch works for me, but I don't feel comfortable evaluating the code changes. I'll usually add a signoff branch and ask somebody else to take a look at it. |
| 09:31 |
kmlussier |
csharp: Also, this is helpful to use as a guide before merging. https://wiki.evergreen-ils.org/doku.php?id=dev:signoff_review_checklist |
| 09:40 |
Dyrcona |
So, if you're considering using my SQL to clean up old action trigger events, be aware that old bills will quite likely come back and be sent again. |
| 09:47 |
Dyrcona |
Hm... There's no easy way to figure out what the date is on an event that made it into an action_trigger.event....It's different for each event.... |
| 09:47 |
Dyrcona |
Might be nice to add an event_date column to track that. |
| 09:49 |
|
terran joined #evergreen |
| 09:52 |
Dyrcona |
Not having max_delay set has something to do with it....Guess we should have set a max_delay on the bill definitions. |
| 09:56 |
|
jvwoolf joined #evergreen |
| 10:06 |
Dyrcona |
So, it looks like there is nothing in the database that links the event and event definition with a database table. There is the delay_field, but you still have to know the table. Am I wrong? |
| 10:08 |
csharp |
kmlussier: perfect - thank you |
| 10:09 |
|
Christineb joined #evergreen |
| 10:09 |
mmorgan |
Dyrcona: Does action_trigger.event.add_time help with the "date" of the event? |
| 10:10 |
Dyrcona |
No, because I have bills for events from before the migration being generated. |
| 10:10 |
Dyrcona |
I should have really thought this through and added a max_delay before doing the delete. |
| 10:11 |
Dyrcona |
That's what happens when you test something on a system not running action trigger cron jobs. |
| 10:12 |
Dyrcona |
I ran this last night: https://pastebin.com/34t5AY1z |
| 10:13 |
Dyrcona |
I figured I was shutting things down for an OpenSRF update, so why not? ..... :/ |
| 10:16 |
jeffdavis |
Dyrcona: action_trigger.hook has a core_type field if that helps |
| 10:17 |
jeffdavis |
(for linking events/event defs with a table) |
| 10:17 |
berick |
yeah, core_type essentially links the event to the target table |
| 10:17 |
Dyrcona |
jeffdavis: Thanks for mentioning that! |
| 10:17 |
Dyrcona |
Guess I can run a SQL to figure out how many and which events were affected. |
| 10:18 |
Dyrcona |
Can't fix it, now, but at least I can see how big the mess is. |
| 10:20 |
|
mmorgan left #evergreen |
| 10:25 |
jeffdavis |
I got a white screen with a "Cannot connect to offline DB" error related to duplicate keys - is there anything I should add to bug 1768947 before I clear local data? |
| 10:25 |
pinesol_green |
Launchpad bug 1768947 in Evergreen "web client: non-hatch white screen issues" [Medium,Confirmed] https://launchpad.net/bugs/1768947 |
| 10:29 |
|
mmorgan joined #evergreen |
| 10:29 |
berick |
jeffdavis: no other info in the indexdb error? |
| 10:30 |
jeffdavis |
The console log shows: Cannot connect to offline DB: Error: http://google.github.io/lovefield/error_lookup/src/error_lookup.html?c=201&p0=Object.pkObject&p1=%5B%22ccs%22%2C%222%22%5D |
| 10:30 |
jeffdavis |
That link resolves to: Constraint error: (201) Duplicate keys are not allowed, index: Object.pkObject, key: ["ccs","2"] |
| 10:31 |
berick |
ok, that's helpful |
| 10:31 |
jeffdavis |
I do see duplicate ccs entries with id=2 in IndexedDB Object storage |
| 10:31 |
berick |
oh, they're actually already in the table? |
| 10:31 |
kmlussier |
That's a little different than the other duplicate keys error messages that have been added to the bug. |
| 10:32 |
jeffdavis |
kmlussier: in my experience the specific duplicate key varies but that's the most common type of error I've seen |
| 10:34 |
* kmlussier |
nods |
| 10:34 |
jeffdavis |
If I go to IndexedDB > offline > Object, object IDs 321 and 345 both contain value {type:"ccs",id:"2",object:{...}}. |
| 10:34 |
csharp |
hmm |
| 10:35 |
berick |
yeah, you'd think it wouldn't get that far... |
| 10:35 |
Dyrcona |
To err is human. To really foul things up requires a computer. :) |
| 10:36 |
csharp |
ccs = config.copy_status? |
| 10:36 |
jeffdavis |
yeah |
| 10:36 |
jeffdavis |
if I look at CacheDate, I see duplicate entries for ccs, ccm, and acpl |
| 10:37 |
jeffdavis |
I think there are probably duplicate values in Object storage for all 3 of those, it's annoying to confirm since they're unsorted but there certainly seem to be too many of them |
| 10:38 |
jeffdavis |
a previous comment in the LP bug showed a duplicate key for Setting.pkSetting, key: "circ.staff.client.receipt.event_text" |
| 10:38 |
berick |
jeffdavis: in CacheDate are the dates close? |
| 10:39 |
berick |
wondering if the dupes are inserted at essentially the same time |
| 10:39 |
jeffdavis |
1528349745308 vs 1528349735365 |
| 10:39 |
* berick |
squints |
| 10:39 |
* jeffdavis |
counts on fingers |
| 10:39 |
* csharp |
pulls out abacus |
| 10:40 |
jeffdavis |
a difference of 10000 units approximately |
| 10:40 |
berick |
yeah |
| 10:40 |
berick |
not simultaneous |
| 10:40 |
csharp |
I don't have a key for ccs in my test server's offline DB right now |
| 10:40 |
csharp |
what adds it? |
| 10:41 |
* csharp |
tried circulating an item |
| 10:42 |
berick |
yeah, looks like copy satuses are fleshed during checkout |
| 10:42 |
jeffdavis |
I did a checkin, then a checkout, then hit F1 and got the white screen at that point |
| 10:42 |
berick |
and at that point likely get addded to offline cache |
| 10:42 |
jeffdavis |
I may have looked at bills but I didn't do much else |
| 10:44 |
csharp |
hmm - still not seeing the key in "Object" |
| 10:45 |
csharp |
I see it in CacheDate, but not in the active objects |
| 10:46 |
jeffdavis |
csharp: you have to page through them |
| 10:46 |
jeffdavis |
do you see a textbox that says "Start from key"? There is a right-pointing triangle beside it for paging through the rows (there are 100 to a page I think) |
| 10:47 |
csharp |
I'm in FF - maybe I'll try it in Chrome |
| 10:48 |
jeffdavis |
(50 per page rather) |
| 10:50 |
csharp |
yeah - that works in Chrome - maybe I'm just missing the control in FF - moving on... |
| 10:51 |
berick |
can't get it to fail over here |
| 10:51 |
|
rlefaive joined #evergreen |
| 10:53 |
berick |
by fail I mean cause duplicate entries |
| 10:53 |
berick |
of course once the dupes are there, all bets are off |
| 10:54 |
berick |
jeffdavis: the ccs values in Object, do the dupes both show the id as a string? |
| 10:54 |
berick |
wondering if one gets inserted w/ a string ID and the other w/ a numeric id |
| 10:55 |
berick |
hopefully indexdb is smarter than that |
| 10:55 |
* csharp |
is looking for the logic that inserts the key in the first place |
| 10:55 |
jeffdavis |
yes, it appears to be a string in both cases: id: "2" |
| 10:55 |
berick |
jeffdavis: thanks |
| 10:56 |
berick |
csharp: env.js service.absorbList() |
| 10:56 |
berick |
ccs objects are fetched then run though that function to cache them essentially |
| 10:57 |
csharp |
berick: thanks |
| 10:57 |
berick |
during the caching, they get added to the indexdb via lovefield |
| 10:57 |
berick |
funny thing is, all inserts are insertOrReplace() so there should /never/ be dupes |
| 11:01 |
|
NFPL joined #evergreen |
| 11:03 |
jeffdavis |
I added a few screenshots to the LP bug, let me know if there's any more info I can share |
| 11:06 |
csharp |
addPrimaryKey(['type','id']); |
| 11:06 |
csharp |
for "Object"^^ |
| 11:06 |
csharp |
"Lovefield supports auto-increment primary key, which must be an integer column with default ascending order, and its value will be assigned by Lovefield, starting from 1." |
| 11:07 |
csharp |
is it okay that the primary is type and id? |
| 11:09 |
Dyrcona |
csharp: I think it would have to be both fields if different objects are jammed into the same "table." |
| 11:09 |
berick |
i think the auto-increment/integer stuff only applies when using a sequence as the pkey |
| 11:09 |
berick |
if you define your own key, it can be (apparently) a combo of fields |
| 11:10 |
Dyrcona |
Multiple field keys are not that uncommon in the wild. :) |
| 11:10 |
csharp |
"There are two different insert builders: lf.Database#insert and lf.Database#insertOrReplace. The former allows insertion of new rows only (determined based on primary key), while the latter will overwrite any existing row" |
| 11:10 |
berick |
yeah, that's the puzzle... why is insertOrDelete not overwriting in these cases? |
| 11:11 |
csharp |
or maybe it tries to overwrite the wrong one? |
| 11:12 |
csharp |
then, "oh wait, that's a dupe" |
| 11:12 |
csharp |
that's why I was wondering about the compound key - but it may be barking up the wrong tree |
| 11:15 |
jeffdavis |
issue with multiple tabs open? https://github.com/google/lovefield/issues/172#issuecomment-256417524 |
| 11:16 |
berick |
oh, was wondering about that |
| 11:16 |
berick |
oh, heh, i was just reading the same thing |
| 11:16 |
berick |
hadn't gotten to the tabs bit yet |
| 11:16 |
kmlussier |
jeffdavis: I was just looking at that a few minutes ago. I've been trying to break it with multiple tabs open. No luck so far. |
| 11:16 |
kmlussier |
Of course, I might not be doing the right things. |
| 11:16 |
berick |
i bet the timing has to be just-so |
| 11:17 |
csharp |
that definitely looks like our issue, though |
| 11:17 |
Dyrcona |
Race conditions... :) |
| 11:18 |
berick |
https://github.com/google/lovefield/blob/master/docs/spec/03_life_of_db.md#32-multi-process-connection |
| 11:19 |
berick |
may have to migrate the lovefield to a webworker/serviceworker |
| 11:19 |
berick |
so there's only a single connection |
| 11:19 |
jeff |
``Users shall be aware of this problem and plan accordingly.'' |
| 11:20 |
jeffdavis |
We have been warned! |
| 11:21 |
* berick |
adds some notes to the LP |
| 11:23 |
|
rlefaive joined #evergreen |
| 11:26 |
* miker |
reads up |
| 11:27 |
miker |
berick: re service worker, or we could possibly use message passing to "claim" the connection |
| 11:28 |
miker |
broadcast a "I want to connect to lovefield, is anyone else connected? |
| 11:34 |
|
rlefaive joined #evergreen |
| 11:35 |
berick |
miker: interesting.. we could use localStorage to track the "spirit stick" and listen for storage events to see when it changes |
| 11:35 |
berick |
https://developer.mozilla.org/en-US/docs/Web/API/StorageEvent |
| 11:36 |
berick |
(so we don't have to poll) |
| 11:37 |
miker |
berick: that's neat. that could allow us to force others to stop using lf when offline needs it, too... |
| 11:42 |
berick |
wonder how much wiggle room for race conditions exist there, since the events are i assume asynchronous. e.g. if tab 2 can grab the db before the "i have it" event propagates. |
| 11:42 |
berick |
... from tab 1 |
| 11:45 |
jeffdavis |
The error is reproducing consistently for me right now. (1) Retrieve a patron, (2) Open Checkin in a new tab and check in an item, (3) In your first tab, check out the item to that patron, (4) In the same tab, hit F1 to search for patron by barcode. I'm getting the white screen at that point. |
| 11:46 |
berick |
jeffdavis++ |
| 11:47 |
berick |
miker: using indexdb for the offline cache, was the concern localstorage might get filled up / cleared? |
| 11:48 |
miker |
yes. re filled, particularly with offline block list (5MB limit, IIRC), and clearing local storage is 10x easier than killing indexeddb |
| 11:48 |
berick |
wondering if it would make more sense to only use indexb for the block list and offline transactions, which would be easier to limit to a single tab. |
| 11:48 |
berick |
and use localStorage for the data cache |
| 11:49 |
miker |
well, you need a pile of objects in order for offline to work. that data is much easier to reload, of course, but critical to functioning offline |
| 11:50 |
miker |
we could forcibly reload it at login, a la xulrunner's login caching |
| 11:51 |
|
stephengwills joined #evergreen |
| 11:51 |
miker |
but if step 1 in troubleshooting is "clear cache" when the problem is really that the server is having problems, you've just removed the ability to do offline while the server is down :( |
| 11:51 |
* kmlussier |
still can't replicate it following jeffdavis' steps |
| 11:52 |
csharp |
kmlussier: jeffdavis: I wasn't able to replicate it either :-/ |
| 11:52 |
jeffdavis |
:( |
| 11:52 |
csharp |
my test server is apparently borked, JS-wise - I keep getting partially loading UIs and "blah is not a function" errors :-/ |
| 11:53 |
csharp |
gonna blow it away and start a new one I think |
| 11:53 |
* berick |
is reminded of https://developers.google.com/web/updates/2016/06/persistent-storage |
| 11:55 |
jeffdavis |
A second person was able to reproduce the white screen with those steps in our environment. Interesting that it doesn't work elsewhere. |
| 11:58 |
|
gsams joined #evergreen |
| 12:01 |
kmlussier |
jeffdavis: I just replicated it on another server following your steps. The other environment is on 3.0 (I was previously testing on 3.1) and has production data instead of Concerto. |
| 12:02 |
kmlussier |
I wonder if I was able to replicate it more easily because, with production data, the transactions move a little more slowly, allowing me to get the timing right? |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:02 |
jeffdavis |
Oh neat! Yeah, I am seeing it in production with 3.1.0 (+ many backports). |
| 12:05 |
jeffdavis |
I realize it's a little weird to be excited that something *isn't* working... |
| 12:06 |
berick |
on the contrary, reproducing a bug is a joyous occasion |
| 12:06 |
mmorgan |
Indeed! Reproducing failure can be very satisfying! |
| 12:06 |
kmlussier |
Yes, I agree. I hate bugs that can't be reproduced. |
| 12:07 |
kmlussier |
In fact, I think that's in my list of hates. |
| 12:07 |
kmlussier |
@hate |
| 12:07 |
pinesol_green |
kmlussier: (hate <thing>) -- Declare your hate for <thing> |
| 12:07 |
kmlussier |
hmmm...I forget how to do that. |
| 12:07 |
jeff |
perhaps not as fun as scanning for lifeforms, but enjoyable! |
| 12:07 |
kmlussier |
@hates |
| 12:07 |
pinesol_green |
kmlussier hates Launchpad search; Internet Explorer; snow; scheduling meetings; Starbucks; negative balances; undrinkable coffee; winter; blizzards; spam; dojo interfaces; Windows line endings; peanut M&Ms; bad technology days; authorities; pollen; comcast; comcast even more; inconsistent bugs; intermittent problems; and deadlines |
| 12:11 |
|
Dyrcona joined #evergreen |
| 12:14 |
|
rlefaive joined #evergreen |
| 12:15 |
|
khuckins joined #evergreen |
| 12:18 |
|
sandbergja joined #evergreen |
| 12:19 |
sandbergja |
Is there a way to get information about the billed patron in the "Bills, Current" receipt template? |
| 12:19 |
sandbergja |
I feel like I saw a LP bug about it, but can't find it. :-( |
| 12:20 |
sandbergja |
We can use {{patron}} in the template editor to get fake data, but it doesn't give us real data when we try to print out a real bill |
| 12:20 |
berick |
kmlussier: jeffdavis: the 'cannot connect to offline db' console message, what line number does it show? |
| 12:21 |
csharp |
sandbergja: consulting docs by terran at https://pines.georgialibraries.org/dokuwiki/doku.php?id=circ:workstations:receipts and https://pines.georgialibraries.org/dokuwiki/doku.php?id=circ:workstations:receipt-content shows that the fields you're after aren't available at this point |
| 12:22 |
jeffdavis |
berick: core.bundle.js:1 here |
| 12:22 |
sandbergja |
csharp++ |
| 12:22 |
sandbergja |
terran++ |
| 12:22 |
kmlussier |
sandbergja: bug 1772053? |
| 12:22 |
pinesol_green |
Launchpad bug 1772053 in Evergreen "Web Client: Print Templates - Missing/Problem Fields" [Undecided,New] https://launchpad.net/bugs/1772053 |
| 12:22 |
sandbergja |
that's so so helpful! |
| 12:22 |
berick |
jeffdavis: heh, ok, lame. |
| 12:23 |
jeffdavis |
:) |
| 12:23 |
|
beanjammin joined #evergreen |
| 12:24 |
jihpringle |
sandbergja: bug 1772444 |
| 12:24 |
pinesol_green |
Launchpad bug 1772444 in Evergreen 3.0 "User information missing from billing receipts" [Undecided,Confirmed] https://launchpad.net/bugs/1772444 |
| 12:24 |
terran |
sandbergja: JBoyer has a patch here that has been signed off but not committed yet: https://bugs.launchpad.net/evergreen/+bug/1772444 |
| 12:24 |
terran |
Jinx! |
| 12:25 |
jihpringle |
:) |
| 12:25 |
berick |
jeffdavis: so, one problem is the db connect promise is never rejected on failure. it just logs the error. that could prevent the browser from continuing to render. I actually address that in my patch for bug 1727557 |
| 12:25 |
pinesol_green |
Launchpad bug 1727557 in Evergreen 3.1 "Web Client: Download Block List causes unresponsive page with large file" [High,Confirmed] https://launchpad.net/bugs/1727557 |
| 12:26 |
berick |
but it would be simple enough to confirm if a reject() alone will allow the browser to continue... |
| 12:26 |
pastebot |
"berick" at 64.57.241.14 pasted "offline db connect promise reject" (20 lines) at http://paste.evergreen-ils.org/9096 |
| 12:27 |
berick |
jeffdavis: kmlussier: could either of you test this patch? ^-- just wondering if we can let the browser recover from the error |
| 12:27 |
sandbergja |
jihpringle++ |
| 12:27 |
sandbergja |
kmlussier++ |
| 12:27 |
sandbergja |
You are all so great! |
| 12:27 |
berick |
we still need to fix the db, of course, but maybe we can buy a little time |
| 12:27 |
kmlussier |
berick: Unfortunately, the test system where I can load patches is not the one where I was able to replicate the problem. |
| 12:28 |
* berick |
nods |
| 12:32 |
jeffdavis |
confirmed the duplicate keys error on a test server, I'll give that patch a try |
| 12:36 |
jeffdavis |
berick: I still get the white screen with that patch |
| 12:37 |
berick |
jeffdavis: ah well, thanks for testing |
| 12:37 |
jeffdavis |
on the plus side, in the test environment the error is pinpointed to lovefield.js:78 if that helps |
| 12:38 |
berick |
it does |
| 12:40 |
jeffdavis |
(that's the line immediately before the first deferred.reject() from your patch in case our line numbers are out of sync) |
| 12:41 |
berick |
oh, just recreated the error |
| 12:41 |
berick |
neat |
| 12:46 |
|
beanjammin joined #evergreen |
| 12:50 |
|
Jaswinder joined #evergreen |
| 12:51 |
Jaswinder |
Hey guys, I need to read the id (sequence field) using the pcrud call, i am getting 'undef' value. I am using the following way: $req->recv()->[0]->id |
| 12:52 |
berick |
maybe: $req->recv()->content->[0]->id |
| 12:52 |
berick |
that assumes a .atomic pcrud call |
| 13:00 |
Dyrcona |
I'm getting a lot of these today: XMPP message resulted in error code 503 |
| 13:01 |
Dyrcona |
Looks like they are all coming from osrf_http_translator. |
| 13:02 |
|
yboston joined #evergreen |
| 13:02 |
Dyrcona |
Service unavailable? |
| 13:04 |
Jaswinder |
berick: Yes, it is atomic call. I tried that and got the same 'undef' |
| 13:04 |
jeffdavis |
Dyrcona: which logfiles? |
| 13:04 |
Dyrcona |
jeffdavis: osrferror.log |
| 13:04 |
berick |
jeffdavis: kmlussier: FYI https://bugs.launchpad.net/evergreen/+bug/1768947/comments/13 |
| 13:04 |
pinesol_green |
Launchpad bug 1768947 in Evergreen "web client: non-hatch white screen issues" [Medium,Confirmed] |
| 13:06 |
Dyrcona |
Also, have two apache2-websockets using 100% cpu on 1 brick but strace shows one of them going through munmap over and over again. |
| 13:06 |
Dyrcona |
jeffdavis: That's on all bricks by the way. |
| 13:06 |
Dyrcona |
The xmpp errors. |
| 13:07 |
Dyrcona |
Not sure the apache2-websockets on brick 3 is related to the xmpp errors. |
| 13:08 |
jeffdavis |
You applied berick's OpenSRF branch for bug 1774703 last night, right? |
| 13:08 |
pinesol_green |
Launchpad bug 1774703 in OpenSRF "Websockets processes locked at 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1774703 |
| 13:09 |
Jaswinder |
Just know that all other fields are returning the data fine. |
| 13:09 |
Dyrcona |
jeffdavis: Yes, I did. |
| 13:10 |
Dyrcona |
I've got 3 apache2-websockets doing something like the next two lines over and over on 2 bricks: |
| 13:10 |
Dyrcona |
munmap(0x7f65e5cb7000, 171216896) = 0 |
| 13:10 |
Dyrcona |
mmap(NULL, 171220992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f65e5cb6000 |
| 13:10 |
Dyrcona |
The calls appear to be the same but the addresses are likely different. |
| 13:10 |
jeffdavis |
Dyrcona: OK. I applied it here last night too. I still saw a few spinning websockets procs this morning, I've been waiting for more to appear before following up. I'm not seeing that XMPP 503 error in our logs though. |
| 13:11 |
Dyrcona |
jeffdavis: Ok, thanks. I did not assume the 503 was related, but it is what inspired me to check the server. |
| 13:11 |
Dyrcona |
I'll update the bug with strace output. |
| 13:13 |
* Dyrcona |
makes absolutely certain that the jchampio branch is installed on all of the bricks as well. |
| 13:14 |
Dyrcona |
It is. |
| 13:16 |
jeffdavis |
berick: for that white screen patch, I wonder if we should notify the user somehow that their offline DB is corrupt. |
| 13:17 |
jeffdavis |
I'm getting ahead of myself though, I should test the patch first. :) |
| 13:18 |
idjit |
the patch for bug 1775216 involves a change to a database function, so i'm guessing i should add a pgtap test for it. unfortunately, while i can execute pgtap and run all the existing tests and verify they pass, i have no idea what i'm doing when it comes to writing new test cases. any guidance? |
| 13:18 |
kmlussier |
jeffdavis: berick: Yes, I was thinking along the same lines. Although I think it's a good thing to get rid of the white screens, my concern is that users happily use the system until it goes down one day, and then they are unable to use offline. |
| 13:18 |
pinesol_green |
Launchpad bug 1775216 in Evergreen "Inconsistency between client and opac availability counts for statuses with is available flag" [Medium,Confirmed] https://launchpad.net/bugs/1775216 |
| 13:19 |
kmlussier |
berick: Do you expect it will take a long time to address the long-term fix for that issue? |
| 13:19 |
* kmlussier |
also hasn't tested the patch. :) |
| 13:35 |
jeffdavis |
tested the patch, works for me, I'll update LP |
| 13:36 |
csharp |
jeffdavis++ berick++ |
| 13:40 |
Jaswinder |
Can anyone help answer my question? I am basically stuck to retrieve the id field |
| 13:44 |
Dyrcona |
The XMPP 503 errors occur in my logs prior to the upgrade to 3.0, but with much less frequency than after. |
| 13:45 |
|
sandbergja joined #evergreen |
| 13:51 |
berick |
kmlussier: not sure yet... |
| 13:52 |
berick |
if we used localStorage for the cache, it would be pretty simple. that has numerous benifits (like only needing the db on the offline page). but there are concerns about staff deleteing data from local storage |
| 13:52 |
|
Dan-O joined #evergreen |
| 13:53 |
Dyrcona |
technology-- |
| 13:53 |
berick |
moving the indexeddb stuff into a webworker is probably the most correct thing to do, but also more involved |
| 13:54 |
* Dyrcona |
lost his wifi just long enough to mess up ssh connections, but not long enough for IRC to notice. |
| 13:56 |
Dyrcona |
Now, I have an apache2-websockets process that looks like the segfautled ones we were trying to fix. |
| 13:56 |
jeffdavis |
Jaswinder: it sounds like either the request is not returning any data or else the data doesn't contain an ID field. Can you use Data::Dumper to see what the response actually contains? |
| 13:57 |
jeffdavis |
I also wonder if you're trying to get the id in the middle of a transaction after first doing an insert, but before committing? I'm not sure how id's get populated in a circumstance like that. |
| 13:59 |
|
yboston joined #evergreen |
| 13:59 |
csharp |
2f7449a7 |
| 13:59 |
pinesol_green |
csharp: [evergreen|Bill Erickson] LP#1741072 Volcopy editor deposit amount format repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2f7449a> |
| 14:00 |
Jaswinder |
jeffdavis: The dumper shows all values except for id |
| 14:00 |
jeffdavis |
What pcrud request are you doing? Is it inside a transaction? |
| 14:01 |
|
rlefaive joined #evergreen |
| 14:02 |
Dan-O |
Question: (sorry to punk your meeting) Where's the best place to get evergreen configuration help? I posted to the mailing list a few days ago, but haven't heard back. |
| 14:03 |
Dyrcona |
Dan-O: There's no meeting, AFAIK. |
| 14:04 |
Dyrcona |
"It's just the normal noises in here...." ;) |
| 14:04 |
Dan-O |
ha ha OK |
| 14:04 |
berick |
Dyrcona: is that a tom petty reference ? |
| 14:04 |
Dyrcona |
What kind of help are you looking for? |
| 14:05 |
Dyrcona |
berick: Indeed. |
| 14:05 |
berick |
nice |
| 14:06 |
Dan-O |
I'm still learning to fly. Anyway this was me: |
| 14:06 |
Dan-O |
https://georgialibraries.markmail.org/search/?q=#query:+page:2+mid:czbbgy2l2ww2hyyl+state:results |
| 14:07 |
Dan-O |
Tailed a bunch of logs too and couldn't find an error messages to work with |
| 14:07 |
Dyrcona |
Dan-O: OK. That's why I didn't answer... Vandelay is not my thing, sorry. |
| 14:09 |
jeffdavis |
I get at least some of the same 404's when I load Vandelay here, but AFAIK it's working fine for us. |
| 14:11 |
sandbergja |
berick: this is from 7 years ago(!), but I'm finally getting around to adding this to the official docs: https://bugs.launchpad.net/evergreen/+bug/833820. Can you remember particular use cases for using POs without copies attached? |
| 14:11 |
pinesol_green |
Launchpad bug 833820 in Evergreen "Support PO activation without requiring bibs/items" [Wishlist,Fix released] |
| 14:12 |
csharp |
Dan-O: do you have access to the server logs? |
| 14:12 |
Dan-O |
Yeah |
| 14:12 |
Dan-O |
https://mlnc4.noblenet.org gets the same 404s and their's works fine too |
| 14:12 |
berick |
sandbergja: don't remember.. let me see if I can find someone who does.. |
| 14:13 |
sandbergja |
berick++ # thanks! |
| 14:13 |
csharp |
Dan-O: check the osrferror/osrfwarn logs (or if you don't have those, /openils/var/log/osrfsys.log) for anything that looks like an error? |
| 14:13 |
Dan-O |
ok |
| 14:15 |
kmlussier |
sandbergja / berick: Is it related to libraries that don't want to make their on-order items showing in the catalog? |
| 14:16 |
kmlussier |
Excuse the poor grammar in my question. |
| 14:16 |
berick |
kmlussier: i think that would be handled by making on-order non opac visible |
| 14:17 |
berick |
one use case is blanket orders -- before the new blanket order feature was available |
| 14:17 |
littlet |
kmlussier We don't show our on order copies in the catalog, so we do as berick says and make them opac invisible |
| 14:17 |
sandbergja |
the blanket orders makes sense |
| 14:18 |
littlet |
sandbergja You could use it if you've already loaded bibs and copies via the Actions menu |
| 14:18 |
Jaswinder |
jeffdavis: I am pcrud call: open-ils.pcrud.search.ebook_rds.atomic. I am pasting the piece of code including xml file code |
| 14:18 |
pastebot |
"jaswinder" at 64.57.241.14 pasted "Code snipper for retrieve data" (34 lines) at http://paste.evergreen-ils.org/9151 |
| 14:18 |
berick |
littlet: if the bibs & copies were already loaded, acq will know not to re-load them |
| 14:18 |
littlet |
Although even if I've done that I can still use Activate and it's fine -- yep |
| 14:19 |
sandbergja |
kmlussier: I just noticed that you'd claimed that feature on the doc needs! Sorry about that; I wasn't paying attention. I just started in on the first feature on the doc needs list. |
| 14:19 |
sandbergja |
kmlussier: Do you still want to do it? |
| 14:20 |
kmlussier |
sandbergja: No, please take it. I'm sure I claimed it back when I was spending more time on docs. |
| 14:20 |
jihpringle |
sandbergja kmlussier: http://docs.sitka.bclibraries.ca/Acq/production/html/activate-purchase-order.html#activation-wo-loaditems |
| 14:20 |
kmlussier |
sandbergja++ |
| 14:20 |
Dan-O |
csharp: open-ils.vandelay_drone_at_localhost_1193 open-ils.cstore 2018-06-07 11:17:43 [INFO:1131:osrf_stack.c:163:152839531411090] Message processing duration 0.000736 [2018-06-07 11:17:43] open-ils.vandelay [INFO:1193:CStoreEditor.pm:139:152839531411090] editor[1|1] json_query : returned 1 result(s) [2018-06-07 11:17:43] open-ils.vandelay [INFO:1193:CStoreEditor.pm:139:152839531411090] editor[1|1] request en-CA open-ils.cstore.j |
| 14:20 |
kmlussier |
jihpringle++ |
| 14:21 |
jihpringle |
I don't know if we have libraries who actually uses it, but that's what we have listed for its possible uses |
| 14:21 |
littlet |
jihpringle++ |
| 14:21 |
sandbergja |
jihpringle++ |
| 14:21 |
sandbergja |
I will just take Sitka's documentation then. :-) |
| 14:22 |
sandbergja |
And berick, feel free to let me know if you think of additional use cases that should be included in the docs. |
| 14:22 |
jihpringle |
please do :) |
| 14:24 |
csharp |
Dan-O: that's all normal - look for anything with "ERR" |
| 14:24 |
csharp |
Dan-O: or "WARN", maybe, though with what you're seeing, probably "ERR" |
| 14:26 |
Dan-O |
csharp: yeah that's what I thought. I don't have an warnings logs. |
| 14:27 |
Dan-O |
csharp: I'll double check. |
| 14:28 |
jeffdavis |
Jaswinder: That looks fine to me, assuming services are running properly and the row you're retrieving from the myschema.digital_services table has a value in the id column. Sorry I don't have any suggestions, maybe someone else will have some ideas or see something I missed. :( |
| 14:28 |
berick |
sandbergja: will do |
| 14:31 |
Dyrcona |
So far, looks like the fix for bug 1774703 is worse than the initial bug. |
| 14:31 |
pinesol_green |
Launchpad bug 1774703 in OpenSRF "Websockets processes locked at 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1774703 |
| 14:32 |
Dyrcona |
Now, we're also seeing bug 1773249, which we apparently weren't seeing yesterday. |
| 14:32 |
pinesol_green |
Launchpad bug 1773249 in Evergreen 3.0 "Retrieving copy templates in web client can result in NOT CONNECTED errors" [Undecided,Confirmed] https://launchpad.net/bugs/1773249 |
| 14:32 |
|
stephengwills joined #evergreen |
| 14:35 |
sandbergja |
jihpringle: Is that link generated from https://github.com/BCLibCoop/acq-manual? I was trying to find who I should credit in the git commit, but I can't find that specific language or image in github. |
| 14:37 |
jeffdavis |
Dyrcona: where was your OpenSRF at before last night's update? Did you have the fixes for bug 1744158 and bug 1746577 already? |
| 14:37 |
pinesol_green |
Launchpad bug 1744158 in OpenSRF "osrf_websocket_translator send requests to the bit-bucket" [Medium,Fix released] https://launchpad.net/bugs/1744158 |
| 14:37 |
pinesol_green |
Launchpad bug 1746577 in OpenSRF "Websocket translator responder thread loops on broken jabber socket" [Medium,Fix released] https://launchpad.net/bugs/1746577 |
| 14:38 |
Dyrcona |
jeffdavis: I had rel_3_0 checked out and applied berick's branch to rel_3_0. |
| 14:38 |
Dyrcona |
jeffdavis: It was a fresh pull. |
| 14:39 |
jeffdavis |
At Sitka we were somewhere between OpenSRF 3.0.0 and 3.0.1 (we had those two fixes but not other stuff that made it into the latest release). I installed berick's branch directly last night. Still seeing spinning websockets procs and NOT CONNECTED errors but not worse than before AFAICT. |
| 14:40 |
Dyrcona |
Ours seems worse. |
| 14:40 |
Dyrcona |
I don't have numbers to back it up, though. |
| 14:41 |
Dyrcona |
We're on 3.0.1, got the Update changelog commit, at least. |
| 14:41 |
jihpringle |
sandbergja: no, that's the old version of our doc, we're still working on updating the acq manual, it would have either been me or ChristineB who added that but I can't remember which |
| 14:41 |
jihpringle |
just credit it to BC Libraries Cooperative? |
| 14:41 |
Dyrcona |
I believe we've been on that since the upgrade actually. |
| 14:41 |
sandbergja |
jihpringle: Will do |
| 14:43 |
Dyrcona |
jeffdavis: Soon as I kill one or two spinning procs, I notice another on a different brick. |
| 14:44 |
Dyrcona |
I've asked our supervisors if they think we should roll it back tonight or this weekend at the latest. |
| 14:46 |
csharp |
Dyrcona: roll back the websockets fork? |
| 14:46 |
Dyrcona |
csharp: That and possibly berick's commit to OpenSRF. |
| 14:46 |
csharp |
k |
| 14:46 |
csharp |
our spinning proc problem is not plaguing us - just an occasional annoyance |
| 14:46 |
berick |
yeah, the osrf commit probably doesn't help with the origin WS module |
| 14:47 |
berick |
probably best to revert fully back to a known state |
| 14:47 |
berick |
Dyrcona++ # testing |
| 14:47 |
csharp |
Dyrcona++ |
| 14:48 |
Dyrcona |
Hmm. There is supposed to be a dig meeting today. Was it canceled? |
| 14:49 |
jeffdavis |
I've got one spinner so far, strace shows the same constant stream of mmap/munmap that Dyrcona reported in comment #6. |
| 14:50 |
remingtron |
Dyrcona: I haven't heard a peep about it. So, canceled I guess. :) |
| 14:50 |
jeffdavis |
I've been restarting services after a few spinners gather, instead of killing individual spinning processes, fwiw. |
| 14:50 |
Dyrcona |
I've had a half-dozen of those so far. Three or four of the other, and 1 that looked like the pre-patch x32 mode/futex/segfault. |
| 14:51 |
Dan-O |
csharp: OK here's some logs |
| 14:51 |
Dan-O |
(sorry for delay) |
| 14:51 |
Dan-O |
[2018-06-07 11:13:11] /usr/sbin/apache2 [ERR :707:EX.pm:66:] Exception: OpenSRF::EX::Jabber 2018-06-07T11:13:11 OpenSRF::Transport::SlimJabber::Client /usr/local/share/perl/5.24.1/OpenSRF/Transport/SlimJabber/Client.pm:155 Jabber Exception: Could not open TCP socket to Jabber server: IO::Socket::INET: connect: Connection refused [2018-06-07 11:17:14] open-ils.actor [WARN:1185:Application.pm:624:152839531210960] open-ils.actor.con |
| 14:51 |
csharp |
Dan-O: can you paste them? http://paste.evergreen-ils.org/ |
| 14:52 |
Dan-O |
Sorry :) |
| 14:52 |
Dan-O |
http://paste.evergreen-ils.org/9162?tx=on&submit=Format+it%21 |
| 14:53 |
Dyrcona |
Dan-O: A line or two is not bad for the channel, but more than a line or two should go to a paste site, just as a rule of thumb. |
| 14:53 |
|
jlamos joined #evergreen |
| 14:53 |
miker |
first, |
| 14:53 |
Dyrcona |
And, that looks like a networking issue. |
| 14:53 |
miker |
berick++ |
| 14:54 |
Dan-O |
I'm a total IRC n00b. thanks |
| 14:54 |
csharp |
Dan-O: "no children available" looks like trouble too |
| 14:54 |
miker |
berick / kmlussier / jeffdavis: re the lf white screen patch and telling the user, I think it might be worth doing something like the "you have outstanding transactions" on the login page when we can't use lf |
| 14:54 |
Dan-O |
Yeah I think I missed something in the install |
| 14:55 |
miker |
that seems relatively low impact, and could probably be done in adjacent code by checking the lf state |
| 14:55 |
Dan-O |
Or my jabber users aren't talking properly to the opensrf |
| 14:56 |
csharp |
Dan-O: also, see this doc about log setup: https://docs.google.com/document/d/1BJ7kSr5LfPkxXRhcrYjNyPlbT9PlNFHg6zL-tyetnKA/edit |
| 14:56 |
berick |
miker: the alert? yeah, i think that makes sense. |
| 14:56 |
miker |
right. instead of putting it on every page ... I mean, you have to log in, so... |
| 14:56 |
csharp |
Dan-O: far easier to read them when they are in directories by date and logfiles are chopped up by service and hour |
| 14:56 |
Dyrcona |
Dan-O: In /openils/conf/opensrf.xml, you want to find where open-ils.supercat is configured and increase the max_children entry. |
| 14:56 |
miker |
with a link to some (perhaps translated) instructions for the time being |
| 14:57 |
* csharp |
needs to contribute this logs doc to DIG |
| 14:57 |
Dyrcona |
csharp++ and +1 to contributing to DIG. |
| 14:59 |
Dan-O |
Drycona: changed max children to 100. restarting opensrf |
| 14:59 |
Dyrcona |
Well, 100 might be overkill. :) |
| 15:00 |
csharp |
Dan-O: prolly better to edge things up - maybe start at 25 and see if the errors still happen |
| 15:00 |
Dan-O |
ha ha OK |
| 15:00 |
jeffdavis |
miker: if I login once per day every morning, my offline db gets corrupted during regular checkout/checkin in the morning, and the server goes down in the afternoon, won't I be out of luck? |
| 15:00 |
csharp |
Dan-O: *but* - those are probably not relevant to your batch import issue |
| 15:01 |
Dan-O |
csharp: all good. at least I know |
| 15:01 |
csharp |
Dan-O: search for "vandelay" or "vl" in the logs |
| 15:02 |
* csharp |
steps afk for a while |
| 15:02 |
Dan-O |
will do |
| 15:03 |
|
rlefaive joined #evergreen |
| 15:12 |
miker |
jeffdavis: you would, indeed :( ... should we show a "danger" icon that links to infor by the hamburger menu, with a tooltip? |
| 15:12 |
Dan-O |
Is this normal: http://paste.evergreen-ils.org/9175?tx=on&submit=Format+it%21 |
| 15:13 |
Dan-O |
Should it be rolling back the db? I haven't found any vandelay errors yet |
| 15:13 |
miker |
Dan-O: yes, if it's an authoritative call via cstore editor |
| 15:13 |
Dyrcona |
Dan-O: Yes, if it made a transaction for an authoritative search, and that's what it looks like. |
| 15:14 |
Dyrcona |
miker: trace is the same, so I'm assuming yes. |
| 15:14 |
miker |
background: cstore editor uses a transaction to tell any potentially-transparent PG load balancers to send the query to the primary database, to avoid stale reads |
| 15:15 |
miker |
and then rolls the transaction back, because that's cheap in PG |
| 15:15 |
Dan-O |
Cool |
| 15:15 |
miker |
cheaper than a commit |
| 15:16 |
Dyrcona |
Not sure about the first rollback, though. That could be for other reasons. |
| 15:16 |
miker |
yeah, that's another thread trace |
| 15:16 |
Dyrcona |
And, it's for permacrud, not vandelay. |
| 15:26 |
Dan-O |
OK last question on this |
| 15:26 |
Dan-O |
Do you guys follow the install instructions on http://docs.evergreen-ils.org/reorg/3.1/command_line_admin/_installing_the_evergreen_server.html? |
| 15:26 |
kmlussier |
miker / jeffdavis / berick: Thinking on this further, I would love to get ride of the white screen. At the same time, the white screen forces the user to deal with the underlying issue. What I hate most about the white screen is that it forces staff to take several steps to clear their offline database. That step doesn't go away with this fix. |
| 15:27 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Reorganizing purchase order chapter - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8ec72cc> |
| 15:27 |
Dan-O |
If so and you're stuff is working, than it really just makes sense that I re-install and make sure I follow everything 100% |
| 15:27 |
pinesol_green |
[evergreen|BC Libraries Cooperative] Docs: Adding information about activating POs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=84bdddd> |
| 15:27 |
kmlussier |
It's very easy to ignore a warning. At the moment, I'm leaning towards not fixing the white screen if the underlying problem isn't fixed. |
| 15:31 |
kmlussier |
Alternatively, the warning gives staff the time to finish up transactions during a busy period before dealing with the offline database. So I could see pros in pushing the fix. |
| 15:36 |
|
mmorgan joined #evergreen |
| 15:41 |
terran |
I have kmlussier's mixed feelings as well. Would it be feasible to keep a message somewhere on screen until the offline database is fixed? (Similarly to how the offline transactions message stays on the login screen until transactions have been handled.) |
| 15:41 |
kmlussier |
Could we add a link to the message that, when clicked, clears the offline database for them? |
| 15:42 |
berick |
kmlussier: as far as I can tell, we can't do anything to the DB because we can't connect to it. |
| 15:43 |
berick |
ideally, we could just automatically reset it |
| 15:43 |
berick |
but can't get that far |
| 16:00 |
miker |
well, we could blindly destroy a named db using the underlying api |
| 16:00 |
miker |
which might be good for the time being, actually |
| 16:01 |
miker |
kill just the Objects table (or however it's spelled) |
| 16:01 |
miker |
so that we don't flush transactions, in the worst case |
| 16:01 |
miker |
oh, and the cache timing table, too, I suppose |
| 16:02 |
miker |
but lovefield may get angry about having some but not all tables ... not sure about that OTTOMH |
| 16:11 |
berick |
yeah, good question |
| 16:11 |
berick |
miker: do you know if we could delete all rows instead of removing the table? using the underlying API? |
| 16:13 |
berick |
on a parallel note, I have simple PoC of running lovefield inside a web worker. (just an insert on one table for now). |
| 16:13 |
miker |
I'm sure that can be done... |
| 16:13 |
berick |
so no question we can go that route, it will just take some work |
| 16:13 |
miker |
oooo |
| 16:15 |
miker |
that could certainly help address the block list file issues (maybe that's obvious) |
| 16:15 |
berick |
yeah, i was thinking about that too. might be worth it for muliple reasons |
| 16:20 |
|
khuckins joined #evergreen |
| 16:35 |
miker |
berick: https://developer.mozilla.org/en-US/docs/Web/API/IDBObjectStore/clear fwiw |
| 16:37 |
berick |
miker++ |
| 16:38 |
miker |
so, var d = window.indexedDB.open('oneWeWantToEmpty'); d.clear(); d.close(); ... maybe? |
| 16:39 |
miker |
looks more complicated than that. start transaction, get objectstore, clear. |
| 16:39 |
miker |
but, doable |
| 16:40 |
berick |
yeah, and hopefully indexDB.open() won't croak, but I suspect it will be more durable |
| 16:43 |
Bmagic |
I have a conundrum where lost item returns are voiding the billing line items like the settings say but for some reason, some libraries are getting it done with account adjustment and others are having it done with voided='t'. Both with the same exact settings.... WTF? |
| 16:44 |
miker |
so, when an error occurs, kill everything but offline xacts and move on? should we show an indicator when that's happened, and the data needs to be reloaded? (go to patron reg page, etc) |
| 16:44 |
miker |
Bmagic: adjusted ones have payments, I'll bet... |
| 16:45 |
Bmagic |
nope, clean slate |
| 16:46 |
miker |
welp, I got nuthin. IIRC, that can happen to prevent negative balances. |
| 16:46 |
Bmagic |
yeah, still diggin, thought I would run it by yall |
| 16:47 |
jeff |
Bmagic: owning lib vs circ lib settings coming into play, or settings changed between the two actions you're comparing? other than that, what miker already said, or... hrm. |
| 16:48 |
jeff |
Bmagic: interested to hear what you find. |
| 16:48 |
Bmagic |
owning lib settings are applied when lost and I didn't think there was any other way about it |
| 16:49 |
Bmagic |
Also, I found that the history (in XUL and webby) doesn't show everything. Things that are $0 checked out LOST, then voided/adjusted are not viewable via staff client |
| 16:49 |
Bmagic |
I suppose that is by design for patron privacy |
| 16:53 |
|
mmorgan1 joined #evergreen |
| 16:54 |
Bmagic |
One theory is based upon the library settings differences. The library that gets account adjustments has circ.prohibit_negative_balance_on_lost set and the other does not |
| 16:54 |
Bmagic |
make that bill.prohibit_negative_balance_on_lost |
| 16:55 |
mmorgan1 |
Bmagic: That makes sense. |
| 16:55 |
Bmagic |
the code forks I guess basd on the answer to that DB lookup |
| 16:56 |
mmorgan |
Prohibiting negative balances uses account adjustments instead of voids. |
| 16:56 |
Bmagic |
yep, that was it |
| 16:57 |
Bmagic |
the library setting bill.prohibit_negative_balance_on_lost made it work with account adjustment instead of voided='t' |
| 16:57 |
kmlussier |
Bmagic: Also, voided transactions have never show in bill history. Account adjustment should. |
| 16:57 |
kmlussier |
s/show/shown |
| 16:58 |
Bmagic |
I see, adding this setting for the library should force the code to start doing account adjustments instead of voiding which will give them what they want "cleaner looking bills" and the ability to see the history. Thanks yall! |
| 16:59 |
kmlussier |
I don't know if "cleaner looking bills" is an accurate description of what happens with account adjustments, but I'm happy that you're happy. :) |
| 17:00 |
Bmagic |
I agree, and I agree |
| 17:00 |
mmorgan |
If you're only prohibiting negative balances on Lost, that may indeed result in cleaner looking bills. |
| 17:01 |
|
jvwoolf left #evergreen |
| 17:01 |
mmorgan |
It's the adjusted overdue charges we find are, well, not particularly clean. |
| 17:01 |
Bmagic |
This particular library doesn't charge overdues |
| 17:01 |
mmorgan |
In that there can be a *LOT* of them. |
| 17:01 |
mmorgan |
That's the ideal situation! :) |
| 17:10 |
|
mmorgan left #evergreen |
| 18:08 |
|
idjit joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:09 |
|
stephengwills joined #evergreen |
| 19:43 |
jeffdavis |
berick++ # various good stuff |
