| Time |
Nick |
Message |
| 01:54 |
|
abowling1 joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
JBoyer joined #evergreen |
| 07:07 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 08:07 |
|
abowling joined #evergreen |
| 08:22 |
|
gsams_ joined #evergreen |
| 08:22 |
|
rhamby_ joined #evergreen |
| 08:22 |
|
Shae_ joined #evergreen |
| 08:27 |
csharp |
hmm - my 2.12 test server's marc import from z39.50 is not respecting unicode |
| 08:28 |
csharp |
it displays fine in z39 view and in MARC edit, then after import the unicode is replaced by non-unicode symbols |
| 08:28 |
csharp |
not sure where to look |
| 08:30 |
csharp |
search for what the "Import" button does leads me to OpenILS/xul/staff_client/server/cat/z3950.js, but I lose the thread there |
| 08:32 |
csharp |
okay - I found the perl |
| 08:35 |
|
kmlussier joined #evergreen |
| 08:36 |
* csharp |
wonders if running through XML::LibXML is causing it |
| 08:45 |
* csharp |
runs off to see if it's happening on master too |
| 08:54 |
csharp |
okay - it's working fine on my master test server, but broken on 2.12 test server |
| 08:59 |
|
_adb joined #evergreen |
| 08:59 |
|
Dyrcona joined #evergreen |
| 09:04 |
csharp |
ok - definitely not a problem with 2.12 - something local |
| 09:07 |
|
kmlussier joined #evergreen |
| 09:16 |
|
yboston joined #evergreen |
| 09:26 |
|
Dyrcona joined #evergreen |
| 09:39 |
|
finnx joined #evergreen |
| 09:41 |
dbs |
csharp: if the code is identical, maybe a difference in either the locale of the server, or the locale of the database? |
| 09:42 |
dbs |
Alternately, difference in where yaz packages are getting pulled from? |
| 09:43 |
dbs |
Or more commonly, actually, duplicated database functions (public.maintain_control_numbers vs. evergreen.maintain_control_numbers) where the old one came from a db restore and the new one was created during upgrade, but isn't first in the search path |
| 09:52 |
pinesol_green |
Showing latest 5 of 13 commits to Evergreen... |
| 09:52 |
pinesol_green |
[evergreen|Mike Rylander] Add moment.js to the offline asset list - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=40079db> |
| 09:52 |
pinesol_green |
[evergreen|Mike Rylander] Remove confusing "session" tab from the offline menu entry -- the code will figure out the correct default tab - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b77f4cb> |
| 09:52 |
pinesol_green |
[evergreen|Mike Rylander] Reorder the tabs and adjust the default based on logged-in-ness - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=346cba8> |
| 09:52 |
pinesol_green |
[evergreen|Mike Rylander] Fix the "404 asset" test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=23886b4> |
| 09:53 |
pinesol_green |
[evergreen|Mike Rylander] The ngToast maintainers decided to trick us with a new directory name. Thanks. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f1e2631> |
| 09:57 |
kmlussier |
And...I just remembered that I was planning to write a release notes entry for that one before merging. I'll put that on my to-do list. |
| 10:00 |
csharp |
dbs: ooh - I'll check those possibilities out thanks! |
| 10:14 |
|
jvwoolf joined #evergreen |
| 10:21 |
csharp |
hmm looks like the maintain_control_numbers function is the issue from what I can tell from the code |
| 10:21 |
csharp |
dbs++ |
| 10:24 |
csharp |
hmm - creating that function doesn't schema-qualify it - should it? |
| 10:24 |
csharp |
CREATE OR REPLACE FUNCTION maintain_control_numbers() RETURNS TRIGGER AS $func$ |
| 10:25 |
csharp |
which is why the right one is in public and the wrong one is in evergreen, and since I'm evergreen and the search_path is "$user",public.... |
| 10:26 |
Dyrcona |
csharp: Probably. |
| 10:26 |
Dyrcona |
:) |
| 10:31 |
* csharp |
creates bug |
| 10:48 |
Dyrcona |
There goes Bmagic pimping docker, again. :) |
| 10:48 |
Bmagic |
:) |
| 10:48 |
Dyrcona |
Good suggestion, just the same. |
| 10:48 |
Bmagic |
I liked your email as well |
| 10:49 |
kmlussier |
Bmagic++ Dyrcona++ |
| 10:49 |
Dyrcona |
I sent another, if you haven't seen it. |
| 10:50 |
Dyrcona |
Ubunut.... ;) |
| 10:50 |
Dyrcona |
I should proofread before hitting send. :) |
| 10:50 |
Bmagic |
that is the one to which I am referring |
| 10:51 |
Dyrcona |
OK. :) |
| 10:52 |
Dyrcona |
I'm trying to find a bug to bug you (Bmagic) about. |
| 10:52 |
Dyrcona |
I was going to look at it, or I tried, but ran out of time. |
| 10:52 |
Bmagic |
ok, that was cryptic |
| 10:53 |
Dyrcona |
Yeah, trouble is, I've forgotten which bug. :( |
| 10:54 |
Dyrcona |
I recall kmlussier commenting about adding a regression test, and that's what I was going to try and do. |
| 10:54 |
kmlussier |
Oh, it's the one for transferring volumes to another record. |
| 10:55 |
kmlussier |
bug 1411422 |
| 10:55 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.12 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
| 10:56 |
Dyrcona |
Yeah, that's it. |
| 10:58 |
Bmagic |
oh yeah, an oldie but a goodie |
| 10:59 |
Bmagic |
that code merges onto 2.11.0 but I can't vouch for anything newer |
| 11:00 |
kmlussier |
Bmagic: The issue with that code is that is has passed user testing, but it needs a regression test. |
| 11:01 |
Bmagic |
right, sounds like today will be EG developing day! |
| 11:01 |
Bmagic |
(for me) |
| 11:01 |
Dyrcona |
I:) |
| 11:01 |
Bmagic |
I'm working on getting bug 1655158 working with the latest master right now |
| 11:01 |
pinesol_green |
Launchpad bug 1655158 in Evergreen "Patron Search by date of birth" [Wishlist,Confirmed] https://launchpad.net/bugs/1655158 |
| 11:02 |
Bmagic |
everyone just needs to stop committing to master :) |
| 11:02 |
Dyrcona |
:) |
| 11:04 |
* kmlussier |
quickly finds something else to merge that will affect Bmagic's search by date of birth branch. |
| 11:04 |
Bmagic |
ahhhhhhhhhhhhhhhh |
| 11:12 |
Dyrcona |
Whee! I'm also getting a conflict merging something into master for testing. |
| 11:14 |
Dyrcona |
Ah, fun. My own coded causing the conflict. :) |
| 11:14 |
Dyrcona |
At least I know how to resolve it. :) |
| 11:33 |
|
rjackson_isl joined #evergreen |
| 11:50 |
miker |
berick++ #stealing the jQuery branch back from me |
| 11:51 |
* miker |
forget to release it |
| 11:51 |
miker |
s/branch/bug |
| 11:57 |
kmlussier |
berick++ miker++ |
| 12:00 |
Dyrcona |
That moment when you go to reply to a bug comment that you received in email, and someone else has added a comment in the meantime that affects what you were going to say. |
| 12:00 |
Dyrcona |
Guess it will wait for after lunch. :) |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:10 |
berick |
Dyrcona: you picked the wrong week to quit sniffing glue |
| 12:12 |
|
khuckins__ joined #evergreen |
| 12:12 |
Dyrcona |
berick: Mu.... |
| 12:13 |
Dyrcona |
Thing is, I agree with miker, but I feel inclined to defer to gmcharlt who is RM. :) |
| 12:14 |
|
sandbergja joined #evergreen |
| 12:29 |
|
terran joined #evergreen |
| 12:39 |
|
Christineb joined #evergreen |
| 13:13 |
kmlussier |
Yay! More merge conflicts! |
| 13:15 |
Dyrcona |
It seems to be the day for it. |
| 13:16 |
kmlussier |
Every branch I've tried to test today has one. I think I can resolve this one on my own. |
| 13:16 |
kmlussier |
Of course, that's what I said a couple of weeks ago before breaking 2.12 |
| 13:18 |
kmlussier |
That is, one week ago. Time is moving very slowly. |
| 13:20 |
Dyrcona |
Yeah. We could be approaching an event horizon. |
| 13:21 |
* Dyrcona |
greps the code for examples of xlst_process used int he database, specifically for mods transformation. |
| 13:24 |
Dyrcona |
Easy enough... :) |
| 14:00 |
Dyrcona |
@marc 035 |
| 14:00 |
pinesol_green |
Dyrcona: A control number of a system other than the one whose control number is contained in field 001 (Control Number), field 010 (Library of Congress Control Number) or field 016 (National Bibliographic Agency Control Number). (Repeatable) [a,z,6,8] |
| 14:00 |
* Dyrcona |
ponders what to call it in the spreadsheet. |
| 14:03 |
dbs |
That needs a 'q' as well. Dang old data. |
| 14:04 |
dbs |
dbs-- # was thinking of 020, duh. |
| 14:04 |
dbs |
@marc 020 |
| 14:04 |
pinesol_green |
dbs: The ISBN assigned to a monographic publication by designated agencies in each country participating in the program. The field may include terms of availability and canceled or invalid ISBNs. It may be repeated for multiple numbers associated with the item (e.g., ISBNs for the hard bound and paperback manifestations; ISBNs for a set as a whole and for the individual parts in the set). (Repeatable) (1 more message) |
| 14:04 |
dbs |
@more |
| 14:04 |
pinesol_green |
dbs: [a,c,z,6,8] |
| 14:04 |
dbs |
That needs a 'q' as well. Dang old data. |
| 14:04 |
dbs |
There, now I feel better. |
| 14:04 |
jeffdavis |
ha! |
| 14:06 |
* Dyrcona |
contemplates writing the script in Python. |
| 14:11 |
Dyrcona |
Or, I may just XML::SAX::Base or something similar, though just throwing the xml in XML::Simple might be good enough. |
| 14:16 |
* dbs |
stares at "Cannot write to '/openils/var/web/reporter/1282/4037/43819/report-data.csv' at /openils/bin/clark-kent.pl" and wonders why |
| 14:16 |
dbs |
ownership is all good. permissions are all good. can touch a file in that directory as the opensrf user. |
| 14:18 |
jeff |
unintentional cartesian join filling the disk? |
| 14:19 |
jeff |
oh, that's being thrown on open(). nevermind. |
| 14:20 |
dbs |
jeff: no it returns immediately and there's 80GB free. yeah |
| 14:20 |
dbs |
It's an NFS share. Maybe some lingering permission/ownership issues from when it was first mounted and I had to chown due to opensrf having a different uid? |
| 14:21 |
csharp |
sounds familiar |
| 14:21 |
dbs |
@later tell NFS "Get over it!" |
| 14:21 |
pinesol_green |
dbs: The operation succeeded. |
| 14:21 |
csharp |
we had lots of NFS ownership hell issues a few years ago |
| 14:21 |
dbs |
csharp++ |
| 14:22 |
* NFS |
gets over it |
| 14:23 |
jeffdavis |
I think the opensrf user has a designated uid in debian/ubuntu as of a few years ago... |
| 14:24 |
* jeff |
nods |
| 14:25 |
jeff |
that may not help your nfs issues, depending on the underlying cause. |
| 14:25 |
dbs |
Some other reports do get written successfully, fwiw |
| 14:26 |
dbs |
@dice 1d20 |
| 14:26 |
pinesol_green |
dbs: 10 |
| 14:27 |
* csharp |
fights with acq vandelay on 2.12 |
| 14:28 |
JBoyer |
\me had intended to send some doc changes re: OpenSRF's uid. |
| 14:28 |
* JBoyer |
"intends" to do a lot of stuff. :/ |
| 14:28 |
csharp |
symptom: user gets "FILE UPLOAD ERROR" alert and 2017-08-30 14:00:46 next-brick01-head open-ils.acq: [ERR :20387:Order.pm:1483:1504112854294049] unable to read MARC file is in the logs |
| 14:28 |
csharp |
that error comes up if the data isn't retreived from the cache |
| 14:29 |
csharp |
manual "memcdump | grep vand" comes up empty and not sure where to go from there |
| 14:29 |
JBoyer |
csharp, vandelay upload dir shared via NFS? |
| 14:30 |
JBoyer |
(that is, it needs to be) |
| 14:30 |
csharp |
JBoyer: yes, actually |
| 14:30 |
JBoyer |
www-data group have the write bit? |
| 14:30 |
csharp |
no |
| 14:30 |
csharp |
hmmm |
| 14:30 |
JBoyer |
Well, we run apache as www-data, if you run it as opensrf that may not matter. |
| 14:31 |
csharp |
744 owned by opensrf:www-data |
| 14:31 |
csharp |
we do run apache as opensrf |
| 14:31 |
JBoyer |
Ah, give 764 a spin. |
| 14:31 |
JBoyer |
Oh. Probably not that then. :? |
| 14:31 |
Dyrcona |
csharp: Are the opensrf user ids the same on both machines? :) |
| 14:32 |
csharp |
Dyrcona: fortunately, yes :-) |
| 14:32 |
Dyrcona |
That one, I make sure of, too. |
| 14:32 |
csharp |
interestingly, I see files there that were created by a tester, but no longer |
| 14:32 |
csharp |
well that is to say, we can no longer upload |
| 14:35 |
dbs |
Oh hey, turns out our reports problem only occurs when we request Excel format output. |
| 14:35 |
berick |
csharp: vandelay <importer> directory looks right in opensrf.xml? |
| 14:36 |
berick |
... and all NFS mounts are confirmed to be mounted? |
| 14:36 |
csharp |
berick: yes and yes |
| 14:36 |
csharp |
I just tested creating files as opensrf from each location |
| 14:37 |
berick |
i don't think creation is the problem |
| 14:37 |
JBoyer |
dbs, oh. That sounds vaguely familiar. Do you have all of the various Excel::Whatevs perl mods that Clark needs for that? I thought there was a period that a couple had to be added by hand and if they were missing I'd get that error instead of the expected exploding perl. |
| 14:37 |
berick |
csharp: problem is acq trying to read the files post-creation |
| 14:37 |
Dyrcona |
Probably missing Excel::Writer::XLSX. |
| 14:38 |
csharp |
berick: should there be a vandelay cache item in memcache? from the perl it looks like it would fail with that error because it couldn't read from the cache |
| 14:38 |
|
jvwoolf joined #evergreen |
| 14:38 |
dbs |
... or not, as I set excel_format = TRUE and it runs happily again? (error message was pointing to output_csv() function anyway) |
| 14:38 |
csharp |
my $data = $cache->get_cache("vandelay_import_spool_$key"); |
| 14:39 |
csharp |
my $filename = $data->{path}; |
| 14:39 |
csharp |
unless(-r $filename) { |
| 14:39 |
csharp |
$logger->error("unable to read MARC file $filename"); |
| 14:39 |
csharp |
$e->rollback; |
| 14:39 |
csharp |
return OpenILS::Event->new('FILE_UPLOAD_ERROR', payload => {filename => $filename}); |
| 14:39 |
csharp |
} |
| 14:39 |
berick |
csharp: you foudn what I was just looking at... |
| 14:39 |
csharp |
(sorry for paste noise) |
| 14:39 |
berick |
so, yeah, lack of memcache entry is bad |
| 14:42 |
dbs |
JBoyer: should be there, it was a fresh 2.12 install, but I'll go back and check |
| 14:42 |
berick |
csharp: unrelated, getting too-many-redirects on nginx-proxied VMs here too. ditto vandelay export. have not investigated yet. |
| 14:43 |
csharp |
berick: I have some info on that (found by abowling & co.) |
| 14:43 |
dbs |
Dyrcona: Excel::Writer::XLSX is there |
| 14:44 |
berick |
csharp: oh, cool |
| 14:44 |
Dyrcona |
dbs: Just a stab in the dark. |
| 14:44 |
berick |
csharp: so, the cache key is created during marc file upload. WWW/Vandelay.pm |
| 14:44 |
dbs |
Dyrcona: thanks! I just feel like stabbing :) |
| 14:44 |
csharp |
berick: was just looking for that |
| 14:45 |
berick |
fair number of logs in there, would expect something useful to be in the log file |
| 14:52 |
berick |
am i crazy or is there no way to edit the copy alert message in webby volcopy editor? |
| 14:52 |
berick |
i see a Default for 'alerts', seems to have no effect |
| 15:02 |
kmlussier |
berick: I think it was kept out while waiting for bug 1676608 to be merged. |
| 15:02 |
pinesol_green |
Launchpad bug 1676608 in Evergreen "Copy Alert Persistence and Suppression Matrix" [Wishlist,New] https://launchpad.net/bugs/1676608 |
| 15:03 |
berick |
aha kmlussier++ |
| 15:03 |
berick |
thanks |
| 15:05 |
kmlussier |
It was on my mind as it was the first branch of the day where I encountered merge conflicts that I couldn't resolve. :) |
| 15:06 |
berick |
:) |
| 15:06 |
berick |
hm, merge conflicts as a memory improvment tool |
| 15:21 |
csharp |
berick: https://pastebin.com/F2pk3pLu - from our no-longer-endlessly-redirecting eg.conf |
| 15:22 |
berick |
csharp: so the problem specifically are the use of 7443 in ServerName and ServerAlias? |
| 15:23 |
Bmagic |
Would you consider it a bug when the system shows deleted copies in the "in-transit" list ? |
| 15:25 |
berick |
csharp: in any event, thanks! probably saved me a bunch of time. i'll experiment... |
| 15:27 |
berick |
csharp++ # fixed my reporter |
| 15:27 |
* berick |
tries the other affected UI's |
| 15:29 |
Dyrcona |
Bmagic: Not if the copies were deleted after they went in transit. |
| 15:30 |
Bmagic |
they were deleted after they went in transit |
| 15:30 |
berick |
doh, vandelay queue -> view marc -> edit tries to open marcedit.xul. will open LP. |
| 15:30 |
dbs |
I guess I should have included my Apache config in my nginx writeup |
| 15:30 |
csharp |
berick: right |
| 15:30 |
csharp |
berick: glad it was helpful |
| 15:31 |
Dyrcona |
Bmagic: Well, I'd consider it a bug that staff could delete in transit copies, but others might disagree with that. |
| 15:31 |
* csharp |
gives abowling and Emerald friends their props |
| 15:31 |
csharp |
they spent a day finding it |
| 15:31 |
berick |
oh, cool, bug 1700635 |
| 15:31 |
pinesol_green |
Launchpad bug 1700635 in Evergreen "webclient: cannot edit MARC records from MARC Batch Import/Export (Vandelay)" [Medium,Confirmed] https://launchpad.net/bugs/1700635 |
| 15:31 |
berick |
abowling++ |
| 15:32 |
berick |
and_emerald_friends++ |
| 15:35 |
dbs |
excel was a red herring, I think I'm back to NFS flakiness for reports not working |
| 15:35 |
berick |
dbs: have you needed to force nginx to clear its cache yet? do you just delete the cache dir? |
| 15:35 |
dbs |
berick: that is exactly what I did |
| 15:35 |
berick |
cool, thanks |
| 15:35 |
dbs |
Brute force, but for the small amount that we're dealing with... |
| 15:36 |
berick |
yeah, still better than no caching |
| 15:40 |
dbs |
that said, I have a custom JS file now named 'wikidata33.js' - heh |
| 16:07 |
Dyrcona |
Bmagic: Y'know there's a setting to prevent copies with certain statuses from being deleted, right? |
| 16:07 |
Dyrcona |
Of course, if you let staff override that..... |
| 16:07 |
Bmagic |
I think I knew that |
| 16:07 |
Dyrcona |
It's a flag on the status. |
| 16:07 |
Bmagic |
It didn't come to mind |
| 16:08 |
Bmagic |
would you agree that deleting a copy that is in transit should also delete the transit? |
| 16:08 |
Dyrcona |
I would, and I was about to mention tmcanna's comment to that effect. |
| 16:09 |
Bmagic |
with the right set of configuration, a system could prevent such deletions, but the opposite is true and therefore we might want to code the possible deletion of the transit row? |
| 16:10 |
Dyrcona |
Well, someone could also decide that deleting copies in transit is OK, and they might want to optionally also delete the transit. |
| 16:10 |
|
Jillianne joined #evergreen |
| 16:10 |
Dyrcona |
Some many knobs.... ;) |
| 16:10 |
Dyrcona |
It's looking like a WWI Uboat. |
| 16:11 |
kmlussier |
ha |
| 16:13 |
Dyrcona |
http://static1.businessinsider.com/image/56bcaa3a2e526519008b67f3-1190-625/a-rare-glance-into-the-heart-of-a-wwi-german-u-boat.jpg |
| 16:13 |
berick |
har, just hit 'z' in top for no reason. was not dissapointed. |
| 16:14 |
gmcharlt |
all the pretty colors... |
| 16:15 |
miker |
Dyrcona: I was thinking something more modern... https://i.pinimg.com/736x/5b/56/34/5b5634ea8949978c0bdd53aa97967e11--boeing--damsel-in-distress.jpg |
| 16:16 |
miker |
"Welcome to the YAOUS flight deck. NO, DON'T TOUCH THAT KNOB!" |
| 16:17 |
Dyrcona |
:) |
| 16:27 |
gmcharlt |
and this, friends, is why you must never, ever let sprawly cats into your cockpit |
| 16:36 |
berick |
Bmagic: when I looked at bug 1655158 yesterday, i recal a 2nd commit that made changes to action.pm. did you squash them into one during your rebase? thought there was some reformatting, too, that i'm not seeing this time. |
| 16:36 |
pinesol_green |
Launchpad bug 1655158 in Evergreen "Patron Search by date of birth" [Wishlist,Confirmed] https://launchpad.net/bugs/1655158 |
| 16:36 |
_adb |
gmcharlt: closest i got: http://i.imgur.com/UvZBECG.gif |
| 16:37 |
Bmagic |
berick: yeah, I opted for the one-liner join,map,grep |
| 16:37 |
gmcharlt |
_adb: indeed (and having seen the full video, I'm glad that the cat made it through OK) |
| 16:37 |
berick |
Bmagic: ah, boo :( that's a beast of a line :) |
| 16:37 |
Bmagic |
I have the while loop still if you prefer |
| 16:38 |
berick |
Bmagic: care if I add some new lines at least? that's kinda nutty |
| 16:38 |
Bmagic |
of course, feel free! |
| 16:38 |
berick |
thanks |
| 16:39 |
|
finnx left #evergreen |
| 16:43 |
miker |
berick: looking at the jquery branch, what do you think about having /common/build/ in the .gitignore, rather than plain /common/? |
| 16:46 |
berick |
miker: that makes sense, but can't remember if git is smart enough to ignore the parent for an ignored child directory |
| 16:46 |
berick |
if the only sub-dir is ignored, i mean, which is the case here |
| 16:47 |
berick |
easy enough to test |
| 16:47 |
miker |
ah... you mean getting warnings about an "empty" common to git-add? |
| 16:47 |
miker |
yeah, I'll test that |
| 16:47 |
berick |
yeah, exactly |
| 16:48 |
miker |
if it doesn't seem to care, I'll add build. otherwise, I'll leave it as you have it |
| 16:48 |
miker |
maybe adjust the comment |
| 16:49 |
berick |
miker: just tested, looks like it's good. |
| 16:49 |
miker |
rock |
| 16:49 |
berick |
no warnings when the sub-dir is ignored |
| 16:49 |
miker |
I'll adjust, remove the comment, and squash into your commit |
| 16:49 |
berick |
cool |
| 16:58 |
pinesol_green |
[evergreen|Mike Rylander] LP#1642086: Smallest possible JQuery patch that could work... - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=92dce93> |
| 16:58 |
pinesol_green |
[evergreen|Bill Erickson] LP#1642086 TPAC Jquery path repair, .gitignore, karma - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5120189> |
| 16:58 |
pinesol_green |
[evergreen|Mike Rylander] LP#1642086: Adjust offline resources for jquery support - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=74e1fba> |
| 16:59 |
miker |
I think I should add an upgrade note about ctx.want_jquery... |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:04 |
pinesol_green |
[evergreen|Mike Rylander] LP#1642086: Relase note for jQuery support - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=18d1064> |
| 17:16 |
|
kakious joined #evergreen |
| 17:16 |
kakious |
Anyone free to help or not right now? |
| 17:18 |
kmlussier |
kakious: Some people may have gone home for the day, but some folks may still be around. |
| 17:18 |
* kmlussier |
is running out to get dinner. |
| 17:19 |
kakious |
Okay, I'll wait. Just let me know if you are free or not. |
| 17:20 |
berick |
hi kakious, welcome, probably best to just ask your question. people will answer as they can. |
| 17:20 |
Bmagic |
kakious: go ahead |
| 17:21 |
kakious |
Okay, got it. I added a book to the catalog, but it seems I can not add physical copys to it. So It says there are no copys available. The option to add it is greyed out and does not show up. |
| 17:22 |
|
jvwoolf left #evergreen |
| 17:29 |
kakious |
I have screenshots if needed |
| 17:30 |
dbwells |
kakious: are you able to post the screenshots somewhere? |
| 17:31 |
kakious |
I have it on imgur. Let me post links one second. |
| 17:31 |
kakious |
SC1: i.imgur.com/Z6vJHqq.png |
| 17:31 |
kakious |
SC2: i.imgur.com/Ce5fqFb.png |
| 17:33 |
dbwells |
kakious: Do you just have the one organizational unit? If so, you may need to tell the system that unit can hold volumes. |
| 17:34 |
dbwells |
Out of the box, the "top" unit cannot. |
| 17:36 |
kakious |
So, do I change that in Organizational Types? |
| 17:37 |
dbwells |
kakious: yes, a check box for "Can Have Volumes and Copies" |
| 17:38 |
dbwells |
kakious: after changing that, I cannot recall if you need to run autogen.sh and/or what to restart. Haven't touched those settings locally in a loooooong time :) |
| 17:38 |
dbwells |
If that's the issue at all. |
| 17:39 |
kakious |
Ahh okay. I am currently running autogen and restarting the system just to be safe |
| 17:40 |
pinesol_green |
[evergreen|Cesar Velez] LP#1683575 - Webstaff fix silent fail of bad barcodes in ItemStatus - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4fc789e> |
| 17:40 |
dbwells |
kakious: Do you have just the one org unit? |
| 17:42 |
dbwells |
kakious: There is also a sample data set you can load if you are just kicking the tires. :) |
| 17:42 |
kakious |
I do. I could make more if needed |
| 17:42 |
kakious |
And that fixed it! |
| 17:43 |
kakious |
dbwells : Thanks! |
| 17:45 |
dbwells |
kakious: great, no problem. Glad to help. Having a single org unit isn't too common with most folks around here, but there is no reason it shouldn't work, so if you end up hitting bugs, those will be good to report. Good luck! |
| 17:46 |
kakious |
Okay, thanks! Oh, also what is the difference between volumes and copies on here? |
| 17:51 |
Bmagic |
berick: my thought on the join/map/grep was that it might be faster than the while loop approach. It makes for a long line, and it probably deserves some line breaks. |
| 17:53 |
dbwells |
kakious: Due to history and difficulty in naming things, "volumes" in most interfaces means "call number". |
| 17:57 |
dbwells |
kakious: Evergreen fundamentally uses a three-layer organization for tracking "things": Record->Call Numbers (aka Volumes)->Copies (aka Items). |
| 18:01 |
kakious |
Okay |
| 18:02 |
kakious |
Thanks for helping me. Bye! |
| 18:06 |
dbwells |
Bmagic: I can play cycle-miser with the best of them, but I feel pretty confident a loop there would never be a meaningful bottleneck. |
| 18:06 |
berick |
Bmagic: ah, well, compared to the speed of say, talking to the database, any speed up that may have provided would be quickly lost in the noise. |
| 18:07 |
Bmagic |
the other reason was to follow suit with the rest of the code in that block |
| 18:10 |
berick |
Bmagic: consistency is def. appreciated |
| 18:11 |
Bmagic |
I guess I don't care either way, I have the working while loop saved in a text file somewhere if we want to go back to it |
| 18:11 |
berick |
Bmagic: any thoughts on the latest comments? |
| 18:11 |
berick |
re: matching |
| 18:12 |
Bmagic |
I see your point about 2~12 , and it's valid |
| 18:13 |
Bmagic |
The comments leading up to that between terran and I were hammering out those same details, and I thought the conclusion was we wanted it to be "wiggly" |
| 18:14 |
berick |
yeah, i'm just adding a voice to that discussion (now that I'm paying attention). |
| 18:14 |
Bmagic |
I'm not opposed to changing it to match your day/month idea |
| 18:15 |
* berick |
nods |
| 18:16 |
* Bmagic |
is headed home for the day, see yall tomorrow |
| 18:16 |
berick |
in any event, i'm stepping away for now. will resume... |
| 18:16 |
berick |
jinx |
| 18:16 |
Bmagic |
:) |
| 21:02 |
|
jvwoolf joined #evergreen |
| 21:07 |
|
jvwoolf1 joined #evergreen |
| 21:35 |
|
jvwoolf1 left #evergreen |
| 23:47 |
phasefx |
grabbing 1061 |
| 23:53 |
pinesol_green |
[evergreen|Bill Erickson] LP#1709521 Webstaff show recent patrons - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4962d99> |
| 23:53 |
pinesol_green |
[evergreen|Bill Erickson] LP#1709521 Release notes for show recent patrons - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e86fdc7> |
| 23:53 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1709521: Tweak description for new OU setting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=930104e> |
| 23:53 |
pinesol_green |
[evergreen|Jason Etheridge] lp1709521 stamping schema upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5fdb9b0> |
