Time |
Nick |
Message |
02:06 |
|
bdljohn1 joined #evergreen |
04:00 |
|
NvpkD1y7Ez joined #evergreen |
06:24 |
|
memoryno- joined #evergreen |
06:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:49 |
|
nickoe12 joined #evergreen |
07:01 |
|
agoben joined #evergreen |
07:01 |
|
lutoma6 joined #evergreen |
07:06 |
|
Dyrcona joined #evergreen |
07:10 |
|
rjackson_isl joined #evergreen |
07:40 |
|
collum joined #evergreen |
08:35 |
Dyrcona |
Bmagic: You can add "Could not launch" to your list of things to grep in the logs. |
08:37 |
Dyrcona |
Bmagic: Also "no children available" |
08:37 |
Dyrcona |
And, I seriously need to consider upping drone counts on a couple of services..... |
08:40 |
Dyrcona |
Bmagic: It turns out that "[Nn]o children available" covers my previous two suggestions with 1 regexp. |
08:40 |
|
mmorgan joined #evergreen |
08:47 |
|
rory6 joined #evergreen |
09:00 |
Dyrcona |
A propos my previous messages to Bmagic: It looks like the web staff client uses more open-ils.pcrud, open-ils.actor, and open-ils.circ drones than did XUL. |
09:01 |
Dyrcona |
It definitely uses open-ils.pcrud a lot more than XUL. |
09:01 |
Dyrcona |
I may have just needed more of the other drones all along. |
09:03 |
Dyrcona |
Going back before the upgrade to 3.0, it does appear that I should have configured more open-ils.actor drones sooner. |
09:15 |
Dyrcona |
@monologue |
09:15 |
pinesol |
Dyrcona: Your current monologue is at least 5 lines long. |
09:21 |
|
kmlussier joined #evergreen |
09:31 |
|
yboston joined #evergreen |
09:56 |
mmorgan |
Does this sound familiar to anyone? |
09:57 |
mmorgan |
I merged two bib records, the ulitmately deleted record had T and M holds. |
09:57 |
mmorgan |
The T holds moved to the Lead record as they should, but the M holds were left behind on the deleted record. |
09:57 |
mmorgan |
I couldn't find a lp bug. |
10:13 |
jeffdavis |
This is pretty weird - for the past two hours, system-wide non-staff searches have been failing with a query error: Can't call method "opac_visible" on an undefined value at /usr/local/share/perl/5.18.2/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm line 1177. |
10:14 |
Dyrcona |
mmorgan: Was the deleted record a lead record for the metarecord? |
10:19 |
|
frmus11 joined #evergreen |
10:19 |
mmorgan |
Dyrcona: You mean "master" record? I'm not sure. I don't know what the master record was before the two records were merged. |
10:22 |
kmlussier |
mmorgan: What is the master record now? If a master record is deleted, does the master for the metarecord group get changes to something that isn't deleted? |
10:26 |
|
mdriscoll joined #evergreen |
10:29 |
|
khuckins joined #evergreen |
10:35 |
mmorgan |
kmlussier: Sorry, phone call. The master record now is undeleted. I couldn't find any master records in the metabib.metarecord table that were deleted bibs. |
10:39 |
mdriscoll |
If you use a load balancer, what software are you using? We have been using pound for years but it apparently won't support websockets. |
10:40 |
Dyrcona |
mdriscoll We use ldirectord. |
10:41 |
Bmagic |
mmorgan: yeah, that happens when the two bibs being merged are not in the same metarecord. I wrote some logic in perl to solve that problem. There is a sub routine in this file: https://github.com/mcoia/mobius_evergreen/blob/master/seek_and_destroy/seek_and_destroy.pl |
10:42 |
Bmagic |
that does a bunch of retro-cleaning of the metarecord stuff. The routine is called "cleanMetaRecords" - There are some inline notes to help understand what it's doing. Starting on line 2916 or so |
10:43 |
Dyrcona |
mmorgan Bmagic: If you think the M holds should move in that case, open a Lp bug. I can see arguments for this going either way if the master record is not deleted and still has bibs left. |
10:43 |
Bmagic |
yeah, it's tricky |
10:43 |
Bmagic |
(and it's been awhile since I thought at it) |
10:44 |
* mmorgan |
is definitely looking to open a bug but wanted to make sure I wasn't missing an existing one. Holds should never be left on deleted bibs. |
10:45 |
mmorgan |
Bmagic++ I'll take a look at your metarecord roomba :) |
10:45 |
Bmagic |
roomba! ha |
10:51 |
dbwells |
jeffdavis: Did you get it figured out? Org tree related, so if you haven't changed the org tree recently, maybe a bad cache value? Looks like locale plays a role as well. |
10:54 |
|
Christineb joined #evergreen |
11:07 |
jeffdavis |
dbwells: sounds like an org unit was added this morning but isn't consistently in the org tree, even after service restart + autogen |
11:11 |
jeffdavis |
The locale-ized orgtree values in memcached ("orgtree.en-US" etc) have the new org unit, but the unlocalized one ("orgtree.") doesn't |
11:14 |
jeffdavis |
Manually deleting the bad cache entry works but I'm not sure how to prevent the same thing from happening next time an org unit is added. |
11:15 |
mdriscoll |
Dyrcona++ We used to use ldirectord. I'll take a look at it. |
11:24 |
jeffdavis |
An un-locale-ized "orgtree." cache value is used when AppUtils->get_org_tree() is called with no locale param, as happens in Application/Storage/Driver/Pg/QueryParser.pm around line 1434. I'm not sure if it's expected to fallback to a default locale. With no locale, autogen isn't smart enough to force an update of the cached unlocalized tree; perhaps OpenILS::Utils::Configure->org_tree_js() needs to delete "orgtree." fro |
11:24 |
jeffdavis |
cache in addition to "orgtree.en-US" etc. |
11:38 |
|
TriJetScud7 joined #evergreen |
11:53 |
|
idjit joined #evergreen |
11:57 |
dbwells |
jeffdavis: sounds like you nailed it. Not sure if the non-localed version is supposed to exist, but if it is, we certainly want to keep it updated. |
11:58 |
|
yboston joined #evergreen |
12:22 |
|
khuckins_ joined #evergreen |
12:36 |
|
NyanCat26 joined #evergreen |
12:47 |
|
jihpringle joined #evergreen |
12:57 |
jeffdavis |
bug 1786987 |
12:57 |
pinesol |
Launchpad bug 1786987 in Evergreen "Autogen does not refresh unlocalized org tree cache" [Undecided,New] https://launchpad.net/bugs/1786987 |
12:59 |
dbwells |
jeffdavis++ |
13:14 |
|
syncretism_mbl joined #evergreen |
13:35 |
|
cyberlard0 joined #evergreen |
14:27 |
pinesol |
[evergreen|Jane Sandberg] LP1164061: Edit authority record by database ID - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e8e7667> |
14:36 |
|
yboston joined #evergreen |
14:38 |
berick |
hoping someone with a 3.1 test server can confirm a bug. bug 1770981. |
14:38 |
pinesol |
Launchpad bug 1770981 in Evergreen "patron alert block are shown untranslated" [Undecided,New] https://launchpad.net/bugs/1770981 |
14:38 |
berick |
test is pretty simple |
14:39 |
berick |
see my last comment. |
14:40 |
berick |
https://launchpadlibrarian.net/383198926/fines-label.png -- 'PATRON OWES TOO MUCH' is my local translation on master, which works as expected. |
14:48 |
* kmlussier |
can try. |
14:53 |
kmlussier |
berick: It work for me. I'll add a comment to LP. |
14:53 |
berick |
kmlussier++ |
15:10 |
|
mmorgan1 joined #evergreen |
15:13 |
|
hbrennan joined #evergreen |
15:18 |
|
JBoyer-alt joined #evergreen |
15:27 |
|
fwilson joined #evergreen |
15:30 |
|
nope__ joined #evergreen |
16:02 |
|
mikedlr14 joined #evergreen |
16:05 |
|
mmorgan joined #evergreen |
17:04 |
|
mmorgan left #evergreen |
17:11 |
|
orliesaurus18 joined #evergreen |
17:17 |
kmlussier |
berick / khuckins_: I'm looking at bug 1744756. When I'm in the admin interface, if I click to add a Permission group, I don't see any options in the Available Entries dropdown. Do I need to do something to make a permission group appear there? |
17:17 |
pinesol |
Launchpad bug 1744756 in Evergreen "Wishlist: Custom profile group display in patron registration." [Wishlist,Confirmed] https://launchpad.net/bugs/1744756 - Assigned to Kathy Lussier (klussier) |
17:20 |
* kmlussier |
needs to run, but will check for an answer later. |
17:34 |
khuckins_ |
kmlussier just caught this, the Available Entries dropdown should be populated by any entries for any permission group not currently in the tree. On a fresh install of the branch with no entries in the tree, every permission group should be in the dropdown. Without any entries, it should have an unsubmittable <NONE> option |
17:35 |
khuckins_ |
I should say, just caught your message, will be looking at trying to replicate the issue you're running into |
17:37 |
berick |
and (I think) make sure a target tree node is selected before clicking Add |
17:41 |
khuckins_ |
If there's no target node, it should default to the root node for adding |
17:48 |
berick |
ah, cool |
18:17 |
|
sandbergja joined #evergreen |
18:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:33 |
|
salios joined #evergreen |
19:35 |
jeffdavis |
Here's a good one: Small academic library closes for the summer. A patron has overdue items accruing hourly fines but they haven't hit max fines yet when the summer closure begins. |
19:35 |
jeffdavis |
Every night, the fine generator cycles through the summer break, checking closed dates for each 1-hour period. Eventually this causes fine generation to fail for that circ (maybe due to a timeout somewhere, not sure) in a way that messes up the cstore editor object used by the fine generator. |
19:36 |
jeffdavis |
As a result, the fine generator fails on every subsequent circ, evidently because of an error trying to use that same cstore editor object. |
19:37 |
jeffdavis |
So it stops generating billings for all remaining overdues. |
19:47 |
jeffdavis |
(This is with the old fine generator; I don't know yet if fine generator v2 has the same problem.) |
20:04 |
|
milky20 joined #evergreen |
20:16 |
|
Guest32493 joined #evergreen |
20:32 |
|
crayfishx18 joined #evergreen |
20:33 |
|
tharkun0 joined #evergreen |
22:14 |
|
jhesketh18 joined #evergreen |