00:18 |
|
remingtron_ joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:45 |
|
jvwoolf1 joined #evergreen |
07:49 |
|
jvwoolf2 joined #evergreen |
08:24 |
|
mdriscoll joined #evergreen |
13:26 |
mmorgan |
I'm looking at the views in the money schema, but not sure if that's the best way. |
13:26 |
|
rgagnon joined #evergreen |
13:30 |
kmlussier |
mmorgan: I think Dyrcona asked a similar question in here over the past 2 or 3 weeks. But I think he was looking for a random user, not working with a list of users, so the answer to his question may or may not be helpful. |
13:31 |
mmorgan |
Yes, I remember that discussion. He was just looking for a random patron that owed fines to test with. I'm not sure there was a definitive answer. |
13:47 |
|
tspindler joined #evergreen |
13:49 |
tspindler |
Evergreen Oversight Board meeting will start in 10 minutes |
13:56 |
|
sherbertbc joined #evergreen |
16:27 |
terran |
To be fair, I only hate it because I'm so bad at it. |
16:29 |
kmlussier |
terran: I hear ya |
16:29 |
kmlussier |
It's easy to be bad at git |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:33 |
Freddy_Enrique |
*Freddy suddenly remembers Dyrcona's words, and starts watching git tutorials |
16:44 |
|
Ryan_M joined #evergreen |
16:45 |
Ryan_M |
Hi! Can somebody help me refresh my catalog display to display the correct book cover? |
02:23 |
|
Josethcortez joined #evergreen |
02:23 |
Josethcortez |
holaaaaaaaaaa |
02:25 |
|
Josethcortez left #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
08:42 |
|
mmorgan joined #evergreen |
09:26 |
bshum |
Maybe it would make sense to move the maintenance release cut to next week so that we can maximize bug week :) |
09:27 |
|
maryj joined #evergreen |
13:10 |
Freddy_Enrique |
I've just graduated, reason why I was absent lately. Time to do my homework |
13:11 |
bshum |
Freddy_Enrique: Awesome, congratulations |
13:12 |
Freddy_Enrique |
yeah! Thanks ^_^. Ive seen that the web client demo is up and running, awesome |
13:12 |
Freddy_Enrique |
I was able to do some cataloginf with the staff client. I'll do some more test before attemping to install the web client |
13:34 |
|
alynn26 joined #evergreen |
14:27 |
|
troy__ joined #evergreen |
14:37 |
|
deep-book-gk_ joined #evergreen |
16:30 |
Freddy_Enrique |
=_=, gonna have a serious conversation with my teachers |
16:30 |
bshum |
Well it's part of RDA spec if I remember right when we built it out to support that particular field |
16:31 |
bshum |
Or at least whatever the spec was back then |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:31 |
* bshum |
is not a cataloger |
16:31 |
bshum |
@quote search cataloger |
16:31 |
pinesol_green |
bshum: 1 found: #46: "<_bott_> I am not a cataloger, but I speak..." |
00:45 |
|
eady joined #evergreen |
05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:09 |
|
JBoyer joined #evergreen |
07:32 |
|
agoben joined #evergreen |
08:48 |
|
mmorgan joined #evergreen |
09:04 |
JBoyer |
Doesn't look like it was backported to 2.11, but I imagine you shouldn't have too much trouble. Good luck! |
09:04 |
JBoyer |
mmorgan++ # Coaxing LP Search to work, heh |
09:06 |
mmorgan |
csharp: FWIW, in the past I have found that the action trigger produced the csv for large histories, but it never made it to the browser for download. So potentially you could find it in trigger output. |
09:06 |
csharp |
we just turned on circ history like last year or the year before, so that's probably why we'd be just now hitting it |
09:06 |
csharp |
mmorgan: I'll look - thanks for the leads! |
09:19 |
|
terran joined #evergreen |
09:21 |
|
yboston joined #evergreen |
09:28 |
|
mdriscoll joined #evergreen |
09:37 |
* csharp |
blows the dust off his xenial test server for bug squashin' |
09:55 |
|
maryj joined #evergreen |
09:58 |
|
Christineb joined #evergreen |
10:05 |
|
mmorgan1 joined #evergreen |
10:41 |
|
mmorgan joined #evergreen |
10:47 |
dbs |
hey miker super-naive question here, but in the absence of that UNIQUE CONSTRAINT should I ever have two rows in metabib.browse_entry where sort_value & value are identical? |
10:48 |
pinesol_green |
[evergreen|Jason Boyer] LP1704463: Item Status Fields Correction - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a15dc23> |
10:49 |
dbs |
(because of course my attempt to add a unique index using substring() is failing due to duplicates; example 1 being https://laurentian.concat.ca/eg/opac/results?query=a+compleat+history+of+europe+or+a+view+of+the+affairs+thereof+civil+and+military+for+the+year+1705+containing+all+the+publick+and+secret+transactions+therein+the+several+steps+taken+by+france+for+an+universal+monarchy+and+to+enslave+her+neighb |
10:49 |
dbs |
ours+the+wars+in+italy+poland+germany+netherlands&qtype=title&fi%3Asearch_format=&locg=105 |
10:50 |
dbs |
was trying with a simplistic: CREATE UNIQUE INDEX CONCURRENTLY browse_entry_sort_value_value_key ON metabib.browse_entry (SUBSTRING(sort_value FROM 0 FOR 2048), SUBSTRING(value FROM 0 FOR 512)); |
10:52 |
* dbs |
has never dealt with browse stuff before, yay 2.12 upgrade tests :) |
10:53 |
* dbs |
ponders throwing the ID field into the mix to guarantee uniqueness, heh |
10:59 |
|
Jillianne joined #evergreen |
11:04 |
pinesol_green |
[evergreen|Martha Driscoll] LP#1692106: Z39.50 server includes prefix and suffix in 852 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e8a19ad> |
11:06 |
pinesol_green |
[evergreen|Galen Charlton] LP#1691560: start open-ils.qstore service by default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=95aa127> |
14:15 |
|
kmlussier joined #evergreen |
14:39 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1486451: Remove rdetails_status nowrap style - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e2c70de> |
16:25 |
* phasefx |
just got bit by a launchpad timeout error.. going to rewrite the ticket in vim first :D |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:50 |
|
Jillianne joined #evergreen |
16:57 |
phasefx |
berick: dbs: kmlussier: https://bugs.launchpad.net/evergreen/+bug/1704873 |
16:57 |
pinesol_green |
Launchpad bug 1704873 in Evergreen "webstaff item print labels" [Undecided,New] |
01:42 |
|
Jillianne joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:40 |
|
rlefaive joined #evergreen |
07:19 |
|
agoben joined #evergreen |
07:24 |
|
rjackson_isl joined #evergreen |
10:05 |
Dyrcona |
Yes, on 2.12.3 plus customizations. |
10:06 |
Dyrcona |
I've seen issues with ISBN searches before, but it seemed randomish and I never tracked it down. |
10:08 |
kmlussier |
Dyrcona: Yeah, the one I replicated was with the metarecord searches. Those are a little easier to make happen. Were the ISBN issues you saw prior to 2.12? |
10:09 |
Dyrcona |
kmlussier: I'm not certain. It may have been on test servers. I'm not sure I've seen it in production on 2.10, still. |
10:20 |
Dyrcona |
So, when are we moving search out of the database and using a real search engine? |
10:20 |
* Dyrcona |
ducks the flying duck decoys. :) |
10:25 |
dbs |
Also on nginx proxying maybe we rely on nginx to do all of the TLS work and just proxy Apache on port 80? |
13:27 |
Dyrcona |
jeffdavis++ |
13:29 |
Dyrcona |
What does the ebook_api.ebook_test.enabled setting do? |
13:29 |
Dyrcona |
Oh never mind. I think I see what it does. |
13:29 |
Dyrcona |
It enables a test provider. |
13:30 |
jeffdavis |
Yeah, same one the live tests use. |
13:32 |
jeffdavis |
If you load the concerto dataset and do an OPAC search for "tolkien" with the test provider enabled, you should see it at work. |
13:32 |
Dyrcona |
Well, we've got it mostly working, so far. Are the users check outs and holds supposed to be showing up? |
13:33 |
jeffdavis |
Yeah, transactions should be displayed in separate "E-Items Checked Out" / "E-Items on Hold" tabs in My Account |
13:33 |
jeffdavis |
actually performing checkouts and holds from the OPAC should be possible in 3.0, I have a working branch for that to be pushed today actually |
13:56 |
|
Jillianne joined #evergreen |
14:08 |
stompro |
dbs++, thanks for pointing out the other nowrap fix. |
14:37 |
|
jvwoolf joined #evergreen |
15:23 |
jeffdavis |
I've shared a working branch for bug 1673870. I'll be away for the next couple of weeks, but if anyone wants to test what's there, please feel free. |
15:23 |
pinesol_green |
Launchpad bug 1673870 in Evergreen "Add support for ebook API transactions in OPAC (OverDrive/OneClickdigital)" [Undecided,New] https://launchpad.net/bugs/1673870 - Assigned to Jeff Davis (jdavis-sitka) |
15:24 |
kmlussier |
jeffdavis++ |
15:24 |
kmlussier |
That's exciting! |
15:45 |
jeffdavis |
I don't recall if you need to request discovery/circ access separately - I think you get them both when you have patron auth. |
15:59 |
JBoyer |
jeffdavis++ |
15:59 |
JBoyer |
Something to look into in a couple weeks when I have time again. |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:03 |
|
mmorgan left #evergreen |
17:09 |
|
jvwoolf left #evergreen |
18:53 |
|
Bmagic joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:54 |
|
rlefaive joined #evergreen |
07:11 |
|
rjackson_isl joined #evergreen |
07:33 |
|
agoben joined #evergreen |
11:54 |
Dyrcona |
:) |
11:55 |
jeff |
hrm. that's weird. the Sitka manual for 2.10 includes things like "new in evergreen version 2.12": http://docs.sitka.bclibraries.ca/Sitka/sitka_2_10/html/ |
11:55 |
Dyrcona |
I was gonna try his patches later, but you beat me to it. |
11:56 |
* Dyrcona |
has been writing a php script to test some SIP code. |
11:56 |
jeff |
oh, hah-- the sections say 2.12 but appear to describe 2.10 features. |
11:57 |
jeff |
Dyrcona: using tsbere's lib or something else / from scratch? |
11:57 |
csharp |
@who foresaw 2.12 features? |
11:57 |
pinesol_green |
sard foresaw 2.12 features. |
11:57 |
Dyrcona |
jeff: Using tsbere's lib, and I think I'm going to add a debug option to log the messages that are sent and received. |
11:58 |
Dyrcona |
I also used PDO to retrieve a list of patron bacordes from the database likely to test the new feature. |
12:00 |
jeff |
which new feature? |
12:00 |
Dyrcona |
It's an improvement to fine item details. I'm not sure we've made a Lp bug, yet. |
12:00 |
jeff |
i've found interesting bugs in the past by fetching all users and / or all items, etc. :-) |
12:01 |
Dyrcona |
if FineItems is > 0, then I look them up again, requesting the fine item details. |
12:02 |
|
rlefaive joined #evergreen |
12:02 |
Dyrcona |
So far, nothing has turned up. :( |
12:07 |
Dyrcona |
jeff: I think I may turn up something broken, whether that's the new code, old code, or my test environment, I'm not sure, yet. |
12:13 |
Dyrcona |
This might be something to do with th PHP library: Unsupported field 'AY' in Patron Info message |
12:13 |
Dyrcona |
It doesn't seem to prevent the message from being processed. I'll look into it later. |
12:17 |
|
jihpringle joined #evergreen |
16:23 |
phasefx |
bshum: roger that |
16:24 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1686832 |
16:24 |
pinesol_green |
Launchpad bug 1686832 in Evergreen "fieldmapper changes break with translations" [Medium,Triaged] |
16:24 |
bshum |
But I *think* that if one were to not use the ansible installer with the i18n options, it should just install clean and happy |
16:25 |
* bshum |
hasn't tested that theory lately |
16:25 |
* bshum |
usually builds with i18n and then runs his own magic POT sync to fix things |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:36 |
phasefx |
yay, it's all working, even the webstaff client |
16:38 |
|
mmorgan1 joined #evergreen |
16:38 |
phasefx |
though settings-tester.pl warns that libdbi PostgreSQL driver not found in shared library path |
00:28 |
|
jvwoolf joined #evergreen |
01:58 |
|
Stompro joined #evergreen |
02:47 |
|
genpaku joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:11 |
|
rjackson_isl joined #evergreen |
07:18 |
|
JBoyer joined #evergreen |
07:33 |
|
agoben joined #evergreen |
10:56 |
Dyrcona |
Yeah, and Josh Berkus reported performance hits with ht once you get past the number of actual cores. |
10:57 |
JBoyer |
Yeah, they're basically only 1/2 - 3/4 of a real core, some things are going to block in weird ways. |
10:57 |
JBoyer |
I did turn it off on my machines eventually. |
10:57 |
JBoyer |
But Proper Testing (tm) sounds interesting, I'm curious to see what you find. |
10:58 |
|
rlefaive joined #evergreen |
10:58 |
Dyrcona |
I've never used pg_bench before, so it might take me a few weeks to do proper testing. |
11:01 |
Dyrcona |
So, I'll try -j 40 just for kicks. :) |
11:31 |
dbs |
Am I wrong in thinking that each of the records linked to a conjoined item should show the call number / copy info? |
11:33 |
dbs |
For example, https://laurentian.concat.ca/eg/opac/record/3111007 shows it is linked to "Douglas-fir" but the corresponding record https://laurentian.concat.ca/eg/opac/record/3111012 doesn't show a call number, making it hard / impossible to find on the shelf |
15:53 |
rjackson_isl |
Dyrcona++ mystery solved then? ;) |
15:54 |
kmlussier |
Dyrcona: Yeah, now that you mention it, I think I knew that. I spent a bit of time looking closely at those screens a month or two ago. |
15:54 |
kmlussier |
dbs++ |
15:54 |
dbs |
(because of course our test Concerto records all have additional copies on them) |
15:58 |
kmlussier |
dbs: Yes, even the records for electronic resources have copies on them, which isn't ideal. I've been meaning to submit a patch to add e-resource records with just URIs. |
16:01 |
* dbs |
has only himself to blame for that |
16:03 |
kmlussier |
dbs: Blame for giving us a set of test records we can work with? |
16:15 |
|
jvwoolf joined #evergreen |
16:17 |
Dyrcona |
About email payment receipts: It appears also that is the only way to trigger the event at the moment. |
16:18 |
* Dyrcona |
smells an enhancement request coming in the near future. |
16:23 |
Dyrcona |
And, it looks like we missed a release note for 2.10 regarding that event. I'll have to do an update on the event defs' template fields. |
16:27 |
dbs |
Might be as simple as adding "IF ctx.foreign_copies; has_copies = 'true'; END;" to copy_table.tt2 |
16:30 |
pastebot |
"dbwells" at 64.57.241.14 pasted "foreign copies local change (dbs)" (13 lines) at http://paste.evergreen-ils.org/181 |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:31 |
dbwells |
dbs: Just checking in for the first time today, ^^ is a patch we have locally. |
16:32 |
dbwells |
dbs: really the same idea as you state |
16:35 |
dbs |
thanks dbwells - also there's some jankiness in the trigger to update asset.opac_visible_copies (freaks out if there's already an entry when you try to add a conjoined item and makes it fail) |
16:41 |
* dbwells |
should make a branch for the other as well while it has his attention. |
16:46 |
kmlussier |
dbwells++ dbs++ |
16:46 |
dbs |
also fixing up the use of "copy_info.location" where we actually need bib.target_copy.location.name and the like |
16:55 |
dbwells |
dbs++ sounds good. We apparently didn't get that far. By the time we got things to show up, the librarian testing it out had moved on to something else, and it hasn't come around again for us. We have something like 100-200 bound volumes, so it naturally doesn't get much priority :( |
16:58 |
|
jvwoolf joined #evergreen |
16:58 |
dbs |
dbwells: bug 1703678 for your enjoyment |
16:58 |
pinesol_green |
Launchpad bug 1703678 in Evergreen "Conjoined items do not display without an extra copy attached to the record" [Undecided,New] https://launchpad.net/bugs/1703678 |
16:59 |
dbwells |
dbs: off-topic question, but something eating my time lately, do you guys do anything in the ilk of "institutional repository"? We've run a few test instances of various products over the years, but our only production collections are homegrown. We're getting ready to try out Invenio. Just curious. |
16:59 |
dbs |
have to go pick up a kid but will be back in a while -- and yes we have run DSpace in production since 2007 and it's a Java monster :) |
17:00 |
dbwells |
dbs: cool, I will maybe pick your brain about it sometime in the future. |
17:02 |
|
jvwoolf1 joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:40 |
|
rlefaive joined #evergreen |
07:15 |
|
rjackson_isl joined #evergreen |
07:30 |
|
agoben joined #evergreen |
10:02 |
* pinesol_green |
brews and pours a cup of Kenya Peaberry Thika Gethumbwini, and sends it sliding down the bar to Freddy_Enrique |
10:02 |
Dyrcona |
@tea |
10:02 |
* pinesol_green |
brews and pours a pot of Laoshan Black, and sends it sliding down the bar to Dyrcona (http://ratetea.com/tea/verdant/laoshan-black/6664/) |
10:33 |
csharp |
hmm - interesting: https://metacpan.org/pod/Email::Send |
10:33 |
csharp |
"Email::Send is going away... well, not really going away, but it's being officially marked "out of favor." It has API design problems that make it hard to usefully extend and rather than try to deprecate features and slowly ease in a new interface, we've released Email::Sender which fixes these problems and others. As of today, 2008-12-19, Email::Sender is young, but it's fairly well-tested. Please cons |
10:33 |
csharp |
ider using it instead for any new work." |
10:36 |
Dyrcona |
Yeah, that rings a bell. Think I've known that for a while. |
10:36 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1466502 ? |
10:36 |
Dyrcona |
I believe our use of Email::Send predates that though. |
10:56 |
jvwoolf1 |
Is anybody using the ebook integration as-is in 2.12? Or are you waiting until circulation is in play? |
10:59 |
|
rlefaive joined #evergreen |
11:02 |
Freddy_Enrique |
*reading the manual while listening megalovania |
11:21 |
Dyrcona |
jvwoolf1: We're testing it on training, but I've only had reports that someone's circulations are not showing up and have not looked into it. |
11:22 |
gsams |
So it looks like we've had reports start duplicating for some reason, has anyone ever seen that happen? |
11:27 |
csharp |
gsams: outputs or scheduled reports? |
11:27 |
gsams |
csharp: schedule reports |
14:20 |
Dyrcona |
miker++ # Thanks, also. |
14:51 |
Dyrcona |
Now, to tune the beast. |
15:26 |
|
kmlussier joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:51 |
|
tsadok joined #evergreen |
20:37 |
|
jvwoolf joined #evergreen |
21:26 |
|
jvwoolf joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:30 |
|
rlefaive joined #evergreen |
07:03 |
|
JBoyer joined #evergreen |
07:12 |
|
rjackson_isl joined #evergreen |
08:42 |
|
mmorgan joined #evergreen |
08:51 |
|
kmlussier joined #evergreen |
08:52 |
|
_adb joined #evergreen |
08:52 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Add doc for Cash Reports feature - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a61058> |
08:52 |
kmlussier |
Happy Friday #evergreen! |
08:53 |
kmlussier |
@coffee everyone |
08:53 |
|
bos20k joined #evergreen |
13:40 |
berick |
Dyrcona: you mean any patron? i grab from money.usr_summary with balance_owed <> 0 -- not exactly "easy" |
13:40 |
Dyrcona |
berick: Thanks. I was think of doing something like that. |
13:40 |
Dyrcona |
thinking... |
13:41 |
Dyrcona |
I'm testing some SIP code and need a patron with fines. |
13:53 |
csharp |
heh - just found an ack-grep easter egg: "ack --bar" |
13:54 |
csharp |
well, "found" means "read the man page and saw the option", but still :-) |
13:56 |
bshum |
HA! hilarious, csharp :) |
15:17 |
csharp |
Dyrcona: yeah - I used to stay logged in there, but only lurked |
15:18 |
csharp |
Freddy_Enrique: hope to see you there |
15:18 |
Dyrcona |
I still lurk, occasionally chime in. |
15:19 |
Dyrcona |
So, looking for patrons for this test from money.usr_summary isn't working or the changes broke the SIP code more than one would expect. |
15:19 |
Dyrcona |
I've tried hundreds of patrons so far, and not one has had a fine items count greater than 0 or returned a list of fine item details. |
15:20 |
Freddy_Enrique |
yeah, For what I can tell, anyone could attend it |
15:20 |
Freddy_Enrique |
Ill take a BIG dictionary with me in case i make it in tiem |
16:31 |
jeff |
only on tuesdays. |
16:31 |
|
rlefaive joined #evergreen |
16:31 |
Dyrcona |
If it's Tuesday, this must be Belgium! |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:03 |
|
mmorgan left #evergreen |
18:03 |
|
Freddy_Enrique left #evergreen |
18:30 |
|
dbwells joined #evergreen |
01:11 |
|
barbara joined #evergreen |
01:20 |
|
sallyf_ joined #evergreen |
03:12 |
|
remingtron_ joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:40 |
|
rlefaive joined #evergreen |
06:54 |
|
remingtron joined #evergreen |
06:54 |
|
dbwells_ joined #evergreen |
15:02 |
ohiojoe |
#topic Ongoing Business |
15:02 |
sandbergja |
Sure! |
15:03 |
ohiojoe |
Progress on Docs Reorganization project |
15:03 |
sandbergja |
With the help of a student here, we were able to put together a proof-of-concept |
15:04 |
sandbergja |
that divides the big monolith of official documentation into different manuals for different folks in the library |
15:04 |
sandbergja |
#link http://docs-testing.evergreen-ils.org/ |
15:04 |
sandbergja |
there's something wrong with the serials module, but the others should be ready to explore |
15:04 |
katiemartin |
neat! |
15:05 |
sandbergja |
they are not perfect by any means, but should help to give us a feel for what our docs would look like in a more audience-focused format |
15:05 |
jihpringle |
that's awesome! |
16:51 |
|
mmorgan joined #evergreen |
16:52 |
|
jeffdavis joined #evergreen |
17:00 |
Bmagic |
When the EDI mechanism FTP's a file from the Evergreen server to the vendor, can we customize the file extension to meet the vendor's requirements? |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:02 |
berick |
Bmagic: yes, somedir/*.edi (for example) should do it |
17:02 |
Bmagic |
that belongs in the "out" |
17:03 |
Bmagic |
Their server has a directory "in" and "out" - which I suppose is in their point of view. Therefore, "in" means incoming TO THE VENDOR. And "out" is FROM THE VENDOR |
20:33 |
Fr0z |
evergreen* |
20:34 |
jonadab |
The catalog maybe? |
20:34 |
Fr0z |
yes |
20:34 |
jonadab |
I mean, I don't know that much about penetration testing. I know what it _is_, but it's not something I've ever dabbled in. |
20:35 |
Fr0z |
and one more thing :P.is it easy to handle as a newcomer? |
20:35 |
jonadab |
Only if somebody else does the installation. |
20:35 |
jonadab |
Installing Evergreen is more complicated than installing most software.\ |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:45 |
|
JBoyer joined #evergreen |
07:11 |
|
rjackson_isl joined #evergreen |
07:32 |
|
agoben joined #evergreen |
10:52 |
bshum |
I guess it doesn't like you, hmm... |
10:53 |
dbs |
Seems like it |
10:53 |
dbs |
bshum: using the "admin" account? |
10:53 |
* berick |
was testing w/ admin |
10:53 |
bshum |
dbs: Yep, admin user |
10:53 |
dbs |
*sigh* |
10:54 |
bshum |
Registered my workstation at a different spot, just in case too |
14:25 |
gmcharlt |
tossing out a random documentation note: clicking on the datepicker used in webstaff changes whether you are selecting a day, or a month, or a year |
14:25 |
gmcharlt |
er, clicking on the *title* element |
14:26 |
berick |
thanks gmcharlt |
14:27 |
csharp |
hmm - having an issue on my 2.12 test server: Method [open-ils.circ.copy_note.retrieve.all] not found for OpenILS::Application::Circ - but I can see that that method is indeed in that file :-/ |
14:28 |
Dyrcona |
csharp: Is the IDL OK? Ran autogen? |
14:28 |
berick |
csharp: perl -c Circ.pm compiles OK? |
14:28 |
Dyrcona |
I've got more, but I'll wait. :) |
15:01 |
|
mmorgan1 joined #evergreen |
15:38 |
|
Freddy_Enrique joined #evergreen |
16:23 |
|
Jillianne joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:00 |
|
jvwoolf left #evergreen |
17:07 |
|
mmorgan1 left #evergreen |
17:21 |
kmlussier |
@quote random |
04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
06:40 |
|
rlefaive joined #evergreen |
07:15 |
|
rjackson_isl joined #evergreen |
08:30 |
|
collum joined #evergreen |
10:24 |
jeff |
alas, we also don't use trac, so some of the comments in that bug lack context. |
10:26 |
csharp |
looks like tsbere's fix would solve the original problem though |
10:27 |
csharp |
it disables gzip for conify stuff, which is what appears to have been the original problem |
10:28 |
jeff |
but since many installations run with mod_deflate disabled thanks to the pre-req makefiles, the existing fix might not be as widely tested as we might hope. :-) similar to what dbs pointed out in comment 10 on that bug https://bugs.launchpad.net/evergreen/+bug/652343/comments/10 |
10:28 |
pinesol_green |
Launchpad bug 652343 in Evergreen 2.1 "use of mod_deflate can break XMLENT" [Undecided,Fix released] |
10:28 |
csharp |
right - saw that |
11:10 |
jeff |
a2dismod gained the feature of warning on "essential" modules back in 2014. the logic seems to be "we enables these by default and permit packages to use config directives from these modules without them being wrapped in an IfModule" |
15:56 |
mmorgan |
Freddy_Enrique: You could, but would need to click on the link to see the image. |
15:58 |
Freddy_Enrique |
oh...... I thought I could make it appear on the TPAC :( |
16:21 |
|
Jillianne joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:41 |
kmlussier |
@quote [random] |
16:41 |
pinesol_green |
kmlussier: Error: The command "random" is available in the LoveHate and Quote plugins. Please specify the plugin whose command you wish to call by using its name as a command before "random". |
16:41 |
kmlussier |
@quote random |
16:50 |
|
grue left #evergreen |
16:50 |
* cesardv |
scratches his head |
16:51 |
kmlussier |
cesardv: Yes, those are definitely ones that should be more clearly defined. pullrequest, needstest, signedoff, needsrepatch, needsreleasenote. |
16:51 |
cesardv |
kmlussier: for me the pullsrequest tag didn't assume that the code had been "tested" |
16:51 |
kmlussier |
There has been an ongoing to-do item on the web team's list to create a page that better explains our use of Launchpad. |
16:52 |
kmlussier |
Speaking of the web team, I think I forgot to schedule a meeting. |
16:52 |
Freddy_Enrique |
Guys, when I want to create a Record a couple of fields appear to be filed (until 650). I just checked the concerto record examples and have more fields than I was given. |
16:54 |
Freddy_Enrique |
Can i modify the template which contains the marc fields? |
16:54 |
Freddy_Enrique |
is it possible? |
16:55 |
cesardv |
kmlussier: or we can get rid of launchpad all together :) |
16:56 |
kmlussier |
cesardv: Yeah, now that you mention it, I don't know if I want to invest time into a LP doc page if we really are planning to leave it soon. |
16:57 |
kmlussier |
cesardv: But for now, I think the important thing to know is that when you're code is ready for testing, slap on that pullrequest tag. If more work is needed, the reviewer will probably let you know with a comment at the same time they add a needstest, needsrepatch or needsreleasenote tag. |
16:57 |
kmlussier |
But those last three tags are generally added when somebody notices there is something missing from your code. |
16:58 |
mmorgan |
Freddy_Enrique: Yes, this should help explain how: https://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:customization:cat |
16:58 |
cesardv |
kmlussier: got it, thanks! |
16:59 |
Freddy_Enrique |
wow |
16:59 |
Freddy_Enrique |
thanks! |
16:59 |
kmlussier |
cesardv: Also, needs test will be used if the reviewer thinks a test as required according to the QA guidelines at https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa |
16:59 |
Freddy_Enrique |
mmorgan++ |
17:02 |
* kmlussier |
has fun clearing out serials wishlist items from the MassLNC ideas site based on improvements coming with the web client. |
17:03 |
Freddy_Enrique |
wait....I thought I added an Image, why does this chart keep showing? : https://snag.gy/vmOWZV.jpg |
04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
06:40 |
|
rlefaive joined #evergreen |
07:15 |
|
agoben joined #evergreen |
07:15 |
|
rjackson_isl joined #evergreen |
14:17 |
bshum |
I think if you don't pass that argument for the next client you build, you could end an update line |
14:17 |
bshum |
Or I have done that by accident before.. |
14:17 |
* bshum |
whistles innocently |
14:18 |
bos20k |
So, if you are running a client that is pointing at production.domain.com, it will only ever look there. Even if you try to log in to testing.domain.com it will not see the updates sitting on testing.domain.com? |
14:18 |
Dyrcona |
It's set at configure time. --with-autoupdates-host= |
14:18 |
bshum |
Right, you would need to build a different client to point at auto-updates elsewhere I would think. |
14:18 |
Dyrcona |
Yes, that is my understanding. |
14:19 |
bos20k |
Ok, just want to make sure that was correct. |
14:19 |
jeffdavis |
The autoupdate hostname is saved in the defaults/preferences/autoupdate.js file in your copy of the client, so you can edit that for testing purposes too. |
14:19 |
bos20k |
Otherwise I'm doing something wrong on my testing setup since the production client doesn't want to update from the testing server. |
14:19 |
bshum |
Yeah, but... the files on the server side have to be able to upgrade from X to Y version. So that sounds messy to me jeffdavis |
14:20 |
bshum |
I mean you could copy production XUL and let the test server build on top of it |
14:20 |
bshum |
But yuck |
14:20 |
Dyrcona |
I always build custom clients for testing, often with a different app name to store preferences in a different place. |
14:20 |
jeffdavis |
That's what we do during pre-upgrade testing. |
14:20 |
Dyrcona |
just use the web staff client? :) |
14:20 |
bos20k |
:) Soon enough... |
14:21 |
bos20k |
Thanks everyone |
14:21 |
Dyrcona |
bos20k: you know about the manualupdates.html page, right? |
14:22 |
bos20k |
Dyrcona: yes, I was just trying to test the auto update stuff. Will do it a different way that should work. |
14:22 |
Dyrcona |
OK. |
14:22 |
Dyrcona |
In my experience auto updates work on Windows, but not Linux. |
14:22 |
jeffdavis |
^ To be clear, "that's what we do" = copy existing updates from production to our upgrade testing server, build the client on the test server with autoupdate_host set to our production URL, manually edit the autoupdate.js file to point at the test server for testing purposes, and copy the new updates from the test server back to production during the upgrade proper. |
14:23 |
jeffdavis |
Cumbersome, but works for us. (And yeah, web client will be nice!) |
14:23 |
bshum |
jeffdavis: That makes more sense to me. I didn't think diverging prod / test without copying something would work cleanly |
14:23 |
bshum |
jeffdavis++ # satisfying my curiousity :D |
14:24 |
Dyrcona |
I'd set the autoupdate host on the testing server at configure time and save a step or two. |
14:24 |
jeffdavis |
Dyrcona: well, we want to test the actual client that we make available to our libraries, and we want that client to have the production autoupdate_host built-in. |
14:25 |
Dyrcona |
But, I also would build everything fresh again on production proper. :) |
14:25 |
jeffdavis |
We have libraries that want the new client available to install several weeks in advance of the upgrade. |
14:26 |
jeffdavis |
Building on prod would be preferable for me, but not possible in that case, alas. :) |
14:26 |
Dyrcona |
See, I'd just tell them No, but I can be a jerk like that. :) |
14:27 |
Dyrcona |
j/k |
14:27 |
bshum |
I think ever since like 2.7, I stopped paying attention to XUL stuff, since it's basically been frozen |
14:27 |
bshum |
All that extra testing sounds boring when nothing is supposed to be different :) |
14:28 |
bshum |
But yay, testing |
15:13 |
bos20k |
I changed the hostname in autoupdate.js but it still says there is no update... |
15:14 |
jeffdavis |
Does your test server have a valid SSL certificate? |
15:14 |
|
rjackson_isl_ joined #evergreen |
15:15 |
bos20k |
jeffdavis: yes, it does |
15:15 |
bos20k |
I also tried changing https:// to http:// in autoupdate.js but that didn't make a difference either. |
15:28 |
Dyrcona |
bos20k: You can always do make updates-client again to be sure. |
15:28 |
bshum |
I wonder if it does matter what you name the thing |
15:29 |
bos20k |
Dyrcona: That has been done many times. |
15:29 |
bshum |
https://developer.mozilla.org/en-US/docs/Toolkit_version_format gets linked to from old https://wiki.evergreen-ils.org/doku.php?id=mozilla-devel:deploying_automatic_updates |
15:30 |
bshum |
and that talks about version numbering |
15:30 |
bshum |
Maybe it doesn't think biblio_2_12 is newer ? |
15:30 |
* bshum |
hasn't really tested |
15:31 |
bshum |
I mean I haven't tested words ahead of the numbers |
15:31 |
bshum |
The doc seems to say numbers, then letters |
15:31 |
bshum |
2.2.0mvlc.0 from the wiki |
15:31 |
bshum |
I'm really just spitballing and guessing; I don't know |
15:32 |
bos20k |
Hmmm, well, the default name is rel_2_12_3 I will try that next. If that doesn't work I will try just 2_12_3 |
15:33 |
bos20k |
Or maybe even 2.12_3... |
15:34 |
Dyrcona |
bos20k: The stamp id is not the version number. I skip stamp id and specify STAFF_CLIENT_VERSION when building. |
15:35 |
Dyrcona |
I'd have to check again how the version is determined from the STAMP_ID. |
15:36 |
Dyrcona |
bos20k: Probably. |
15:36 |
Dyrcona |
I believe the version needs to begin with digits or it gets confused, and use dots, not underscores for best results. |
15:39 |
bos20k |
Yup, don't mess with STAFF_CLIENT_STAMP_ID... It offers to update now. Now to clean up my mess and test the procedure again. |
15:40 |
bos20k |
Thanks again! |
16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:38 |
|
maryj joined #evergreen |
17:07 |
|
mmorgan left #evergreen |
17:29 |
cesardv |
random fact: apparently mongoDB built a CI server called Evergreen https://jira.mongodb.org/browse/EVG |
17:37 |
berick |
huh, this is the first time i've made the connection of "ever green" to "always good/OK/GO" -- i'm guessing that was the motivation for the name. |
17:38 |
berick |
here I was just thinking about trees |
17:39 |
cesardv |
berick: they do have a green basil type of "leaf" as their logo |
17:40 |
berick |
cesardv: indeed, matching the color of the 'success' blocks on their test coverage grids |
17:40 |
berick |
(presumably, looks close) |
17:40 |
cesardv |
berick: yep definitely could be |
17:42 |
rhamby |
cesardv: our trademark requires they enter enter the realm of library services for infringment ... once they do though ... POW ZOOM TO THE MOON! |
17:43 |
phasefx |
unless we were Apple or somebody huge, then they'd sue or at least send nasty letters no matter what the domain :) |
01:36 |
|
BigRig joined #evergreen |
01:37 |
|
mnsri_ joined #evergreen |
01:39 |
|
abneiman joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
05:27 |
|
pinesol_green` joined #evergreen |
05:28 |
|
Bmagic_ joined #evergreen |
05:29 |
|
jeffdavi1 joined #evergreen |
10:13 |
Dyrcona |
Plus, it's easier to cherry-pick all of the commits and sign them all at once. :) |
10:14 |
Dyrcona |
I should see the fifth element. |
10:15 |
|
frank___ joined #evergreen |
10:15 |
frank___ |
Hi all, I am still trying to upgrade from 2.8.4 to 2.12.3, (from one sorver to another too), all the migration is fine, but when I test creating a marc record something weird hapends, for example, If I create/import a new record with this "©" character, it is saved in the database with an strange character "�", but if I re-open the same marc record register, and replace the character with the correct one it is saved correctl |
10:16 |
bshum |
Dyrcona: WHAT? You haven't seen the Fifth Element?! |
10:16 |
Dyrcona |
No, I have not, just bits and pieces. |
10:17 |
|
Freddy_Enrique joined #evergreen |
10:30 |
Dyrcona |
You could try that and see if it works better with a new record. |
10:30 |
frank___ |
ok, let me try |
10:33 |
Dyrcona |
phasefx++ gmcharlt++ |
10:35 |
abneiman |
Dyrcona++ for 1208875 test -- will make lots of people happy! |
10:51 |
dbs |
frank___: that sounds very familiar, I think we fought a similar battle when we upgraded to 2.9 or 2.10 (lots of French in use here)... I'll try to look at my notes about that |
10:52 |
dbs |
frank___: but check first to be 100% sure that your MARC record templates are correctly saved in UTF8 encoding |
10:52 |
dbs |
(our battle had more to do with MARC record copy catalogying from Z39.50 I think) |
16:12 |
* dbs |
does not enjoy reliving last September |
16:21 |
|
b_bonner joined #evergreen |
16:27 |
frank___ |
dbs: let me try |
16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:34 |
|
jwoodard joined #evergreen |
16:35 |
frank___ |
dbs: It works |
16:35 |
frank___ |
excellent |
05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
07:09 |
|
rjackson_isl joined #evergreen |
07:27 |
|
rlefaive joined #evergreen |
07:31 |
|
JBoyer joined #evergreen |
13:19 |
jonadab |
Ah. I was thinking more deletions than additions usually means the code got easier to maintain. |
13:20 |
Dyrcona |
Well, it did, since these files are separate from the others. |
13:20 |
Dyrcona |
Most of these are one shots, too. |
13:43 |
jeff |
has anyone here written tests (pgtap or other) for circ policies? |
13:44 |
jeff |
"if i check this item out to this patron it should go out for this long / with this rule? even if you were just testing circ matrix matchpoints exclusively to start... |
13:45 |
Dyrcona |
No, but I have used the database functions to check that certain rules are working as expected. |
13:47 |
jeff |
Dyrcona: for your syrup install(s), are staff logging into syrup with their evergreen credentials, or are you setting a password for each syrup-using staff member in syrup itself? |
13:47 |
Dyrcona |
jeff: I think they're using their evergreen credentials, but I wasn't here for the initial setup. |
13:47 |
JBoyer |
I don't know if I understand databases anymore. I take a query with 7 inner joins and 12 outer, add *9 more* outer joins and exec time goes from 184 seconds to 41. Consistently (+- a couple seconds; it's not caching that helps). |
13:48 |
Dyrcona |
JBoyer: The magic of indexes.... :) |
13:48 |
JBoyer |
jeff, I haven't written circ policy tests, but it seems like it would take significant setup to actually test properly. |
13:49 |
jeff |
JBoyer: could be that one or all of the additional joins are forcing the planner to make a decision it wouldn't normally make -- and it ends up being a better decision after all! |
13:49 |
JBoyer |
I suppose I should throw a couple EXPLAINs at it, that should make for some interesting reading... |
13:50 |
JBoyer |
jeff, Oh, re: policy testing, are you thinking just some tests that you can run against your own real data to make sure things work the way you expect? |
13:50 |
jeff |
JBoyer: right. |
13:50 |
Dyrcona |
I'm looking through some of my old stuff to see what I've got. |
13:51 |
JBoyer |
That does sound interesting. |
13:52 |
JBoyer |
Dyrcona, Sure, but it has a built in reminder to update the check to reflect the new policy. ;) |
13:52 |
Dyrcona |
heh |
13:53 |
Dyrcona |
IIRC, I mostly ran stuff in the database with the find_circ_matrix_matchpoint and related functions. |
13:56 |
jeff |
and for the exhaustive test, you just join actor.usr with asset.copy and actor.org_unit... |
13:59 |
Dyrcona |
heh |
13:59 |
Dyrcona |
Well, you basically need some representative transactions where you know what the outcome should be ahead of time....but you knew that. |
13:59 |
* jeff |
nods |
16:25 |
Dyrcona |
Oh. I think I may have copied the wrong apache2.conf for websockets. |
16:26 |
Dyrcona |
Looks like I got the Apache 2.2 version and this host is running apache 2.4. |
16:29 |
Dyrcona |
Yeap. |
16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:58 |
|
frank_guel joined #evergreen |
16:59 |
|
frank_guel joined #evergreen |
17:03 |
frank_guel |
Hi all, I am still trying to upgrade from 2.8.4 to 2.12.3, (from one sorver to another too), all the migration is fine, but when I test creating a marc record something weird hapends, for example, If I create/import a new record with this "©" character, it is saved in the database with an strange character "�", but if I re-open the same marc record register, and replace the character with the correct one it is saved correc |
17:04 |
frank_guel |
I tested in two diferent server and is the same, |
17:06 |
|
mmorgan left #evergreen |
17:58 |
|
Freddy_Enrique joined #evergreen |
18:05 |
|
Freddy_Enrique joined #evergreen |