Time |
Nick |
Message |
04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:14 |
|
rjackson_isl joined #evergreen |
07:31 |
|
agoben joined #evergreen |
07:38 |
|
Dyrcona joined #evergreen |
07:54 |
csharp |
jeff: on my server with SSDs and nothing else going on your index fix took 4 mins |
08:37 |
|
mmorgan joined #evergreen |
08:48 |
|
maryj joined #evergreen |
08:52 |
jeff |
csharp: thanks! |
09:01 |
|
_adb joined #evergreen |
09:19 |
|
collum joined #evergreen |
09:27 |
|
jvwoolf joined #evergreen |
09:35 |
|
yboston joined #evergreen |
09:59 |
Dyrcona |
Yeap, grunt all blows up on me again on a fresh install on Ubuntu Xenial. This time I'm installing rel_2_12 with no customizations. |
10:02 |
Dyrcona |
I can try again with a fresh Debian 8. |
10:02 |
JBoyer |
Dyrcona, Not that I think this is a good thing to do full time, but if you just do a grunt build does it work? (i.e. skipping the test) |
10:02 |
Dyrcona |
I am installing the developer prereqs and not building node from source. |
10:02 |
Dyrcona |
JBoyer: I'll try that. It does look like a test that's failing. |
10:03 |
csharp |
npm feels fragile to me - kinda like ruby gems |
10:03 |
Dyrcona |
The build "succeeds" with this message from cssmin:combine : |
10:03 |
Dyrcona |
>> Destination not written because minified CSS was empty. |
10:04 |
csharp |
or even CPAN, though that's been more consistently stable than I've seen the other two be |
10:04 |
Dyrcona |
csharp: Node feels fragile to me, not just npm, worse than ruby gems. |
10:04 |
JBoyer |
I think the last time I was having issues with grunt test it was something of ours, but it's been a minute. |
10:05 |
Dyrcona |
I get that same reference error from yesterday. |
10:08 |
Dyrcona |
Hmm... Something isn't getting loaded in the tests, I assum. |
10:08 |
Dyrcona |
Assume, even. |
10:09 |
JBoyer |
It's ok, dropping the e in Assumr would be hipster, but dropping the e from Assum is tres Unix. |
10:09 |
Dyrcona |
It's complaining about the angular.module() line at the top of services/core.js. |
10:09 |
Dyrcona |
heh. |
10:09 |
Dyrcona |
I'll ignore it and get on with things. |
10:11 |
JBoyer |
Hmm. That almost sounds familiar. ngCookies specifically... To the Googles. |
10:14 |
Dyrcona |
ReferenceError: Can't find variable: angular at /home/opensrf/Evergreen/Open-ILS/web/js/ui/default/staff/services/core.js:6 |
10:14 |
Dyrcona |
Nothing specific about ngCookies |
10:14 |
JBoyer |
Delightful: https://stackoverflow.com/questions/18287476/cause-of-angular-error-error-no-module-ngcookies |
10:17 |
Dyrcona |
Hah. |
10:17 |
JBoyer |
I also sometimes forget that JS cares about the order that things appear in source fils. |
10:17 |
JBoyer |
files too. |
10:17 |
Dyrcona |
I get an unexpected error on that URL. |
10:17 |
Dyrcona |
I'll try again later. |
10:22 |
JBoyer |
I'm not seeing anything obvious that would imply that's the issue here (loading angular modules out of order) so that may not be it. |
10:24 |
Dyrcona |
I'll see if the webclient works. |
10:25 |
Dyrcona |
I use it more than the xul client with this vm anyway. |
10:38 |
|
Jillianne joined #evergreen |
10:38 |
|
mdriscoll joined #evergreen |
10:50 |
|
Christineb joined #evergreen |
10:52 |
|
Freddy_Enrique joined #evergreen |
10:52 |
Bmagic |
I am attempting to investigate a hold that should have been filled, and reaching out for some ideas |
10:52 |
Freddy_Enrique |
Good morning Evergreen Folks :) |
10:53 |
Bmagic |
Freddy_Enrique: Good morning! @coffee |
10:53 |
Freddy_Enrique |
Yeah.. I need some coffee, urgent |
10:54 |
csharp |
TFW you start a new git branch and discover that a past version of yourself has already opened a branch and done some of the work you were planning to do |
10:54 |
Bmagic |
So, I have this title hold from May 28th. Only 2 copies in the consortium are not age based protected. These two copies are listed in the hold_copy_map. These copies have been checked out for weeks. |
10:54 |
Bmagic |
@coffee [Freddy_Enrique] |
10:54 |
* pinesol_green |
brews and pours a cup of Kenya Peaberry Muthunzunni Estate, and sends it sliding down the bar to Try restarting apache. |
10:54 |
Bmagic |
lol |
10:55 |
berick |
heh |
10:55 |
Bmagic |
@coffee Freddy_Enrique |
10:55 |
* pinesol_green |
brews and pours a cup of Kenya AA Kiaora Estate Full City Roast, and sends it sliding down the bar to Freddy_Enrique |
10:56 |
Bmagic |
The hold from May 28th is for Library A. But a hold placed on June 14th was captured for Library B. The copy belongs to Library C. All libraries are in different systems, each with the same proximity. |
10:57 |
Bmagic |
The hold targeter had 2 weeks to target the available copy for the May 28th hold |
10:57 |
Bmagic |
And it hapily filled the new hold for Library B..... |
10:59 |
Freddy_Enrique |
Jajaja, thanks guys |
10:59 |
Dyrcona |
Bmagic: Does it help to say, "Holds are complicated?" :) |
10:59 |
mmorgan |
Bmagic: Could the patron with the May 28th hold have a block that prevents hold capture? |
11:00 |
Bmagic |
mmorgan: thanks, I will double check that |
11:00 |
Bmagic |
Dyrcona: lol |
11:00 |
|
kmlussier joined #evergreen |
11:00 |
Dyrcona |
Or had a block, or suspended the hold, or .... was the moon full? :) |
11:03 |
Bmagic |
would the copy be in the hold_copy_map if that copy didn't satisfy the action.hold_request_permit_test ? |
11:03 |
Dyrcona |
It might. I don't remember. |
11:04 |
berick |
Bmagic: a copy does not have to pass action.hold_request_permit_test to appear in the hold_copy_map. |
11:04 |
Bmagic |
i see |
11:05 |
berick |
only directly targeted (or op-captured) copies have to pass the test |
11:06 |
Bmagic |
I think we are getting warm |
11:06 |
Bmagic |
mmorgan: no penalties |
11:11 |
pinesol_green |
[evergreen|Jason Etheridge] lp1653998 webstaff redirect to login page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=518023b> |
11:11 |
mmorgan |
ok. It's a title level hold and not suspended as Dyrcona mentioned? |
11:12 |
Bmagic |
right, not suspended, it's title |
11:12 |
|
petyo joined #evergreen |
11:12 |
Bmagic |
there are only two copies that are not age protected |
11:12 |
Bmagic |
and another hold was filled by a copy that clearly could have gone to the May 28th hold |
11:13 |
Bmagic |
the system had 2 weeks! to target that hold while that copy had a status of 0 |
11:13 |
Bmagic |
I just ran select * from action.hold_request_permit_test(150,150,2816987,129910,125311) - and found success = 't' |
11:13 |
Dyrcona |
Bmagic: The hold might have been suspended during that two weeks. |
11:14 |
Dyrcona |
Or part of it. |
11:14 |
Bmagic |
Auditor.action_hold_request_history tells me that the hold was never suspended |
11:14 |
Dyrcona |
You audit holds? OK, then. |
11:15 |
Dyrcona |
Hold are complicated. :P |
11:15 |
Bmagic |
yep, started doing that about a year ago |
11:16 |
berick |
Bmagic: does the may 28 hold have a current_copy value now? |
11:16 |
Bmagic |
no |
11:16 |
berick |
did it ever? (neat, auditing holds!) |
11:17 |
Bmagic |
never did |
11:17 |
berick |
are there any other copies available now that should be targeted for the hold? |
11:17 |
Bmagic |
I can confirm that the hold request was evaluated with the prev_check_time changing in the auditor table |
11:18 |
Bmagic |
berick: no |
11:18 |
Bmagic |
I suppose I could create one for fun |
11:18 |
Bmagic |
That might not be a bad idea |
11:19 |
mmorgan |
Bmagic: Have you tried manually retargeting the May 28 hold? |
11:19 |
Bmagic |
mmorgan: waiting for copy, no copy |
11:20 |
berick |
Bmagic: this is new hold targeter? may get some useful details from logs: grep "targeter: \[hold $hold_id]" osrfsys.log |
11:21 |
Bmagic |
old targeter |
11:21 |
berick |
what version are you on? |
11:21 |
Bmagic |
2.11 |
11:21 |
Bmagic |
.0 |
11:21 |
* berick |
nods |
11:25 |
berick |
does the hold have a selection_ou / selection_depth value? mint_condition value? |
11:25 |
berick |
is the pickup lib closed? :) |
11:26 |
Bmagic |
ahr, mint_condition = 't', selection_ou = branch level, selection_depth=0, pickup_lib same as selection_ou |
11:26 |
berick |
what's the mint_condition value on the copy that should have been captured? |
11:27 |
Dyrcona |
mint_condition-- |
11:27 |
Dyrcona |
Even if that is not the problem. |
11:27 |
|
kmlussier joined #evergreen |
11:27 |
Bmagic |
't' |
11:27 |
* mmorgan |
would suspect that all the holds have mint_condition = 't' |
11:29 |
Dyrcona |
Yeah, that's normal. I just think we should lose the mint_condition fields, but never felt motivated to make a Lp bug about it. |
11:29 |
Dyrcona |
Pro Tip: Don't run autogen.sh until after you've run the db upgrade scripts.... |
11:29 |
Bmagic |
comparing the two rows in ahr, I find nothing other than requestor, pickup_lib, usr, selection_ou that stands out as being a possible culprit |
11:30 |
Bmagic |
I think I am going to make another copy and see what happens... |
11:42 |
Bmagic |
my new copy did fill it! |
11:45 |
eeevil |
Bmagic: assuming it was scanned at C, what is C's active config.best_hold_order and could that cause an ordering imbalance? (group hold priority and cut-in-line are possible issues for "Traditional") |
11:45 |
eeevil |
bah ... |
11:46 |
* eeevil |
should scroll all the way down before typing |
11:46 |
Dyrcona |
Lots of things can affect it....Holds are complicated. :) |
11:46 |
Dyrcona |
screenshots-in-Word-documents-- |
12:05 |
|
jihpringle joined #evergreen |
12:16 |
|
krvmga joined #evergreen |
12:23 |
Bmagic |
berick: check this out |
12:23 |
Bmagic |
Recall threshold was not set; bailing out on hold 771736 processing. |
12:30 |
berick |
Bmagic: that really just means no suitable target was found for the hold, and the follow-up check for recall-able copies exited since you're (apparently) not doing recalls. |
12:31 |
Bmagic |
should this table: config.org_unit_setting_type contain that setting? "circ.holds.recall_threshold" |
12:31 |
berick |
yes, the setting type should be there |
12:33 |
Bmagic |
that doesn't exist in our database |
12:34 |
berick |
i see it in the 2.1-2.2-upgrade-db.sql |
12:34 |
berick |
(and seed data file) |
12:34 |
berick |
possible there's a gap somewhere, though |
12:34 |
Bmagic |
I performed the same search and got the same results in the code |
12:35 |
berick |
to be clear, though, by the time the targeter is looking for recall copies, targeting has already failed. |
12:35 |
Bmagic |
our db started at 1.6 |
12:35 |
berick |
since your not doing recalls, the lack of a setting should have no effect |
12:38 |
berick |
(though clearly it's odd you don't have the setting) |
12:39 |
Bmagic |
it makes me wonder |
12:40 |
Bmagic |
a couple of years ago, I discovered a gap in our database, missing some functions, I tracked it down to the 2.1 era.... |
12:42 |
csharp |
Bmagic: there were a lot of mismatched DB creation/DB upgrade issues from that era - we still find them 5+ years later |
12:42 |
Bmagic |
well, that makes me feel (a little bit) better |
12:43 |
Bmagic |
give you the willies! "What else is wrong......" |
12:43 |
csharp |
there wasn't a very organized method for recording DB changes until maybe 2.2 or so |
12:44 |
csharp |
2011-ish |
12:45 |
Bmagic |
before my time |
13:04 |
Bmagic |
Another subject: permissions to checkout items to patrons from other systems. How do others address this? Which permission should I be looking at for the staff accounts? I suppose a "VIEW" permission of some kind, would dissallow the staff from opening the patron account? |
13:08 |
Bmagic |
VIEW_USER is set to "system" - but staff can see patrons with different home_ou's |
13:10 |
Bmagic |
I think I might have found it. VIEW_USER is set to consortium high up the pgpt |
13:43 |
Freddy_Enrique |
Excuse me guys, could anyone tell me or give a Link of the current EV modules please? |
13:45 |
Bmagic |
Evergreen has modules? Aquisitions, serials, booking, etc? |
13:47 |
Freddy_Enrique |
So, modules is not the correct way to describe those, how should I call them? |
13:47 |
Freddy_Enrique |
Yea... the Acquisitions, serials... |
13:47 |
Dyrcona |
Most other ILSes call them modules. In Evergreen, most of them are not modules in that they can't be added or removed. You get them all. |
13:48 |
Freddy_Enrique |
Is there a word to describe these in evegreen? |
13:49 |
Freddy_Enrique |
oh.... |
13:49 |
|
jihpringle_ joined #evergreen |
13:49 |
Dyrcona |
Modules works, but features might be better. |
13:49 |
Freddy_Enrique |
Features, ok. Ill keep that in mi chip |
13:51 |
Freddy_Enrique |
Then, it would be crazy if I ask the EV's features, it would be too many |
13:51 |
Dyrcona |
I don't think there is a neat list anywhere. The best place to look might by the documentation table of contents: http://docs.evergreen-ils.org/2.12/ |
13:51 |
Dyrcona |
s/by/be/ |
13:52 |
Dyrcona |
I notice the chapter on booking actually calls booking a module. |
13:53 |
Dyrcona |
Booking is easily, and often, disabled if not used. |
13:54 |
Dyrcona |
I guess we can go with modules, since it's familiar to most librarians. |
13:55 |
Dyrcona |
The documentation isn't really arranged by module, though. |
13:56 |
Freddy_Enrique |
I wanted to confirm this information: |
13:56 |
Freddy_Enrique |
Evergreen Evergreen stands by the quality of the implementation of its features: extensive access management - security; robust construction to support a consortium of libraries (275 libraries in the consortium Pines of the state of Georgia, 9.8 million documents, 15 million of loans in 2007), but also a documentation center; power tool for generating reports and statistics. Evergreen has no module for author |
13:58 |
Freddy_Enrique |
for what I can tell, Its outdated |
13:59 |
Dyrcona |
Freddy_Enrique: https://evergreen-ils.org/frequently-anticipated-questions/ |
13:59 |
Dyrcona |
Scroll down to #4. |
14:00 |
Dyrcona |
And, where did that information come from? |
14:00 |
Freddy_Enrique |
And Article made in.... |
14:00 |
Freddy_Enrique |
Fondation pour une Bibliothèque Globale, Québec, Canada |
14:01 |
Freddy_Enrique |
Dyrcona++ |
14:01 |
Freddy_Enrique |
THANKS! |
14:01 |
Freddy_Enrique |
tittle: How to Choose an Free and Open Source Integrated Library System |
14:01 |
Dyrcona |
The href would be nice, so I don't have to google it. :) |
14:02 |
Freddy_Enrique |
SUre, give me a minute |
14:02 |
Dyrcona |
I found it. A PDF by that title anyway. |
14:03 |
Freddy_Enrique |
jajaja, so fast |
14:03 |
Dyrcona |
The font makes it hard to read.... |
14:07 |
Freddy_Enrique |
Here I can read it. Maybe because i Donwloaded it |
14:07 |
Bmagic |
Dyrcona++ awesome href |
14:11 |
Freddy_Enrique |
yeah ^_^ |
14:15 |
Dyrcona |
Guess my PDF reader picked a better substitution font than Chromium. It's easier to read after downloading it. |
14:17 |
Dyrcona |
Yeah, some things in that document are no longer true, and may even have been false at the time it was written. |
14:18 |
Freddy_Enrique |
I've got to be careful then |
14:19 |
Dyrcona |
Well, we do have serials and acquisitions now. I think they were still in development in 2011, or just being completed. |
14:19 |
Dyrcona |
I'm not sure what they want with an authority control module... We do have limited authority control, such as it is. |
14:21 |
Freddy_Enrique |
uhm....say for example |
14:21 |
Freddy_Enrique |
I find a record with the authority otorongo |
14:22 |
Freddy_Enrique |
When I click the authority Otorongo, I have a set of option |
14:22 |
Freddy_Enrique |
options |
14:22 |
Freddy_Enrique |
Also find records attached to that authority |
14:23 |
Dyrcona |
I don't think we have that, but I'm not a cataloger. |
14:23 |
Dyrcona |
You can link bib fields to authority records, though. |
14:24 |
Dyrcona |
So the underpinnings are there. |
14:24 |
Freddy_Enrique |
I'll have my computer repaired this saturday and Ill check it put. I just die a couple of days ago |
14:24 |
Freddy_Enrique |
out* |
14:24 |
Freddy_Enrique |
it just * |
14:25 |
Freddy_Enrique |
I'm pretty sure I saw it. In the cataloging tool, camp 650 |
14:26 |
Dyrcona |
I don't know if you can go from an authority record and get a list of bibs easily, though. |
14:46 |
bshum |
Oh yay, checking LP translations, the export for 2.12 and master both ran successfully to their respective bzr branches |
14:46 |
bshum |
Guess those custom language settings I added to clear up the import queue helped :D |
14:47 |
Dyrcona |
bshum++ |
15:03 |
miker |
Freddy_Enrique: much of that functionality is availble through the browse functionality. It takes authority records into account, and links to bibs that use the authority |
15:09 |
Freddy_Enrique |
I was told that the browse funtionality is optional for the moment, But I guess I wont be able to wait until october so I'm gonna look into that this weekend :) |
15:09 |
Freddy_Enrique |
thanks Miker |
15:19 |
|
hbrennan joined #evergreen |
15:20 |
hbrennan |
jeff: Does the Overdrive API need a copy/item barcode to function? Or can the record contain no actual copies and still pull up the info? |
15:23 |
bshum |
Maybe jeffdavis would know better |
15:24 |
hbrennan |
jeff: Just kidding. jeffdavis is who I meant :) |
15:24 |
hbrennan |
bshum: Thanks |
15:24 |
bshum |
Not that jeff wouldn't know... he knows many things |
15:24 |
hbrennan |
#AllTheJeffs |
15:24 |
hbrennan |
Yeah no kidding |
15:26 |
berick |
@band add All The Jeffs |
15:26 |
pinesol_green |
berick: Band 'All The Jeffs' added to list |
15:26 |
hbrennan |
ha |
15:29 |
Dyrcona |
@praise [band] |
15:29 |
* pinesol_green |
All The Jeffs is the hardest working person in #evergreen. |
15:29 |
Dyrcona |
ha! |
15:29 |
Dyrcona |
True dat! |
15:30 |
Dyrcona |
hbrennan: If you mean does the Overdrive record have to have a copy and barcode in Evergreen, I don't think it does. |
15:30 |
mmorgan |
hbrennan: I am not a Jeff, but I don't believe there needs to be a copy either. |
15:30 |
berick |
mmorgan: but you play one on TV? |
15:30 |
hbrennan |
:) |
15:30 |
mmorgan |
:) |
15:31 |
hbrennan |
Thanks. We stopped importing Overdrive records when moving to Evergreen and now we're trying to play catch up |
15:31 |
mmorgan |
berick: I don't feel I am qualified. ;-) |
15:31 |
hbrennan |
not having to generate dummy barcodes would be one less step |
15:32 |
Dyrcona |
hbrennan: We didn't and it seems to be mostly working for us. |
15:32 |
jeffdavis |
Yeah, you want an OverDrive ID in the 037 (if you're using recent-ish records from OverDrive) and a URI in the 856. No copies needed. |
15:33 |
jeffdavis |
If you have older records with old-style Overdrive URIs you don't need the 037. |
15:33 |
hbrennan |
We have the option of importing the MARC Express records to get caught up, and I haven't looked closely at them yet |
15:43 |
|
jihpringle joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:40 |
Dyrcona |
And, just like that: 92,811 lines of code written... |
16:40 |
Dyrcona |
emacs++ |
16:41 |
* berick |
chuckles |
16:42 |
* Dyrcona |
just mangled a spreadsheet into a ridiculous number of SQL inserts. :) |
16:43 |
Dyrcona |
About 5 lines for each insert. |
16:45 |
|
dbwells joined #evergreen |
16:50 |
jeff |
live test failure does not at first glance appear to be a transient one, nor does it seem to be what Dyrcona ran into recently. commit 518023b might need some followup. |
16:50 |
pinesol_green |
jeff: [evergreen|Jason Etheridge] lp1653998 webstaff redirect to login page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=518023b> |
16:50 |
jeff |
"Unknown provider: $routeProvider" |
16:56 |
Dyrcona |
Ah.. this just went in this afternoon. |
16:57 |
Dyrcona |
This morning, rather. |
16:57 |
Dyrcona |
That's why I didn't see that failure. |
17:00 |
* Dyrcona |
wonders if a 2.7MB sql file is a bit much.... |
17:00 |
Dyrcona |
Anyway, signing out for now. |
17:07 |
|
mmorgan joined #evergreen |
17:08 |
|
mmorgan left #evergreen |
18:05 |
|
jvwoolf left #evergreen |
19:34 |
|
jihpringle joined #evergreen |
19:53 |
|
dbwells joined #evergreen |
21:07 |
|
RBecker joined #evergreen |
21:51 |
hbrennan |
mmorgan++ |
21:52 |
hbrennan |
Dyrcona++ |
21:52 |
hbrennan |
jeffdavis++ |