Time |
Nick |
Message |
00:29 |
|
dbwells_ joined #evergreen |
06:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:57 |
|
JBoyer joined #evergreen |
07:18 |
|
rjackson_isl joined #evergreen |
07:30 |
|
agoben joined #evergreen |
07:49 |
|
rlefaive joined #evergreen |
08:16 |
|
collum joined #evergreen |
08:38 |
|
tlittle joined #evergreen |
08:45 |
|
mmorgan joined #evergreen |
08:56 |
|
bos20k joined #evergreen |
09:09 |
|
jvwoolf joined #evergreen |
09:10 |
|
kmlussier joined #evergreen |
09:14 |
|
jvwoolf1 joined #evergreen |
09:25 |
mmorgan |
Has anyone successfully created a user activity type for OverDrive? |
09:26 |
|
yboston joined #evergreen |
09:28 |
mmorgan |
Documentation suggests adding a row to config.usr_activity_type with correct values for event caller, event type and event mechanism should do it, but I haven't had success. |
09:37 |
|
mmorgan left #evergreen |
09:39 |
|
Stompro joined #evergreen |
09:42 |
jeff |
@later tell mmorgan it depends on how you are handling authentication between OverDrive and the library. What method are you using? EZproxy, HTTP call, SIP2, or other? |
09:42 |
pinesol_green |
jeff: The operation succeeded. |
09:44 |
|
mmorgan joined #evergreen |
09:44 |
|
rlefaive joined #evergreen |
09:47 |
mmorgan |
jeff: we're using SIP2 |
09:48 |
|
JBoyer joined #evergreen |
09:48 |
jeff |
okay. i believe there's a variable you need to set on the sip user or institution in order to pass the activity type. |
09:49 |
jeff |
activity_who attribute on the SIP user in the SIPServer config file. |
09:52 |
mmorgan |
Ok, will check the SIPServer config file. Is just the ewho enough? |
09:53 |
jeff |
one sec. |
09:58 |
jeff |
activity_who should match the ewho value of an entry in config.usr_activity_type whose ewhat is verify and whose ehow is sip2. |
10:00 |
* jeff |
looks to see how that differs if you're validating passwords via SIP2 |
10:00 |
jeff |
are you requiring users to share their library password with OverDrive? |
10:00 |
mmorgan |
Ok, does anything need to be restarted? |
10:01 |
mmorgan |
No, users don't need a password |
10:01 |
jeff |
ah, that simplifies things. |
10:02 |
jeff |
you'll need SIPServer to notice the config change. In most cases, that means a restart of SIPServer on the host that OverDrive communicates with. |
10:02 |
mmorgan |
ok, thanks, will give it a try. running to a mtg right now |
10:02 |
mmorgan |
jeff++ |
10:03 |
|
mmorgan1 joined #evergreen |
10:24 |
jeff |
bug 1736173 |
10:24 |
pinesol_green |
Launchpad bug 1736173 in Evergreen "Document activity_who and related options for SIP user activity tracking" [Low,New] https://launchpad.net/bugs/1736173 - Assigned to Jeff Godin (jgodin) |
10:42 |
jeff |
oh weird. that's not the summary as i had edited it. |
10:42 |
|
Christineb joined #evergreen |
10:42 |
jeff |
i'm guessing i edited the search field instead. ah well. |
11:12 |
|
mmorgan joined #evergreen |
11:48 |
|
khuckins joined #evergreen |
11:51 |
|
_adb joined #evergreen |
12:47 |
csharp |
aebf4a5 |
12:47 |
pinesol_green |
csharp: [evergreen|Bill Erickson] User Activity : SIP activity tracking - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aebf4a5> |
12:48 |
|
jihpringle joined #evergreen |
12:58 |
|
khuckins_ joined #evergreen |
13:04 |
|
rlefaive joined #evergreen |
13:16 |
|
rlefaive joined #evergreen |
13:32 |
|
sandbergja joined #evergreen |
13:34 |
|
khuckins__ joined #evergreen |
13:35 |
|
rlefaive joined #evergreen |
13:38 |
sandbergja |
Hi all! Does Evergreen only accept EDI INVOICs that have SANs in the format NAD+BY+[SAN]::91? Our vendor sends them with ::92 at the end, and I want to make sure my understanding is correct before reporting a bug / asking the vendor to use 91 instead. |
13:39 |
sandbergja |
(I was looking at line 25 of this, btw: https://github.com/evergreen-library-system/Evergreen/blob/tags/rel_2_12_2/Open-ILS/src/perlmods/lib/OpenILS/Utils/EDIReader.pm |
13:45 |
berick |
sandbergja: i'm not aware of any. what vendor, if you don't mind me asking. |
13:45 |
berick |
for reference, 91 = Assigned by supplier or supplier’s agent, 92 = Assigned by buyer |
13:45 |
sandbergja |
berick: It's Proquest Coutts |
13:46 |
berick |
sandbergja: ok. a vendor I have not encountered. they all do /something/ different :) |
13:46 |
sandbergja |
hahaha of course! :-) |
13:47 |
berick |
an LP bug seems like a good idea. |
13:48 |
sandbergja |
Okay! I can go ahead and type that up. Really, what would need to happen is to change the regex to be a bit more permissive, right? |
13:49 |
sandbergja |
Actually, now that I look closer, EG is looking for SANs in something that ends in ::31B, not ::91 |
13:49 |
sandbergja |
or am I mis-reading that? |
13:50 |
berick |
that's right, 31B is hte code for SANs. |
13:51 |
berick |
so, yeah.. SANs should use 31B. 91/92 are for locally defined values. |
13:51 |
berick |
like ad-hoc account codes |
13:51 |
sandbergja |
So, in the meantime, I'll ask the vendor if they can put the SAN in 31B, and file a not-very-urgent LP bug about allowing 92 for account codes. |
13:51 |
sandbergja |
Thanks so much for your help, berick! |
13:52 |
berick |
yr welcome |
13:55 |
|
rlefaive joined #evergreen |
14:18 |
|
rlefaive joined #evergreen |
14:21 |
|
rlefaive joined #evergreen |
14:40 |
JBoyer |
berick, I see all of the existing EDI docs still talk about the webrick install; is there anything about the new A/T EDI setup? (or is it so basic as "enable this A/T, turn off those 2 perl scripts, turn on these two?) |
14:47 |
JBoyer |
berick, Ah, never mind. Found it in the general 3.0 release notes, I was looking in the more specific directories. |
14:48 |
* berick |
nods |
14:48 |
kmlussier |
I'm having trouble building the web client on 2.12. When I run the npm install command, I get the following - https://pastebin.com/n7cBknbg |
14:49 |
berick |
@band add Weird Error 8 |
14:49 |
pinesol_green |
berick: Band 'Weird Error 8' added to list |
14:50 |
kmlussier |
:) |
14:53 |
berick |
JBoyer: more or less what you said. enable and configure edi-attrs per edi account as desired, cron the new edi_order_pusher.pl script. if going all-in, disable the legacy edi_pusher script. no A/T changes are needed, though you could disable the JEDI event-def once fully migrated. |
15:00 |
JBoyer |
Since we never actually got off the ground in the webrick days I'll just switch off all of that and onward we go. |
15:00 |
JBoyer |
berick++ |
15:01 |
berick |
nice, that's a good way to start. |
15:04 |
JBoyer |
kmlussier, that sounds familiar; if you have any node debs installed (i.e. if `dpkg -l | grep nodejs` returns anything) you should remove it and any dependencies and then repeat the prerequisites install to get a more current node installed. |
15:26 |
kmlussier |
JBoyer: OK, I'll try that. Thanks! |
15:26 |
kmlussier |
Strange that it hasn't come up before. |
15:27 |
JBoyer |
I don't recall when it popped up, and if you normally have VMs that don't have nodejs pre-installed you might not normally see it. |
15:38 |
kmlussier |
JBoyer: Yes, well, that's why it's strange because I am installing it on a newly-built VM. |
15:39 |
JBoyer |
Ah, very strange then, yes. |
15:39 |
kmlussier |
node is installed while I run make -f Open-ILS/src/extras/Makefile.install ubuntu-trusty-developer, right? Is it possible we're grabbing an older version of node? |
15:42 |
JBoyer |
That's when it's installed, yes. It's supposed to install it from source though, so it should always been pretty fresh. |
15:42 |
JBoyer |
What you're seeing *should* only happen if it's installed via apt-get / aptitude / etc. |
15:43 |
JBoyer |
But, so long as you're up and going, there's a mystery for another time. ;) |
15:47 |
kmlussier |
No, not up and going yet. I'm checking master now to see if I come across the problem there too. |
15:48 |
bshum |
Well, the version of node that gets installed depends on which distro you're on. Some of them use the packaged apt source, others will download the binary directly |
15:48 |
bshum |
So I guess my first question is what Linux flavor are you using kmlussier? |
15:48 |
kmlussier |
ubuntu 14.04 |
15:49 |
bshum |
Okay, 14.04 installs the nodejs from packages |
15:51 |
bshum |
I did think about suggesting that we use just the nodejs sources instead of whatever distros package with |
15:56 |
bshum |
Oh nvm |
15:56 |
bshum |
kmlussier just pointed me out at a patch I did to already make that the approach for 3.0+ |
16:00 |
JBoyer |
Ah, oops. I was looking at my 3.0+ version of the trusty makefile, I forgot about that part. |
16:02 |
bshum |
It's not hard to port the stuff for using nodejs binary latest LTS instead of the apt packaged legacy stuff. |
16:02 |
* jeff |
laughs at the usage of "nvm" in a conversation about node |
16:02 |
bshum |
But I guess we didn't backport it cause we didn't expect there to be much change for 2.12 |
16:02 |
bshum |
Heh |
16:03 |
jeff |
(nvm == node version manager -- not something I think is immediately helpful here) |
16:09 |
Bmagic |
pg_restore - we get the errors when restoring to a blank DB complaining about functions that do not exist. Should the db have the schema's already created before the restore so that the functions exist ahead of time? |
16:10 |
Bmagic |
I think the answer is "ignore those function errors and restore to a blank db" |
16:10 |
kmlussier |
bshum: So we should be backporting bug 1683388 and bug 1718549 to 2.12? |
16:10 |
pinesol_green |
Launchpad bug 1683388 in Evergreen "Install newer NodeJS binary for Ubuntu Trusty and Debian Wheezy" [High,Fix released] https://launchpad.net/bugs/1683388 |
16:10 |
pinesol_green |
Launchpad bug 1718549 in Evergreen "install NodeJS from source for all supported distributions" [High,Fix released] https://launchpad.net/bugs/1718549 - Assigned to Galen Charlton (gmc) |
16:10 |
|
rlefaive joined #evergreen |
16:11 |
bshum |
kmlussier: Possibly. |
16:11 |
bshum |
Not sure if that's the real problem or not based on your errors you saw |
16:11 |
* kmlussier |
can try it locally to see if it fixes her issue. |
16:13 |
bshum |
And I'm not 100% sure what'll happen if you have both nodejs legacy and then install the nodejs binary |
16:13 |
bshum |
If it'll just figure out to use the newer one, or if it'll be unhappy till you remove nodejs legacy |
16:13 |
bshum |
I vaguely recall testing that out |
16:13 |
bshum |
but it's been awhile.. |
16:14 |
jeff |
Bmagic: can you please name the functions in question? |
16:14 |
jeff |
Bmagic: my first thought is that you may be running into bug 1671150 |
16:14 |
pinesol_green |
Launchpad bug 1671150 in Evergreen "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Medium,Fix committed] https://launchpad.net/bugs/1671150 |
16:15 |
Bmagic |
jeff: I thought of that one too! |
16:15 |
Bmagic |
that is a problem, but not the only one |
16:15 |
Bmagic |
ALTER FUNCTION metabib.compile_composite_attr(cattr_def text) OWNER TO evergreen - ERROR: function metabib.compile_composite_attr(text) does not exist |
16:15 |
jeff |
Bmagic: if it's not that, then can you (in addition to the function names or full pg_restore output), i'd be interested to know how you're creating the database. |
16:15 |
Bmagic |
CREATE FUNCTION compile_composite_attr(cattr_def text) RETURNS evergreen.query_int ERROR: type "evergreen.query_int" does not exist |
16:16 |
jeff |
are you using -e / --exit-on-error with your pg_restore? if not, what is the first error you see in the pg_restore output? |
16:16 |
jeff |
(also, still interested in how you're creating the database) |
16:17 |
Bmagic |
not exiting on error... Command was: CREATE FUNCTION compile_composite_attr(cattr_id integer) RETURNS evergreen.query_int is the first error |
16:18 |
jeff |
okay, metabib.compile_composite_attr() is a plperlu function. does the database you're restoring to have plperlu as a language? |
16:19 |
jeff |
(\dL from psql) |
16:20 |
miker |
Bmagic: you need to install the extensions in the empty db |
16:20 |
Bmagic |
miker: got that |
16:20 |
jeff |
Bmagic: what method and/or commands are you using to create your empty database? |
16:21 |
Bmagic |
CREATE DATABASE evergreen TEMPLATE template0 ENCODING 'UNICODE' LC_COLLATE 'C' LC_CTYPE 'C'; |
16:21 |
jeff |
Bmagic: can you share the output of \dL and \dx for the empty database (even if partially-restored-into)? |
16:22 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "PG creation" (13 lines) at http://paste.evergreen-ils.org/947 |
16:22 |
jeff |
generally you'll want to create an empty database to restore into using proper arguments to eg_db_config.pl or the steps in Open-ILS/src/sql/Pg/create_database_extensions.sql (paying attention to the comments) |
16:23 |
jeff |
Bmagic: what version of Evergreen for the database dump you're restoring? |
16:23 |
Bmagic |
CREATE EXTENSION unaccent; is missing from my script..... |
16:24 |
jeff |
you're missing the unaccent extension, which iirc has been a requirement since 2.11 |
16:24 |
jeff |
yeah. |
16:24 |
jeff |
also, how are you calling pg_restore? |
16:25 |
Bmagic |
-C -d |
16:25 |
jeff |
you don't want -C |
16:25 |
Bmagic |
alright, I'll try that |
16:28 |
Bmagic |
still have the issue with missing function calls, how big of an issue is that exactly? In theory I can create the missing function (evergreen.query_int) before restoring? |
16:28 |
jeff |
-C is going to have pg_restore create a new database matching the name of the database in the dump file. that probably isn't the name of the empty database you created to hold your restore. |
16:28 |
jeff |
i think that's probably solving the wrong problem. |
16:28 |
jeff |
or attempting to. |
16:29 |
Bmagic |
it is the same db name |
16:29 |
Bmagic |
the very tippy top error is complaining about the db already existing, but that is OK because I think I created it just fine |
16:30 |
jeff |
the behavior in that case is not defined in the manpage. (-C without --clean where the database name in the dump file already exists in the cluster). I haven't tested to see what the actual behavior is. Were you able to share the \dL and \dx output of the database you're attempting to restore into? |
16:30 |
Bmagic |
that went away when I removed -C |
16:30 |
jeff |
okay. i still recommend getting out of the habit of using -C, but it sounds like it was not the cause of your issue. |
16:31 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "\dL \dx" (22 lines) at http://paste.evergreen-ils.org/948 |
16:33 |
jeff |
are you dropping and re-creating the database between pg_restore attempts? |
16:36 |
Bmagic |
yes |
16:36 |
jeff |
okay. if you remove -C and add -e to your pg_restore, what does your pg_restore command line look like? feel free to sanitize as long as it's clear what you're sanitizing. :-) |
16:37 |
Bmagic |
sec |
16:38 |
Bmagic |
Error from TOC entry 4496; 1255 17114 FUNCTION compile_composite_attr(integer) evergreen |
16:38 |
Bmagic |
could not execute query: ERROR: type "evergreen.query_int" does not exist |
16:38 |
Bmagic |
Command was: CREATE FUNCTION compile_composite_attr(cattr_id integer) RETURNS evergreen.query_int |
16:39 |
Bmagic |
let me see what it does if that function DID exist |
16:39 |
jeff |
What version of Evergreen is this database, and what did your pg_restore command line look like? |
16:44 |
jeff |
the query_int type is part of the intarray extension. i would expect to find both the extension and the type in the public schema. it sounds like your source database had it in the evergreen schema, either due to baseline/upgrade script oddity or something local being different. |
16:44 |
jeff |
possibly a search_path biting you if you connect as a user called "evergreen", etc. |
16:45 |
Bmagic |
I thought of search path too |
16:46 |
jeff |
changing your CREATE EXTENSION for intarray to this might be needed in this case: CREATE EXTENSION intarray WITH SCHEMA evergreen; |
16:46 |
jeff |
is the source database available for you to query? |
16:48 |
Bmagic |
weird. I can't find the example of query_int in any of my other test machines |
16:48 |
Bmagic |
only query_int_wrapper |
16:48 |
jeff |
it would be a type, not a function. |
16:48 |
jeff |
\dT |
16:48 |
Bmagic |
I see |
16:48 |
jeff |
rather, "\dT query_int" to find it in your search path. |
16:48 |
kmlussier |
Backporting the commits to install nodejs appears to work. I'll create a branch and post it to LP. bshum++ JBoyer++ |
16:48 |
Bmagic |
yep, \dT shows it |
16:49 |
Bmagic |
must be a search path thing, let me switch that up |
16:49 |
jeff |
okay. on the source database does \dT show query_int in the evergreen schema or the public schema? |
16:49 |
Bmagic |
yes |
16:49 |
jeff |
that wasn't a yes or no question. :-) |
16:50 |
Bmagic |
sorry, lol, public |
16:51 |
Bmagic |
ALTER DATABASE evergreen SET search_path TO evergreen,public; |
16:51 |
Bmagic |
or public should be first....? I'm not sure where the assumption is made about which schema to look for query_int is made |
16:51 |
jeff |
i wouldn't go altering your search path without a reason. |
16:52 |
Bmagic |
if the restore used public.query_int - it would find it, therefore, problem sovled right? |
16:53 |
jeff |
or if it existed at evergreen.int_array |
16:54 |
jeff |
does your source database have results for both \dT public.query_int and \dT evergreen.query_int? |
16:55 |
Bmagic |
here's an idea! let the restore create the db..... |
16:56 |
Bmagic |
just tried it, so far no errors, lol |
16:56 |
jeff |
...which won't work because pg_dump/pg_restore don't do languages or extensions... |
16:57 |
Bmagic |
missing those would result in errors during restore? |
16:57 |
jeff |
yup. |
16:57 |
jeff |
and a failed restore. |
16:57 |
jeff |
unless your target db already had the correct languages and extensions. |
16:58 |
Bmagic |
wouldn't it fail pretty quickly? |
16:58 |
jeff |
probably. |
16:58 |
Bmagic |
still running...... |
16:58 |
|
mmorgan1 joined #evergreen |
17:00 |
Bmagic |
I was expecting to see the db during the restore, but it's not available. It must be "in it's head" during the restore process. A giant transaction maybe? |
17:01 |
jeff |
at least with postgresql 9.4, you can't have one extension installed in two schemas in the same database, so i'm puzzled as to why your dump is trying to reference a type of evergreen.query_int while the source db has the intarray extension installed in the public schema. |
17:01 |
|
mmorgan1 left #evergreen |
17:01 |
jeff |
unless the evergreen.query_int type was manually created outside of the extension framework, or one or more of our assumptions is wrong. |
17:03 |
* jeff |
checks some of his own assumptions |
17:03 |
jeff |
(especially the extensions/languages pg_dump/pg_restore one) |
17:10 |
jeff |
yup, i'm wrong about the language and extensions. the logic for pg_restore isn't that it skips those on restore when restoring into an existing database, it's that it does a CREATE OR REPLACE on the languages and a CREATE IF NOT EXISTS for the extensions. |
17:10 |
jeff |
so, does "pg_restore --schema-only dumpfile | grep 'CREATE EXTENSION'" show intarray being created in the public or evergreen schema? |
17:11 |
bshum |
kmlussier++ # web client building happiness for all |
17:11 |
jeff |
and what does the output of this look like? pg_restore --schema-only dumpfile | grep "query_int" |
17:16 |
khuckins__ |
Has anyone here conditionally applied styles to cell content eg-grid-fields? ng-class doesn't seem able to see the item in the current eg-grid-field, whether I make a scope function or do the condition check in the ng-class attribute itself. I can display the data outside the element, so it's a bit odd. Currently working in the bills list |
17:20 |
jeff |
Bmagic: you've gone silent -- I'm still interested in answers to the various questions above, if only to help update documentation/recommendations and understand what state your database is in and how it may have gotten there. Heading out for a few, back later. |
17:20 |
Bmagic |
jeff: sorry, back |
17:20 |
jeff |
heh. |
17:21 |
Bmagic |
so, just after installing postgres, I did run the typical evergreen install script, then deleted the db and created fresh |
17:22 |
Bmagic |
I let the eg scripts work it's magic on the fresh postgres install (if that makes a difference) |
17:23 |
jeff |
i'd be interested in the two pg_restore + grep commands above. it would help understand what the dump file contains with regard to the extension/type in question. |
17:23 |
Bmagic |
I just ran schema only |
17:23 |
Bmagic |
no errors |
17:24 |
|
bos20k joined #evergreen |
17:24 |
Bmagic |
from what I can tell, it also didn't do anything |
17:24 |
jeff |
pg_restore --schema-only dumpfile | grep 'CREATE EXTENSION' |
17:24 |
jeff |
pg_restore --schema-only dumpfile | grep "query_int" |
17:24 |
Bmagic |
right |
17:24 |
Bmagic |
maybe I need to throw in the -d evergreen |
17:25 |
jeff |
i'm interested in seeing the full output of those commands (replacing dumpfile with the name/path of the file you're restoring) |
17:26 |
jeff |
away for a few, back later this evening! |
17:26 |
jeff |
Bmagic++ |
17:26 |
Bmagic |
pg_restore -d evergreen --schema-only dump.dmp | grep "query_int" |
17:26 |
Bmagic |
jeff++ |
17:28 |
pastebot |
"jeff" at 64.57.241.14 pasted "pg_restore -d evergreen --schema-only dump.dmp | grep "query_int"" (27 lines) at http://paste.evergreen-ils.org/949 |
17:32 |
Bmagic |
sorry khuckins__ - I have not |
18:10 |
|
jvwoolf joined #evergreen |
18:11 |
|
JBoyer_alt joined #evergreen |
18:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
19:02 |
|
beanjammin joined #evergreen |
19:04 |
beanjammin |
khuckins: You were asking about conditionally adding classes to grid fields? I just finished doing a little bit of that. |
19:06 |
khuckins |
beanjammin: Yeah, I've been wracking my brain a bit, specifically trying to make a few glyphicons show up in a field depending on certain values in the item |
19:08 |
beanjammin |
I banged my head trying to add a class to show overdue items in a Patron's Checked Out items list. This is what I came up with - http://paste.evergreen-ils.org/950 |
19:09 |
|
rlefaive joined #evergreen |
19:15 |
khuckins |
Oooh I've done something somewhat similar for a separate part of this - to get row highlighting working |
19:16 |
khuckins |
Sadly editing the autogrid wouldn't work too well for this particular instance, but thanks :) |
19:30 |
|
rlefaive joined #evergreen |
19:37 |
|
Christineb joined #evergreen |
22:31 |
jeff |
@later tell Bmagic thanks for the paste output attempt, but you seem to have added an argument (-d evergreen). if you still have time and interest, I'd be interested in seeing the output of the command without that added argument. |
22:31 |
pinesol_green |
jeff: The operation succeeded. |
23:15 |
|
ohiojoe joined #evergreen |