| 01:12 |
|
bdljohn joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:29 |
|
yar_ joined #evergreen |
| 07:01 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 08:36 |
JBoyer |
and finally records: delete from biblio.record_entry where id > 0; |
| 08:37 |
JBoyer |
(Normally you would want to use database transactions when using things like insert, update, or delete, but if you're trying to delete everything anyway it's not such a big deal.) |
| 08:37 |
JBoyer |
does that help? |
| 08:38 |
RMiller |
Testing it now! |
| 08:39 |
JBoyer |
Since I didn't know where you were comfort-wise I tried to make it easy to follow, hopefully that didn't come across condescending. :) |
| 08:39 |
RMiller |
I'm an English teacher fumbling around. You cannot condescend too low :) |
| 08:42 |
RMiller |
The first two returned "DELETE 0" pretty quickly, and the third one is... still... thinking... Does that sound normal? |
| 12:16 |
mmorgan |
We see log entries like this: 2019-01-18 11:02:24 brick2 open-ils.vandelay: [WARN:22569:Application.pm:624:1547827174572487] open-ils.vandelay.bib.process_spool: no mapping found for [0xCC] at position 5 in GarciÌ<U+0081>a Lorca, Federico,g0=ASCII_DEFAULT g1=EXTENDED_LATIN at /usr/share/perl5/MARC/Charset.pm line 308. |
| 12:16 |
mmorgan |
Anyone else seen something similar? |
| 12:26 |
|
sandbergja joined #evergreen |
| 12:27 |
sandbergja |
Bmagic: Our branch librarian is interested in testing your fix to bug #1741299 |
| 12:27 |
pinesol |
Launchpad bug 1741299 in Evergreen "DYMO LabelWriter 450 Turbo Hatch Label print fails with margin error" [Undecided,Confirmed] https://launchpad.net/bugs/1741299 - Assigned to Blake GH (bmagic) |
| 12:27 |
Bmagic |
great! |
| 12:27 |
sandbergja |
I'm not very familiar with Hatch, though. Would we need to use a test server with that Evergreen branch enabled? |
| 12:28 |
Bmagic |
the changes to Evergreen are very very small |
| 12:28 |
sandbergja |
And would we have to compile Hatch ourselves? And if so, can it co-exist with Hatch installed from the Chrome store? |
| 12:28 |
Bmagic |
you could edit the single tt2 file manually without having to merge the branch, etc |
| 14:03 |
jvwoolf |
JBoyer: Yes! |
| 14:08 |
JBoyer |
Ooh, the low-impact version would be a new view that only pulls things out of acn where label_class = dewey... Now I'm very interested in playing with this. |
| 14:16 |
|
beanjammin joined #evergreen |
| 14:24 |
csharp |
JBoyer++ |
| 14:25 |
csharp |
I'd be happy to work with you on that (or at least test whatever you come up with) after the dust settles from this weekend's upgrade |
| 14:31 |
JBoyer |
csharp++ |
| 14:31 |
JBoyer |
Good luck! We've been enjoying 3.2 so far. :) |
| 14:36 |
csharp |
thanks - all looks good |
| 15:43 |
miker |
mmorgan: that sounds a lot like (and, based on your error paste, looks like) badly encoded records. specifically, marc8 encoded records. is that possible? |
| 15:44 |
|
beanjammin joined #evergreen |
| 15:44 |
miker |
as in, the xml related code thinks its dealing with utf8 data, but it's marc8 |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:34 |
|
yboston joined #evergreen |
| 16:42 |
bshum |
Happy Friday everyone, and good luck to all the upgrading Evergreeners this weekend :) |
| 16:42 |
bshum |
I'll be excited to see your shiny upgraded catalogs on Tuesday :) |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
bdljohn joined #evergreen |
| 11:50 |
|
sandbergja joined #evergreen |
| 11:58 |
|
khuckins joined #evergreen |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:13 |
JBoyer |
gmcharlt, depending on how far you've made it looking into bug 1805856 you might want to load the branch I referenced in the latest comment before testing further. |
| 12:13 |
pinesol |
Launchpad bug 1805856 in Evergreen "WebClient: would like certain results to open in a new tab" [High,Confirmed] https://launchpad.net/bugs/1805856 - Assigned to Galen Charlton (gmc) |
| 12:14 |
gmcharlt |
JBoyer: thanks for the heads-up |
| 12:15 |
sandbergja |
JBoyer: thanks for the testing and correction! |
| 12:15 |
sandbergja |
JBoyer++ |
| 12:15 |
JBoyer |
sandbergja++ |
| 12:15 |
JBoyer |
Thanks for putting it out there to test! |
| 12:23 |
mmorgan |
Just mentioning I added my signoff branch to bug 1806709 |
| 12:23 |
pinesol |
Launchpad bug 1806709 in Evergreen 3.2 "Add Billing History grid persist-key to server-side db settings" [High,Confirmed] https://launchpad.net/bugs/1806709 |
| 12:29 |
|
Christineb joined #evergreen |
| 13:58 |
csharp |
in this case I changed a digit of day phone and clicked Save |
| 13:58 |
Dyrcona |
Were you trying to change the usrname? |
| 13:58 |
csharp |
no |
| 13:58 |
berick |
if anyone wants to test/merge: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/patron-create-load-js-errors |
| 13:59 |
berick |
hm, no trouble saving modified patrons here |
| 13:59 |
berick |
in master |
| 14:00 |
csharp |
berick++ # your fix stopped the console errors - thanks |
| 14:02 |
Dyrcona |
csharp: Somehow, you're ending up in the code to create a new patron. |
| 14:02 |
JBoyer |
I was about to be confused as to how that usrname check could possibly work, but then I noticed that it's in _add_patron... So something about an isnew check (maybe not the ones berick fixed?) seems to be failing somewhere. |
| 16:30 |
Bmagic |
sheesh |
| 16:30 |
Bmagic |
it works as ejabberd |
| 16:30 |
bshum |
Well "sudo" doesn't come with Debian right? |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:30 |
bshum |
You'd have to add sudo as a package prereq or something for the blind followers :) |
| 16:31 |
Dyrcona |
Um, I get sudo by default. |
| 16:31 |
bshum |
Maybe it's an old Debian problem |
| 01:25 |
|
beanjammin joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:56 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:49 |
|
bdljohn joined #evergreen |
| 12:25 |
|
yboston joined #evergreen |
| 13:01 |
|
bdljohn joined #evergreen |
| 13:08 |
|
khuckins joined #evergreen |
| 13:45 |
gmcharlt |
has anybody had an opportunity to test the OpenSRF 3.1 beta? |
| 14:01 |
Dyrcona |
No, but I've been using OpenSRF master for a while. |
| 14:02 |
Dyrcona |
including updating my VMs this week for some light weight work testing things for my conference presentation. |
| 14:09 |
JBoyer |
I was going to say no but upon actually bothering to look, I've been running master in production for a while now. Haven't given proper attention to any specific features beyond websocketd support though. |
| 14:15 |
|
yboston joined #evergreen |
| 14:30 |
|
khuckins_ joined #evergreen |
| 14:58 |
* berick |
thinks the answer is probably yet |
| 14:58 |
berick |
er, yes |
| 15:01 |
pinesol |
[evergreen|Cesar Velez] LP#1737800 - add delete action to pending patrons - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5d52073> |
| 15:03 |
phasefx |
gmcharlt: fwiw, 3.1 beta passed qa tests and my smoketest with a dev system |
| 15:26 |
Dyrcona |
I'll push bug 1801998 in the interest of getting it in before tomorrow's releases, if they're still on. Last that I heard they were, but haven't heard anything since last week. |
| 15:26 |
pinesol |
Launchpad bug 1801998 in Evergreen 3.2 "Deprecate Hatch storage for 3.2" [Medium,Confirmed] https://launchpad.net/bugs/1801998 |
| 15:29 |
pinesol |
[evergreen|Bill Erickson] LP#1801998 Deprecate Hatch for data storage - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ec3ce4b> |
| 15:33 |
Dyrcona |
It would be good if someone looked at bug 1803734 before tomorrow. |
| 15:33 |
pinesol |
Launchpad bug 1803734 in Evergreen 3.2 "edi_order_pusher.pl blindly pushes ancient orders" [Critical,Confirmed] https://launchpad.net/bugs/1803734 |
| 15:34 |
Dyrcona |
And bug 1806709 |
| 15:34 |
pinesol |
Launchpad bug 1806709 in Evergreen 3.2 "Add Billing History grid persist-key to server-side db settings" [High,Confirmed] https://launchpad.net/bugs/1806709 |
| 15:58 |
|
jvwoolf1 joined #evergreen |
| 16:06 |
|
khuckins__ joined #evergreen |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:38 |
|
hbrennan joined #evergreen |
| 16:44 |
hbrennan |
bshum: FYI autogen didn't solve the "unclickable item barcode" issue :( |
| 16:44 |
hbrennan |
but diving in deep, there's a xul reference in there |
| 17:04 |
bshum |
Speaking from my own opinion, fixing webby issues in previous releases is a pain :) |
| 17:04 |
bshum |
Fixing them in current ones isn't much better either. |
| 17:05 |
bshum |
If it's not broken for others on 3.1 or 3.2, it's community-advisable to just say "plan your next upgrade" |
| 17:05 |
hbrennan |
We're building a test of 3.1.something this week |
| 17:05 |
hbrennan |
It's not even broken on 3.0.9, the closest I could survey |
| 17:06 |
hbrennan |
Literally no one has this issue, which is why I went in the direction that it must be us |
| 17:06 |
bshum |
Yeah :( |
| 17:06 |
bshum |
I hate it when that happens :) |
| 17:06 |
hbrennan |
Instead, it looks like it must be 3.0.5 |
| 17:07 |
hbrennan |
I'm too excitable. I should probably stop reading release notes. They promise so much fun and new. |
| 17:12 |
bshum |
New is always better. |
| 17:12 |
hbrennan |
Except when it's not. :) |
| 17:12 |
bshum |
When it was up to me, life on the bleeding edge was the only way to go |
| 17:12 |
|
mmorgan left #evergreen |
| 17:12 |
bshum |
But I was more in-tune with the development then |
| 17:12 |
bshum |
So it was easier to know where the mines were going to be |
| 17:13 |
bshum |
I don't get to test as much as I'd like to, now. |
| 17:13 |
hbrennan |
Well thankfully we can still run the xul client. Which is why this has been on my backburner for a while. |
| 17:13 |
hbrennan |
But now I'm leaving my position and need to push up web training |
| 17:13 |
bshum |
It makes me wonder if maybe it's a customization issue |
| 08:44 |
|
mmorgan joined #evergreen |
| 09:13 |
JBoyer |
Dyrcona, If you have a couple minutes for Overdrive API questions I have a couple. (Mostly what needed to be requested for CW/MARS' setup, not low level stuff) |
| 09:14 |
Dyrcona |
JBoyer: Go ahead. |
| 09:15 |
JBoyer |
I was looking at the APIs we have access to (LIB, META, AVAIL, and SRCH) and I have an updated and hand-tested api secret, but no part of the Ebook API displays anything in the logs. Did you request additional APIs or have to do anything special to get things working there? |
| 09:16 |
JBoyer |
(hand-tested as in I can throw the secret at curl and get an oauth bearer token back, I haven't done much else) |
| 09:17 |
Dyrcona |
Yes. Let me check. |
| 09:20 |
Dyrcona |
You need to have Client and Patron authenticaton API access. |
| 09:21 |
Dyrcona |
BTW, where do you see the list of APIs that you have access to? I'm not seeing that in the member center on the developers' site. |
| 12:47 |
Bmagic |
Since it's not officially recognized in LOC, it's the wild west, and you/catalogers can decide how to catalog playaways. Our catalogers decided it needed to have two 007's and some other stuff. Then you define that in the Evergreen ILS, call it playaway. Then create an icon for it with the same name |
| 12:48 |
Bmagic |
the icon/picture file needs to be located in the same folder as the rest of the picture files. The naming convention needs to match the name of the format (but all lowercase) as defined in the ILS |
| 12:49 |
Bmagic |
and finally.. reingest |
| 12:49 |
Bmagic |
you need only reingest a test record for troubleshooting before you go and reingest the whole database |
| 12:53 |
nfburton |
Would I be able to see your tree for the Format Icon? |
| 12:54 |
Bmagic |
yeah, let me see if I can get a screenshot |
| 12:54 |
nfburton |
Thanks |
| 13:12 |
nfburton |
Sounds good thanks |
| 13:18 |
|
yboston joined #evergreen |
| 14:31 |
|
jvwoolf joined #evergreen |
| 14:36 |
csharp |
khuckins_: we were just testing your fix for bug 1777677 and hit a snag - if I'm a non- |
| 14:36 |
pinesol |
Launchpad bug 1777677 in Evergreen "Test notification method" [Wishlist,New] https://launchpad.net/bugs/1777677 |
| 14:37 |
csharp |
"admin" user, I am prompted with a perm override box for OPAC_LOGIN even though my user has that perm at the proper level |
| 14:37 |
csharp |
gonna see if I can get that working, but wanted you to know (I also update the bug report) |
| 14:38 |
csharp |
s/update/updated/ |
| 14:50 |
Bmagic |
nfburton: it looks like the SMD stuff is stock in config.marc21_physical_characteristic_type_map |
| 15:02 |
jeff |
csharp: was the user you were testing as a user with super_user = true set? |
| 15:02 |
csharp |
I think I may have a handle on the problem. It's possible that the "home_ou" attribute is not being dereferenced "enough" (obviously not conversant in Perl to this level) |
| 15:02 |
jeff |
csharp: can you see what arguments were being passed to open-ils.actor.event.test_notification? |
| 15:02 |
csharp |
jeff: the original testers were superusers and that works perfectly |
| 15:03 |
jeff |
and once that's fixed, there's some other permissions-related flaws which would need to be addressed before that's tested and merged. |
| 15:03 |
csharp |
but a non-superuser with OPAC_LOGIN set still doesn't see it |
| 15:03 |
csharp |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm;h=f8aa7491bf1ff8d097229c484a26201b1a84c1b4;hb=refs/heads/user/khuckins/lp1777677-test-notification-method#l4231 |
| 15:04 |
csharp |
that's the sub it's using and I think $$args{home_ou}) on line 4241 is the problem |
| 15:04 |
jeff |
it's because a user with super_user = true (which should probably be deprecated) gets TRUE returned for permission checks on non-existent org unit contexts. |
| 15:04 |
csharp |
I'm not great at using Data::Dumper, but it comes back as Fieldmapper::actor::org_unit=ARRAY(0x5b40070) |
| 15:05 |
csharp |
ah - makes sense |
| 15:05 |
csharp |
er... |
| 15:05 |
jeff |
oh. |
| 15:06 |
csharp |
not showing the args in the console, no |
| 15:06 |
jeff |
is this in place on a test system i can log into, or would i need to install the branch to get that? |
| 15:06 |
JBoyer |
I would wonder how well it works if that line is just thrown away. I barely remember when a perms check came up for that and the question was basically "What's something that everybody has?" which to me sounds a lot like |
| 15:07 |
JBoyer |
"Maybe we don't need to gate this one" |
| 15:07 |
csharp |
jeff: let me fix the SSL cert on it and I'll let you it (it's a concerto server) |
| 15:13 |
khuckins |
home_ou is passed in for the sake of checking the permission, so if we drop the OPAC_LOGIN check, that should probably be dropped as well |
| 15:14 |
khuckins |
csharp++ jeff++ Drycona++ JBoyer++ |
| 15:14 |
Dyrcona |
khuckins: Any reason for checking for OPAC_LOGIN? |
| 15:15 |
jeff |
Just to be clear, the status of this is that it is not currently included in any released or reployed Evergreen install, other than perhaps a test install with either no live data or no ability for non-trusted individuals to log in? :-) |
| 15:16 |
* Dyrcona |
thinks its on our training server where we may have looked at it, but yeah. :) |
| 15:16 |
khuckins |
Early on on the lp ticket it was suggested to have a permissions check to avoid potential abuse, initially using the UPDATE_USER permission, then brought down to OPAC_LOGIN when realizing users should be using this as well as staff |
| 15:16 |
khuckins |
But in retrospect any user who's going to be able to access that API call would be logged in |
| 15:19 |
Dyrcona |
CStoreEditor->allowed could be made smarter, i.e. to check if it got an object or an int and then derefence the id if got an object. Some other places make similar checks. |
| 15:20 |
jeff |
and if my quick scan of the requirements is correct, you're going to want to checkauth, but then instead of just checking for OPAC_LOGIN or skipping a perm check, you'll want to verify that the user is the same as the target, OR if the user is different from the target, that the user has an appropriate staff permission at the right level. |
| 15:21 |
Dyrcona |
An "appropriate permission"... VIEW_USER perhaps? |
| 15:21 |
jeff |
the trouble with the code as currently written is that it permits any valid logged in user to send test notifications to anyone, just by supplying a value for "target" |
| 15:21 |
jeff |
Dyrcona: originally it was UPDATE_USER |
| 15:21 |
|
aabbee left #evergreen |
| 15:21 |
|
aabbee joined #evergreen |
| 15:22 |
Dyrcona |
Well, that makes sense if the test is done in conjunction with changing the notification method's value. |
| 15:22 |
Dyrcona |
jeff++ |
| 15:23 |
jeff |
Also, it allows a wider than intended array of events to be fired. |
| 15:24 |
jeff |
by passing arbitrary values as event_def_type -- though it looks like it will only pass an (arbitrary!) user object to $U->fire_object_event |
| 09:13 |
|
yboston joined #evergreen |
| 09:33 |
|
aabbee joined #evergreen |
| 09:48 |
|
dkyle1 joined #evergreen |
| 10:01 |
csharp |
miker: I'm looking to put your branch for bug 1749475 on our 3.2.2 test server... |
| 10:02 |
pinesol |
Launchpad bug 1749475 in Evergreen "wishlist: Improved email and printing from the OPAC" [Wishlist,New] https://launchpad.net/bugs/1749475 |
| 10:02 |
csharp |
my concern is the change to the eg2 stuff - will that require a rebuild of the ang6 stuff? |
| 10:02 |
csharp |
git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=f882dae5c875ce11f8cdeff046ddb1928af7c4fd is the commit in question for others possibly interested |
| 13:02 |
bshum |
If it's the latter, I agree with csharp that it doesn't seem any of the merged code seems to touch anything XUL related |
| 13:02 |
mmorgan |
csharp: Hmm. I'll look at that again, looked to my untrained eye like it was in the right places to apply to xul, too. |
| 13:02 |
* mmorgan |
thought it was using the TPAC place hold. |
| 13:02 |
bshum |
The XUL client has two place hold places if I remember right (and I might not, because it's been a few years) |
| 13:09 |
bshum |
Yeah the only place where "circ.staff_placed_holds_fallback_to_ws_ou" gets used is in that eframe.js from webstaff side. |
| 13:09 |
bshum |
I don't see it in the opac js file that was changed too |
| 13:09 |
bshum |
So that means it probably doesn't affect the behavior in TPAC place hold |
| 13:10 |
bshum |
Though now I'm not sure |
| 13:10 |
* bshum |
doesn't have any 3.1 systems to test with :D |
| 13:12 |
Dyrcona |
We reverted the patch that introduced the change in behavior to our XUL client when upgrading to 3.0. I'll see if I can find the commit. |
| 13:12 |
mmorgan |
We've been reverting the changes from bug 1167541 for the past couple releases, by just commenting out the changes to eframe.js and staff.js. But those changes have, well, changed. |
| 13:12 |
pinesol |
Launchpad bug 1167541 in Evergreen 2.11 "Pickup library defaults to Home OU of staff, instead of patron when placing holds" [Medium,Fix released] https://launchpad.net/bugs/1167541 |
| 00:11 |
|
Christineb joined #evergreen |
| 01:03 |
|
beanjammin joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:04 |
|
dkyle2 joined #evergreen |
| 06:34 |
|
jamesrf joined #evergreen |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 10:38 |
|
jamesrf joined #evergreen |
| 10:40 |
Bmagic |
stephengwills: Chrome/Firefox both seem to work and work well. When it comes to the Hatch software, Chrome was* the only browser that had the Hatch extension, but now thanks to csharp and others, FF has it available in the add-on's store |
| 10:42 |
|
khuckins_ joined #evergreen |
| 10:42 |
stephengwills |
thanks…my tests seem to be working as well. I just wanted to double check. |
| 10:44 |
berick |
we officially support chrome and ff |
| 10:44 |
berick |
hatch still needs a little bit of love for FF, though - some pending LP's |
| 10:48 |
stephengwills |
i was just on a conf call where one of my LibDirs told the group not to ue firefox because it was unsupported. I didn’t want to jump in without this checkin. thanks all, as usual. ++ |
| 10:52 |
berick |
ideally, the other browsers will catch up, but yeah for now Chrome is the path of least resistence, but we also support FF |
| 10:57 |
* stephengwills |
puts up his thumb and pokes himself in the eye. |
| 11:03 |
Dyrcona |
Speaking of Google.... Do we have a community calendar with the EOL dates for the releases on it? |
| 11:26 |
Dyrcona |
berick++ for Lp 1810802. I swear I tested that, but guess I didn't. |
| 11:26 |
pinesol |
Launchpad bug 1810802 in Evergreen "Database org_top() function upgrade script errors" [High,New] https://launchpad.net/bugs/1810802 - Assigned to Jason Stephenson (jstephenson) |
| 11:31 |
pinesol |
[evergreen|Bill Erickson] LP1810802 org_top() SQL upgrade repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eaca9cd> |
| 11:37 |
berick |
Dyrcona++ |
| 12:05 |
|
mmorgan joined #evergreen |
| 12:05 |
|
sandbergja joined #evergreen |
| 12:22 |
Dyrcona |
Speaking of db upgrades... It would be great if Lp 1806709 could go in before next week's update releases. |
| 12:22 |
pinesol |
Launchpad bug 1806709 in Evergreen 3.2 "Add Billing History grid persist-key to server-side db settings" [High,Confirmed] https://launchpad.net/bugs/1806709 |
| 12:37 |
|
khuckins_ joined #evergreen |
| 12:40 |
|
beanjammin joined #evergreen |
| 12:47 |
|
beanjammin joined #evergreen |
| 13:41 |
|
khuckins_ joined #evergreen |
| 15:13 |
|
khuckins joined #evergreen |
| 15:56 |
|
jvwoolf joined #evergreen |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:11 |
|
mmorgan left #evergreen |
| 17:31 |
|
jvwoolf joined #evergreen |
| 22:36 |
|
beanjammin joined #evergreen |
| 15:10 |
phasefx |
welcome |
| 15:13 |
phasefx |
hrmm, so some instances of stretch seem to require use of /etc/init.d/ in places instead of systemctl :-/ |
| 15:14 |
berick |
phasefx: apache2ctl-websockets should work universally |
| 15:15 |
phasefx |
berick++ in this most recent case, it was ejabberd surprising me |
| 15:15 |
phasefx |
what do you guys think of this look/layout for the live tester? http://testing.evergreen-ils.org/~live/ |
| 15:16 |
bshum |
phasefx++ # neat :) |
| 15:16 |
phasefx |
will put a shortuct at the top to indicate/jump to the first failure |
| 15:17 |
bshum |
berick: phasefx: that step's in the OpenSRF readme right? It probably hasn't been touched since we introduced apache2-websocket |
| 15:18 |
phasefx |
will probably hyperlink to sections in the install instructions as well |
| 15:20 |
bshum |
Makes sense to update the instruction to be distro specific, if necessary. Or just use the one berick suggests. |
| 15:20 |
bshum |
That's assuming we keep it as option #1 over the new websocketd :D |
| 15:25 |
pinesol |
News from qatests: Failed configuring ejabberd <http://testing.evergreen-ils.org/~live/test.15.html#2019-01-03T15:08:51,961120528-0500 -0> |
| 15:25 |
pinesol |
News from qatests: Failed creating jabber users <http://testing.evergreen-ils.org/~live/test.16.html#2019-01-03T15:08:51,970774027-0500 -2> |
| 15:25 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.18.html#2019-01-03T15:08:51,980501558-0500 -4> |
| 15:25 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.20.html#2019-01-03T15:08:51,990116639-0500 -6> |
| 15:25 |
pinesol |
News from qatests: Failed test opensrf <http://testing.evergreen-ils.org/~live/test.21.html#2019-01-03T15:08:51,999747537-0500 -8> |
| 15:25 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-01-03T15:08:52,009366939-0500 -10> |
| 15:38 |
blongwel |
In 3.1.7 with duplicate tcn (from 035) on import we are seeing long tcns generated with all isbns in the record. Is this expected behavior or a bug? |
| 15:55 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-01-03T15:48:20,626585144-0500 -0> |
| 16:04 |
|
gsams_ joined #evergreen |
| 16:06 |
|
gsams_ joined #evergreen |
| 16:25 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:45 |
mmorgan |
Anybody getting reports from patrons using Comcast as an email provider that they are not getting their Evergreen notifications? |
| 16:45 |
csharp |
not here that I've heard |
| 16:46 |
mmorgan |
We're getting lots of reports, but see no problems in our email logs, and we've successfully seen messages delivered to staff members who have Comcast email. |
| 16:50 |
csharp |
email providers are getting stricter about enforcing that - but I would expect problems with Gmail and Yahoo too |
| 16:51 |
mmorgan |
We send through gmail and those logs indicate those messages are all being delivered to Comcast servers. We're only seeing the usual occasional bounce when a user doesn't exist. |
| 16:52 |
csharp |
yeah - the logs on your end will look fine - the receiving server accepts the mail in most cases, then trashes it on their end |
| 16:54 |
mmorgan |
Tests we've done work fine. Hold notifications, etc. appear in the Comcast inboxes of the patrons, who just happen to be staff members who tested with their Comcast email addresses. |
| 16:54 |
csharp |
oh - hmm |
| 16:55 |
mmorgan |
But we've had a large number of reports from patrons that they're not getting messages in the past two weeks. |
| 16:55 |
csharp |
we have a standard line of "all looks correct on our end - please contact your email provider" (sometimes including the log message on our end showing successful receipt |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 09:24 |
|
stephengwills joined #evergreen |
| 10:57 |
|
jvwoolf joined #evergreen |
| 11:00 |
stephengwills |
Is it reasonable for me to upgrade EG database on a test server and copy the database to a production server and expect the prod version to attach to it and work properly? (as opposed to upgrading the prod database in place?) |
| 11:02 |
stephengwills |
i’m having profound index problems this morning and want to start by checking the basic premise of my workflow. |
| 11:08 |
|
khuckins joined #evergreen |
| 11:49 |
|
terran joined #evergreen |
| 11:54 |
bshum |
stephengwills: That makes sense to me. "Production" is basically whichever database you designate as the main one used by your Evergreen app servers. |
| 11:54 |
bshum |
It doesn't have to be the same actual database server, etc. |
| 11:55 |
bshum |
of course, once people start using said database, it'd be hard to go back and use another DB copy again |
| 11:55 |
bshum |
Meaning copying transactions, etc. between databases, I wouldn't advise that |
| 11:55 |
bshum |
But basically any app server, you can edit the opensrf.xml config to point at any database you want |
| 11:56 |
bshum |
In theory. :) |
| 11:57 |
bshum |
In the past, I've "upgraded" databases by building a whole fresh server and new PG version, and then took a db-dump copy of our prod database and restored it into the fresh system. |
| 11:57 |
bshum |
I just liked doing the dump/restore PG approach rather than doing in-place pg_upgrade. But to each their own. |
| 11:59 |
bshum |
Of course, your "test server" becoming the new production, you'll want to make sure the hardware is comparable, tuning is done, security in place, etc. |
| 11:59 |
bshum |
Good luck with everything. Be curious to hear how it all turns out later. :) |
| 13:08 |
|
hbrennan joined #evergreen |
| 14:18 |
stephengwills |
in 3.1.8 I imported a record via z39.50, added a 250 field and clicked save. There was no UX feedback that I was successful until I click on MARC View and saw that my 250 field has, indeed been added. is this a known problem? |
| 16:51 |
|
khuckins_ joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-19T04:52:32,076196669-0500 -0> |
| 07:05 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
bdljohn joined #evergreen |
| 09:51 |
|
yboston joined #evergreen |
| 09:54 |
RMiller |
Hi, quick Evergreen install question. In step 11 of the Evergreen install, it tells me to copy the opensrf_core.xml file again, then modify it the same way I did in OpenSRF setup |
| 09:55 |
RMiller |
Since I only installed OpenSRF for the purposes of using Evergreen, do I need to do this step? |
| 09:56 |
JBoyer |
RMiller, yeah, the one included in OpenSRF only has a couple testing services defined, the example included with Evergreen defines the other services required by Evergreen and a couple testing services. |
| 09:56 |
RMiller |
So the Evergreen setup replaced that example file with something more thorough? |
| 09:57 |
RMiller |
It's the same location and filename, so that just seemed weird |
| 09:58 |
|
bwicksall joined #evergreen |
| 14:15 |
jeff |
if your backend systems are not sharing a memcached instance, then the session token from one would not be considered valid on another. |
| 14:16 |
jeff |
so unless you have taken some extraordinary steps to ensure that requests by a given client are only ever serviced by a specific backend host, you're going to run into issues where it appears that you are not logged in. you may never be able to successfully log in and could loop, like you're seeing. |
| 14:16 |
stephengwills |
ok. makes sense. |
| 14:17 |
jeff |
if haproxy was connecting over http and you weren't taking other steps to inform the backend systems of the client <-> haproxy protocol being https, then you'd run into similar redirect issues because the backend systems would think the client connection was over http and try to redirect to https, looping. |
| 14:19 |
jeff |
if you rule out those two issues and are still having problems with a "fresh" client, you might consider configuring haproxy to only use a single backend system as a next troubleshooting step. |
| 14:20 |
jeff |
and by a "fresh" client, I mean you might want to clear cache and restart the web browser, or try a new incognito/private browing session to test, to rule out the possibility that the client had cached a problematic redirect, etc. often not necessary, but good to rule out... |
| 14:21 |
stephengwills |
fair. thanks will do |
| 14:21 |
jeff |
good luck! |
| 14:26 |
jeff |
another issue that we might still be susceptible to is if you've created a directory in your DocumentRoot titled "eg", or if your hostname contains (or perhaps just starts with) "staff". I should find or create bugs for those two. They're less common, but if either rings a bell for you, could be that. :-) |
| 15:29 |
|
bdljohn1 joined #evergreen |
| 16:51 |
stephengwills |
one of the hosts I am retiring was named staff but that is no longer an issue. I fixed the eg_vhost to rewrite all traffic to https and now haproxy delivers a user to one of the hosts and that user should stay put for the druation of thier session, anyway. not fool proof but it got me past that issue. I’ll look into shared memcache after dinner. thanks for the suggestions. |
| 16:57 |
|
stephengwills left #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-19T16:53:56,389847953-0500 -0> |
| 17:33 |
|
stephengwills joined #evergreen |
| 18:17 |
|
nfBurton joined #evergreen |
| 20:27 |
|
sandbergja joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-18T04:52:13,436767412-0500 -0> |
| 07:02 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:42 |
|
bdljohn joined #evergreen |
| 09:24 |
RMiller |
The passwords are in there correctly, as far as I can tell; two are inside <password> tags and two are inside <passwd> tags. Is that right? |
| 09:27 |
aabbee |
yes. the <password> tags are for router users, <passwd> tags for opensrf users. note that these do not appear in the opensrf_core.xml file in the same order that the users were created in step 11. |
| 09:28 |
RMiller |
I gave them all the same password, so the order shouldn't matter... :) |
| 09:29 |
Dyrcona |
RMiller: For testing purposes, I use "password" so I don't have to change the configuration file. |
| 09:30 |
Dyrcona |
Did you restart ejabberd after making the changes to ejabberd.yml? |
| 09:31 |
Dyrcona |
You probably could not have registered the users unless you did, though. |
| 09:32 |
RMiller |
I'm sure I did (this has been a month-long on-and-off process, long story) but I just did again, and no change. |
| 10:32 |
RMiller |
4! Hooray! |
| 10:33 |
Dyrcona |
I'm concerned about the amount of RAM. I never go with less than 4GB. You may find yourself running out once you get PostgreSQL and everything else running. |
| 10:36 |
RMiller |
Ok. It's virtualized, so I'd have to ask the IT guy for that one. Are we talking increasing swap space or just actually adding another stick of RAM or what? |
| 10:37 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Free on Ubuntu 18.04 test VM" (4 lines) at http://paste.evergreen-ils.org/14378 |
| 10:38 |
Dyrcona |
That's after having done very little, just looking up a book and editing it's information. |
| 10:38 |
Dyrcona |
Is this going to be for production use or just for testing? |
| 10:39 |
RMiller |
Production on a small scale- we're one K-12 school library. |
| 10:40 |
Dyrcona |
You'll probably want 8GB in the end. If it's virtualized, they should be able to increase the RAM rather easily, just a config change and VM restart. |
| 10:41 |
RMiller |
Ok. Thank you again for all your help! I really appreciate it |
| 16:58 |
bshum |
It's kind of like you'd have to though. In order to preserve the original displayed content vs. the new variable you'd rather be searching on |
| 16:59 |
|
khuckins joined #evergreen |
| 17:01 |
nfBurton |
I thought one would exist already. Thanks for the sanity check. |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-18T16:54:23,308313503-0500 -0> |
| 17:02 |
bshum |
It wouldn't be the first time we broke up an existing field definition into more granular pieces to achieve certain goals |
| 17:04 |
|
mmorgan left #evergreen |
| 17:54 |
|
aabbee left #evergreen |
| 11:17 |
phasefx |
Dyrcona++ |
| 11:18 |
berick |
and phasefx++ |
| 11:18 |
Dyrcona |
phasefx: What version of Pg is installed? |
| 11:18 |
berick |
building test server on ub 18? |
| 11:18 |
phasefx |
Dyrcona: PostgreSQL 9.6.10 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit |
| 11:19 |
Dyrcona |
OK. I don't recall if I've ever run the tests on Pg 9.6. |
| 11:19 |
phasefx |
berick: debian stretch, but we have or are close to having multi-server support |
| 11:20 |
phasefx |
http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.xml;h=6e3952d0b1f47e2a1898d3048ebe6153ce4da547;hb=refs/heads/collab/phasefx/eg_live_tests |
| 11:20 |
berick |
nice! |
| 11:21 |
Dyrcona |
Looks like we'll have to modify the test to accommodate 9.6 also.... |
| 11:31 |
phasefx |
right now testing.evergreen-ils.org is still running test.sh (http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test.sh;h=11d96d5b42eb05d513e6bea63d75a29983175246;hb=refs/heads/collab/phasefx/eg_live_tests), but we can eventually switch it over to and smoke test test_runner.pl http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.pl;h=4fc672529021ec2b74bcf83d69dc22bf74ff3c73;hb=refs/heads/collab/phasefx/eg_live_test |
| 11:32 |
phasefx |
then folks with commit access to the branch can just add their servers (there's an ssh pubkey for testin.evergreen-ils.org in the branch) |
| 11:33 |
Dyrcona |
phasefx: Sound interesting/useful. I'll take a look some day. |
| 11:38 |
jeff |
what keeps us using the random repository for all manner of things? would gitlab and/or something else help us get away from that practice, because it would potentially reduce the burden of creating a repo? |
| 11:38 |
jeff |
(tangent, i know) |
| 12:25 |
|
bdljohn1 joined #evergreen |
| 12:36 |
|
beanjammin joined #evergreen |
| 12:39 |
Dyrcona |
jeff: Gitlab will let you create your own repositories just by pushing to them be default. It can be done with gitolite using a wildcard repo configuration. |
| 12:42 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,428726255-0500 -0> |
| 12:42 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,450827934-0500 -2> |
| 12:42 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,472980231-0500 -4> |
| 12:47 |
dickreckard |
uhm, is there a way to list the last records added to the catalog in the staff client? |
| 13:01 |
miker |
dickreckard: in the staff client directly? hrm, probably not. but in another tab: http://sandbox-32.evergreencatalog.com/opac/extras/feed/freshmeat/opac/biblio/import/10/ |
| 13:05 |
* jeff |
notes the Apache "Found" 3xx body appended to the end of that document |
| 13:12 |
jeff |
also, if you're not logged in to the staff client in that browser when you fetch that url, if the most recent 10 bibs aren't otherwise visible in searches, you may get zero results, or more likely less than the number requested. |
| 13:14 |
jeff |
but if there are zero results you'll get an error that references record IDs, which you can then individually retrieve. |
| 13:16 |
Dyrcona |
dickreckard: What problem are you trying to solve? Do you want to see X of the most recent records you've added or just the previous one? This sounds like a potentially useful feature request. |
| 13:16 |
dickreckard |
no it's for the staff indeed |
| 13:17 |
dickreckard |
just wanted to check how the staff is doing in the test installation, and export the records that were added |
| 13:17 |
dickreckard |
so maybe make a csv with the IDs and use the batch export |
| 13:18 |
dickreckard |
cos I will need to merge the old database with the recods that were added in the test installation, into a new installation |
| 13:20 |
dickreckard |
I think a record query " * sort(create_date) #descending " solve my needs.. but indeed the last x records instead of just the 'retriev last bib record' button could be nice |
| 13:26 |
dickreckard |
also I finally solved the problem I had with vandelay batch imports.. I found the issue was that systemd creates a private /tmp folder nested inside an apache2 private folder, so it couldn't find the uploaded temporary .mrc file as it was inside the private tmp instead of /tmp. I wanted to somehow add that note somewhere, cos it would be useful to add in the documentation as from debian stretch it's the |
| 13:26 |
dickreckard |
default behavior. |
| 13:27 |
dickreckard |
I looked on launchpad and couldn't find mentions about it. so let me know if I can add notify this somewhere. |
| 13:29 |
jeff |
It might be reasonable to review changing the default value of <importer>/tmp</importer> in openils.xml.example |
| 13:31 |
Dyrcona |
dickreckard: You should be able to get marc records out of the URL that miker shared earlier. |
| 13:31 |
|
sandbergja joined #evergreen |
| 15:07 |
JBoyer |
++ |
| 15:08 |
* berick |
wonders if csharp is in the house |
| 15:08 |
berick |
in any event, I'll note that in the LP |
| 15:08 |
* Dyrcona |
was thinking we could assign testing with Firefox to csharp. :) |
| 15:08 |
JBoyer |
The thing that's primarily being tested is the Windows installer. The extension can function without changes so long as the windows bits are updated. |
| 15:08 |
gmcharlt |
ok |
| 15:08 |
gmcharlt |
so I'll take this as |
| 15:11 |
gmcharlt |
^ that one looks straightforward; I'll run it through its paces and will merge today |
| 15:12 |
gmcharlt |
the other is bug 1729610 |
| 15:12 |
pinesol |
Launchpad bug 1729610 in OpenSRF "allow requests to be queued if max_children limit is hit" [Wishlist,New] https://launchpad.net/bugs/1729610 |
| 15:12 |
gmcharlt |
which I know miker will test, but it would be nice to have additional eyes on it |
| 15:12 |
gmcharlt |
I'll write up draft release notes as well |
| 15:12 |
gmcharlt |
request chunking will /not/ make it into 3.1-beta for lack of code |
| 15:12 |
gmcharlt |
any questions? |
| 15:12 |
* miker |
hangs head in shame |
| 15:13 |
JBoyer |
Looks good, since I'm hoping to use websocketd in production soon I'll try to test those two branches too. |
| 15:14 |
|
bdljohn1 joined #evergreen |
| 15:14 |
* Dyrcona |
is using websocketd in production and it is very reliable. |
| 15:14 |
berick |
just noticed I need a better commit message on the websocketd patch... |
| 15:25 |
gmcharlt |
ok, moving on |
| 15:25 |
gmcharlt |
#topic Hatch |
| 15:25 |
|
Topic for #evergreen is now Hatch (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:26 |
berick |
I am planning to help w/ the Dymo LP, at minimum code reivew and non-Dymo testing. |
| 15:26 |
gmcharlt |
berick++ |
| 15:26 |
berick |
I don't have a Dymoe printer, alas |
| 15:27 |
berick |
so kind of like the other Hatch issue, more help testing would be appreciated |
| 15:27 |
gmcharlt |
I have one comment so far ... I dislike calling it "compatibility mode" as a printing setting |
| 15:27 |
dbwells |
We've got a million Dymos and can help with testing. |
| 15:27 |
Bmagic |
I solicited my libraries and was able to borrow one more long term. |
| 15:28 |
gmcharlt |
as ultimately that's meaningless to the user |
| 15:28 |
Bmagic |
I'm not married to the term either. |
| 15:47 |
berick |
and when it's enabled it will be clearly /other/ |
| 15:47 |
berick |
and not a replacement |
| 15:47 |
gmcharlt |
but I'm wondering if we can go so far as to also deprecate the old embedded OPAC at the same time, with a stated goal of removing it in 3.4 |
| 15:47 |
JBoyer |
+1 to having the code in core, possibly just have 2 entries in the cat menu "Search Catalog" and "Testing Catalog" or similar. |
| 15:47 |
Dyrcona |
I'd be inclined to leave it out. |
| 15:47 |
berick |
Dyrcona: well, it's already in there |
| 15:47 |
berick |
or do you mean the menu entry? |
| 15:48 |
berick |
Dyrcona: gotcha |
| 15:48 |
miker |
is it Decided(tm) that the embedded catalog must die? (sorry if that's been made clear or is obvious) |
| 15:48 |
JBoyer |
Does seem a little early to deprecate embedded tpac in 3.3, though |
| 15:48 |
berick |
it could still be easily tested even if it weren't listed in the menu, of course |
| 15:49 |
berick |
miker: that is certainly my hope, but no decisions on that have really been made. also why I wanted to raise the topic |
| 15:49 |
JBoyer |
miker, if it went up to a vote among circ staff they wouldn't think twice, as the iframe eats the shortcut keys. |
| 15:49 |
gmcharlt |
miker: in the long run, I don't think it does us much good to support two different staff OPACs (although obviously there will need to be a way to quickly open a bib in the OPAC) |
| 15:49 |
berick |
make sure I'm tilting at the correctly shaped windmills |
| 16:05 |
berick |
that's my take as well. |
| 16:05 |
miker |
gmcharlt: that's totally fair |
| 16:05 |
jeffdavis |
I think deprecating in 3.3 is too aggressive, but a soft goal of defaulting to angular OPAC in 3.4 (+ deprecating TPAC in client) is ok with me. |
| 16:06 |
gmcharlt |
I also think that it should be a bit easier than editing navbar.tt2 (or the equivalent) to make it avaialble in 3.3 for testing purposes |
| 16:06 |
gmcharlt |
YAOUS, perhaps? |
| 16:07 |
JBoyer |
A reasonable compromise; that way Library A can get their staff started early even if Library B isn't sure how this whole "online" thing is going to shake out. |
| 16:07 |
miker |
I'm mainly curious as to whether we can, or should, write an Ang egFrame component so we can make use of what's there, or will the whole catalog in the client continue to be AngJS until we switch? |
| 16:08 |
berick |
miker: as it stands, I'm making the Ang catalog jump to AngJS for anything it's not prepared to deal with |
| 16:08 |
berick |
to ease integration / testing |
| 16:09 |
berick |
e.g. it jumps to AngJS for holdings maintenance, holds lists, and a few others |
| 16:09 |
berick |
but AngJS stays within its own sphere for now |
| 16:09 |
berick |
it never jumps back to Ang (unless you use the back button) |
| 16:10 |
berick |
which as it stands would be confusing for most staff, but certainly usable / testable |
| 16:10 |
miker |
sure, that makes sense |
| 16:11 |
berick |
but to answer your questoin, I think yes, there has to be a single catalog that's the main one |
| 16:11 |
berick |
which will be angjs until it's not |
| 16:15 |
* JBoyer |
can't wait for the hip-hop remix of the discussion. |
| 16:15 |
berick |
i think that's it so far |
| 16:15 |
berick |
miker: :) |
| 16:16 |
gmcharlt |
ok, so I think to sum up, it sounds like we have |
| 16:16 |
gmcharlt |
(a) general willingness that the Ang staff OPAC be made available in 3.3 in some fashion for testing |
| 16:17 |
gmcharlt |
(b) a new shared sense of what the issues will be around when (or if) to make a full transiition to it at some point |
| 16:17 |
gmcharlt |
accurate? |
| 16:17 |
miker |
+1 |
| 16:17 |
JBoyer |
+1 |
| 16:17 |
berick |
+1 |
