| Time |
Nick |
Message |
| 00:17 |
Guest40233 |
I'm curious...what does Evergreen need to know about RDA? |
| 00:17 |
Guest40233 |
^bshum dbs |
| 00:21 |
bshum |
dcook: Well, the thing we're working on is some new work to show more RDA 264 tag elements in the catalog. Thing is, we don't have any sample bib records in our test dataset that ships with Evergreen that include 264 (or other RDA tags) |
| 00:22 |
bshum |
dcook: dbs' idea is to get some sample bibs that do contain these new tags into our test dataset so that future testing / work with RDA can be checked using those test bibs. |
| 00:22 |
dcook |
Mmm. Fair enough. I can certainly get behind that idea. |
| 00:22 |
dcook |
It would be nice to have a quintessial RDA record set |
| 00:22 |
dcook |
Man, that wasn't even spelled anywhere near correctly |
| 00:23 |
dcook |
quintessential* |
| 00:23 |
bshum |
Hehe |
| 00:24 |
bshum |
Present time, Evergreen already supports generally the 264 publisher tag, but there's work in the mix to add other types of 264 - producer, manufacturer, distributor, and copyright date |
| 00:24 |
bshum |
And we may have some bug fixing to deal with in how 264 was originally implemented now. |
| 00:25 |
bshum |
Down the road, I don't know how ready we're going to be to work on other things, but we're starting simple. |
| 00:25 |
dcook |
That actually sounds quite logical |
| 00:26 |
dcook |
At first, I thought you might just be wanting a list of tags and I thought of: http://www.loc.gov/marc/bibliographic/ecbdlist.html |
| 00:26 |
dcook |
Too bad it's just plain text and not XML... |
| 00:26 |
dcook |
But yeah...having a set of RDA in MARC records to validate against would be wonderful. |
| 00:26 |
dcook |
When I say wonderful, I mean less making you want to stab yourself in the eyes :p |
| 00:27 |
bshum |
Heh |
| 00:29 |
dcook |
I wonder if LOC indexes some of their RDA fields like 336, 337, 338 |
| 00:29 |
dcook |
A person could try doing an automated search on LOC for some RDA records and maybe put together a set that way |
| 00:29 |
dcook |
Fairly haphazard but better than the alternative, perhaps? |
| 00:31 |
bshum |
Potentially. |
| 00:31 |
bshum |
I'll wait to see what dbs has in motion. In the meantime, our live system has enough RDA bibs with 264 tagging floating around. |
| 00:32 |
bshum |
Our consortium's been adding them for awhile now. Part of the reason I feel very close to making sure it plays nicely. |
| 00:32 |
dcook |
Always a good idea |
| 00:33 |
dcook |
I wonder how useful this is: http://www.loc.gov/marc/RDAinMARC.html |
| 00:34 |
dcook |
Anyway, I'll shut up now. I was just curious :) |
| 00:35 |
bshum |
It's cool. My brain is just slowly winding down as the day ends. |
| 00:35 |
dcook |
Wait a tic.. |
| 00:35 |
bshum |
Those 3xx tags make me wonder though... |
| 00:35 |
dcook |
Wonder? |
| 00:35 |
bshum |
Well, there's some new stuff in Evergreen to map formats and item materials. |
| 00:35 |
dcook |
Are you at home, bshum? Why are you up so late? |
| 00:36 |
bshum |
I wonder if we use any of that towards adopting 3xx tag data |
| 00:36 |
bshum |
To define what a thing is |
| 00:36 |
dcook |
Might be an idea |
| 00:36 |
bshum |
dcook: I'm up at all sorts of weird hours. |
| 00:37 |
bshum |
Someday I'll sleep more :) |
| 00:37 |
bshum |
Or have a life. |
| 00:41 |
bshum |
dcook: It's been awhile but Koha has a sample dataset that you can load on install for demo, right? Do you guys toy with MARC nonsense there too? |
| 00:49 |
* bshum |
may find out later tomorrow. |
| 00:49 |
bshum |
For now, attempts to sleep. |
| 01:00 |
dcook |
Hmm, good question |
| 01:00 |
dcook |
Off the top of my head, I don't think there is a sample dataset. |
| 01:00 |
dcook |
Actually, I would say I'm 90% certain there is no sample MARC dataset with any install of Koha. |
| 01:01 |
dcook |
Since we support MARC21, UNIMARC, and NORMARC...we toy with all the MARC nonsense ;) |
| 01:01 |
dcook |
We have a couple ways of displaying records...my favourite being via XSLT. |
| 01:02 |
dcook |
It makes showing multiple 264s a breeze. At the moment, I don't think we differentiate between the different types of 264, but it would be a trivial change to make. |
| 01:02 |
dcook |
In any case, sleep well! |
| 01:57 |
|
zerick joined #evergreen |
| 05:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:38 |
|
akilsdonk joined #evergreen |
| 08:05 |
|
Dyrcona joined #evergreen |
| 08:07 |
Dyrcona |
So, I get daily promotional emails from Packt Publishing because I've bought some ebooks directly from them in the past. |
| 08:08 |
Dyrcona |
Today's promotion is "Save 50% on JavaScript titles." |
| 08:08 |
Dyrcona |
Their lead title is Learning Dart. |
| 08:08 |
Dyrcona |
:) |
| 08:09 |
Dyrcona |
Just thought that was amusing. |
| 08:13 |
|
mmorgan joined #evergreen |
| 08:19 |
|
b_bonner joined #evergreen |
| 08:20 |
|
BigRig joined #evergreen |
| 08:22 |
|
mrpeters joined #evergreen |
| 08:26 |
|
Shae joined #evergreen |
| 08:29 |
|
rjackson-isl joined #evergreen |
| 08:33 |
* Dyrcona |
flips Launchpad the bird. |
| 08:37 |
|
timf joined #evergreen |
| 08:42 |
bshum |
Hmm, thoughts on this... I see two more new questions in the LP tracker area for questions, from 4/7 and 4/8 |
| 08:43 |
bshum |
I'm tempted to email the general list to recommend people do not use this part of LP to ask questions, but to email the lists, etc. |
| 08:43 |
bshum |
It's not something we're actively watching as a community (as far as I know) |
| 08:44 |
bshum |
https://answers.launchpad.net/evergreen |
| 08:44 |
|
ericar joined #evergreen |
| 08:44 |
* bshum |
wonders how this became popular again |
| 08:48 |
Dyrcona |
bshum: If its there, someone will use it. |
| 08:48 |
bshum |
I suppose that's true. |
| 08:48 |
dbs |
bshum: to follow up on your convo with dcook, no, koha doesn't have a sample set of RDA records; I always load sample records from Evergreen's test datasets into Koha :) |
| 08:49 |
bshum |
Dyrcona: Maybe we need something in Questions on LP like what jcamins did for our issues tracker in github: https://github.com/evergreen-library-system/Evergreen/issues/9 |
| 08:49 |
bshum |
But to subtly point people at the lists |
| 08:49 |
dbs |
The "trawl LoC for sample RDA records" approach could work, although it's not as though LoC hasn't made errors before. |
| 08:49 |
Dyrcona |
bshum: Subtly doesn't work. You need a very big hammer. |
| 08:50 |
bshum |
Dyrcona: I think the part that bothers me most is that nobody gets notified by LP when new questions are lodged |
| 08:50 |
dbs |
Which is why it's so freaking frustrating that all of these standards-creators haven't simply created a set of records that they can agree represents best practices! |
| 08:50 |
Dyrcona |
dbs: I can throw some records with some of the 264 data at you. |
| 08:50 |
Dyrcona |
OCLC be damned. :p |
| 08:51 |
dbs |
Some is better than none. |
| 08:51 |
Dyrcona |
I'll see if I can dig up the IDs of the two or three that I used for testing. |
| 08:52 |
* dbs |
also hopes, like bshum, that the 3xx were taken into account with all the MVF/CRA stuff |
| 08:53 |
* dbs |
peers with interest at http://www.loc.gov/standards/mods/mods-conversions.html - nope, still no MARCtoMODS3.5 XSLT |
| 08:54 |
dbs |
Although there is an RDAtoMODS3.4 XSL (as in, Excel spreadsheet; and it's horrible) |
| 08:54 |
|
kbeswick joined #evergreen |
| 08:55 |
dbs |
Example mapping from RDA to MODS 3.4 entry: "Item-specific carrier characteristics of early printed resources" to "physicalDescription/note" |
| 08:57 |
|
dbs joined #evergreen |
| 09:00 |
dbs |
s/XSL/XLS/ # phew, feel better now. |
| 09:01 |
jeff |
heh |
| 09:01 |
bshum |
Dyrcona: Sigh, now that I'm looking I can see how people could end up down the rabbit hole with questions. Not like there aren't enough "ask a question" links in LP. |
| 09:01 |
bshum |
@hate launchpad |
| 09:01 |
pinesol_green |
bshum: But bshum already hates launchpad! |
| 09:02 |
Dyrcona |
@hates |
| 09:02 |
pinesol_green |
Dyrcona hates parts; MARC; vacation; their/there; English orthography; Launchpad; RDA; typos; Launchpad Search; printing; and NCIP |
| 09:02 |
Dyrcona |
@hate Launchpad_some_moar |
| 09:02 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates Launchpad_some_moar. |
| 09:02 |
Dyrcona |
And if we hate it, why do we use it? |
| 09:03 |
bshum |
Dyrcona: It's because you didn't come to the lunch dev meeting at the conference to help remind me why I hate it so much. |
| 09:03 |
bshum |
Okay, so we can setup notifications for questions in LP |
| 09:03 |
bshum |
Right now there are no "answer contacts" which is why nobody is notified |
| 09:04 |
bshum |
But do we even want to use it |
| 09:04 |
bshum |
Sigh |
| 09:04 |
Dyrcona |
@eightball |
| 09:04 |
pinesol_green |
Dyrcona: No clue. |
| 09:04 |
Dyrcona |
Well, that doesn't help. :) |
| 09:05 |
mmorgan |
bshum: Do we have a choice but to use it? Can it even be disabled? |
| 09:05 |
bshum |
mmorgan: No, we don't have a choice to disable it. But we could actively discourage it by putting up signs and otherwise continue ignoring it :) |
| 09:06 |
bshum |
But meh |
| 09:06 |
mmorgan |
Can the answer contact be set as the general list? |
| 09:06 |
dbs |
We use Launchpad because it does almost everything we want. And more! It's mostly the "And more!" that causes problems though. |
| 09:06 |
Dyrcona |
So, looks like I have 18 098 records with at least 1 264 tag. Guess that is too many. :) |
| 09:07 |
dbs |
Dyrcona: can you find some that have a 264, some 3xx, and some RDA 7xx? |
| 09:08 |
bshum |
mmorgan: No, it looks like I can subscribe myself personally, or add different teams (like bug wranglers) as contact groups. |
| 09:08 |
bshum |
I'm hesitant to just add the bug wranglers to auto subscribe to this area without at least some more discussion by the project. |
| 09:09 |
bshum |
And I would add myself, but I'm also reluctant to commit to answering questions in that forum. |
| 09:09 |
bshum |
:D |
| 09:13 |
Dyrcona |
bshum: I would not add any teams. |
| 09:14 |
* dbs |
closes eyes and covers ears to unsee the RDA 7xx recommendations to use $e with literal values instead of $4 relator codes |
| 09:15 |
dbs |
Because, you know, $e is so multilingual and linkable |
| 09:15 |
Dyrcona |
Hmmm.. I either got my like syntax wrong or we only have 1 record with either a 3xx or 7xxx that doesn't have a 264. |
| 09:16 |
jcamins |
dbs: it's Linked Data! |
| 09:16 |
dbs |
Dyrcona: that's a good sign |
| 09:17 |
jcamins |
I went to a talk where a person from the RDA taskforce informed an audience of catalogers very seriously that RDA was designed the way it was because computer scientists insisted on it being like that. |
| 09:17 |
jcamins |
And that this new format was "Linked Data." |
| 09:17 |
dbs |
jcamins: are you sure that person didn't say "mad scientologist"? |
| 09:18 |
jcamins |
dbs: quite sure. That's why it stuck in my memory. |
| 09:20 |
* Dyrcona |
has a very low opinion of "computer science." |
| 09:20 |
dbs |
jcamins: how did that feel to be in the audience? |
| 09:20 |
Dyrcona |
And it in no way belongs in the same college as Engineering, but that's where it usually ends up. |
| 09:23 |
dbs |
Dyrcona: if you have any records with a 7xx $i, that could be interesting |
| 09:24 |
Dyrcona |
dbs: I'll see. Right now, I'm getting a count of records with 264, 3xx, and 7xx. |
| 09:24 |
dbs |
Dyrcona++ |
| 09:25 |
Dyrcona |
I'll add a subfield i on the 7xx and see if that gets me less than 6 633. |
| 09:25 |
* dbs |
predicts 0 :) |
| 09:26 |
Dyrcona |
517! |
| 09:26 |
dbs |
Hey, nice! |
| 09:26 |
Dyrcona |
Well, just 517 and no the mathematical 517!. |
| 09:26 |
dbs |
Grab 1/10 of those for a sample set? |
| 09:27 |
Dyrcona |
will do. |
| 09:31 |
|
alynn26 joined #evergreen |
| 10:09 |
|
atlas__ joined #evergreen |
| 10:10 |
Dyrcona |
dbs: I put another file up without all of the electornic records in it. |
| 10:10 |
Dyrcona |
It looks about 1 : 50 of our database records are RDA compatible or whatever. |
| 10:13 |
Dyrcona |
Heh. The first two records in my new sample are perfect for the Concerto dataset: Dvorak violin concertos, and a death metal CD by Amon Amarth. |
| 10:14 |
|
denishpatel joined #evergreen |
| 10:19 |
|
dluch joined #evergreen |
| 10:25 |
dbs |
oh yay |
| 10:26 |
dbs |
Dyrcona++ |
| 10:38 |
|
ldwhalen joined #evergreen |
| 10:57 |
csharp |
is anyone aside from KCLS using the PayPal/PayFlowPro additions? I've been asked to look into that for PINES... |
| 10:59 |
bshum |
csharp: I vaguely feel like C/W MARS implemented Paypal? |
| 11:01 |
bshum |
Or maybe they were just looking too |
| 11:02 |
Dyrcona |
I can say that we haven't because of municipal regulations and fees/fines and fees for processing, etc., and all but 1 of our members is a public entity. |
| 11:04 |
Dyrcona |
Can't pay with a credit card either for the same reasons. |
| 11:46 |
* mmorgan |
is puzzled about entries in the osrfsys log for checkins. |
| 11:47 |
mmorgan |
grep do_checkin osrfsys.09.log |
| 11:47 |
mmorgan |
I see many barcodes that have multiple entries a few hundredths of a second apart. |
| 11:47 |
mmorgan |
2014-03-26 09:47:16 app201 open-ils.circ: [INFO:29949:Circulate.pm:3613:13958414252941622] circulator: do_checkin() requestor=346, recipient=2022702, copy=31760004337848 |
| 11:47 |
mmorgan |
2014-03-26 09:47:20 app201 open-ils.circ: [INFO:29949:Circulate.pm:3613:13958415743044710] circulator: do_checkin() requestor=346, recipient=2022702, copy=31760004337848 |
| 11:48 |
mmorgan |
I see this for a lot of checkins in any give hour |
| 11:48 |
mmorgan |
Is this normal? Seems odd to me. |
| 11:48 |
mmorgan |
s/give/given |
| 11:51 |
|
Christineb joined #evergreen |
| 11:54 |
csharp |
mmorgan: you can grep the threadtrace to see all the logs for a given action (e.g., 'grep 13958414252941622 osrfsys.09.log | less') |
| 11:54 |
csharp |
mmorgan: that assumes that you chop your logs up by date/hour like we do |
| 11:56 |
mmorgan |
csharp: Thanks, that's helpful. Yes we do chop them up by hour. |
| 11:57 |
csharp |
mmorgan: you can also search the threadtrace in the activity.log (assuming that's there too) |
| 11:59 |
Dyrcona |
mmorgan: Circulation code is a mess, I see things going through it 3 and four times, even when testing and I know I only checked it in once. |
| 12:00 |
Dyrcona |
mmorgan: There's a) too much logging and b) too much bouncing back and forth among different methods. |
| 12:00 |
mmorgan |
yes, activity is there, too. I get a single line from activity for one of these threadtraces, and a whole bunch of stuff going on with the other one. |
| 12:01 |
mmorgan |
I know we have had a few situations where the same item was captured by two different holds. That's what brought me to this. |
| 12:03 |
mmorgan |
Dyrcona: that does not fill me with confidence :-( |
| 12:05 |
mmorgan |
I was thinking items were being double scanned, but this looks to be too many. |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:12 |
mmorgan |
ok, interesting. For the 2 threadtraces for each related checkin log entry, activity.log shows "open-ils.circ.checkin" for one and "open-ils.circ.checkin.override" for the other. |
| 12:13 |
mmorgan |
so maybe this isn't as odd as it first looks. |
| 12:14 |
Dyrcona |
mmorgan: That's not so odd. IIRC, the .override will be called if there is something to override about a checkin. |
| 12:14 |
Dyrcona |
Circ is still a mess. :) |
| 12:15 |
mmorgan |
ok, I'll give you that :) |
| 12:16 |
* mmorgan |
is going to stop trying to completely understand evergreen logs. At least until after lunch. |
| 12:17 |
mmorgan |
csharp++ |
| 12:17 |
mmorgan |
Dyrcona++ |
| 12:31 |
Bmagic |
anyone develop simple jquery on the opac? |
| 12:32 |
|
bmills joined #evergreen |
| 12:32 |
Bmagic |
I'm having an issue that looks like the dojo JS script runs and horks the DOM which makes my jquery break |
| 12:34 |
Bmagic |
firefox console tells me: undefineddojo._scopeArgs = [undefined]; |
| 12:36 |
jboyer-isl |
Today's lesson: if you're going to use a shell script for a nagios check, maybe mark it executable? |
| 12:43 |
tsbere |
jboyer-isl: But what if the check is "does the OS refuse to execute shell scripts not set to execute?" ;) (and yes, I have run into a linux box that stopped caring about the execute flag once, though I never did find out why) |
| 12:43 |
jboyer-isl |
That bug sounds exciting. |
| 12:56 |
|
timf joined #evergreen |
| 12:59 |
|
hbrennan joined #evergreen |
| 13:03 |
|
fparks joined #evergreen |
| 13:27 |
eeevil |
dbwells: just a head's up, if gmcharlt's fixed field seed data ends up getting into 2.6.0, that needs to come /before/ the MVF/CRA conversion dance, so that the existing values are seen as controlled instead of uncontrolled |
| 13:39 |
* csharp |
really dislikes "does program X work with Evergreen?" questions |
| 13:39 |
csharp |
my pat answer is "test it and see" |
| 13:42 |
tsbere |
csharp: My first desire is to turn around and say "Does it have any reason to interact with the ILS directly?" For example, "Does Office work with Evergreen?" Well, since it doesn't actually interact with Evergreen at all to begin with.... |
| 13:47 |
_bott_ |
Reporter creates .xls files, so yes. In a 7 degrees of Kevin Bacon kinda way. |
| 13:48 |
jeff |
i need to work on guidelines for transitioning some willing initial staff members from "one account for all" to "this is my patron account" and "this is my staff member account" |
| 13:48 |
|
bibliophylum joined #evergreen |
| 13:51 |
csharp |
tsbere: this particular question is more about extending the OPAC with vendor widgets |
| 13:51 |
tsbere |
csharp: Ahhh. That can be more complicated and/or annoying. <_< |
| 13:51 |
csharp |
usually both in my experience ;-) |
| 13:52 |
csharp |
and I'm usually dealing with it after a library has purchased said service on the breezy assurances of the vendors |
| 13:52 |
csharp |
rather than after a rigorous test, which I'm happy to coordinate on our end ;-) |
| 13:53 |
csharp |
at least this particular library asked ahead of time, so I should be happy, not complaining |
| 13:53 |
* csharp |
is just tired today |
| 13:54 |
csharp |
jeff: are you doing that in a software-based way, or from a "this is my staff card, but *this* is my patron card" way? |
| 13:55 |
_bott_ |
jeff: we chose to transition unwilling staff into "this is your only account and you'll like it" |
| 13:58 |
* tsbere |
would like to move to *either* of those setups at MVLC, but can't |
| 13:59 |
bibliophylum |
Hey folks... I'm trying to explain to non-technical bosses what the implications of Heartbleed on Evergreen systems are. I've already covered, "we're aware of this *because* it's open source" and "no, there's no way of telling if a system was targeted", and "yes, it's patched". Any thoughts/tips? |
| 14:00 |
tsbere |
bibliophylum: Show them today's XKCD and explain that the attacker can't actually control what was returned anyway? |
| 14:00 |
bibliophylum |
tsbere: heh - already did :-) |
| 14:02 |
jboyer-isl |
bibliophylum: potential patron session key retrieval, which could lead to bad actors posing as patrons to compromise privacy or just place holds on books they wouldn't like. Limited by the lifetime of the key in cache and the ability of the attacker to already know enough about evergreen to have most of that planned out. |
| 14:03 |
csharp |
bibliophylum: I thought this was a nice summary - not too technical, but not dumbing down either: http://www.newyorker.com/online/blogs/elements/2014/04/the-internets-telltale-heartbleed.html |
| 14:03 |
jboyer-isl |
That's just what comes to mind, not the full extent of the problem. |
| 14:03 |
csharp |
"But, before you panic, it is worth remembering that, at this point, we don’t know how close we are to the worst-case scenario. It is possible, though improbable, that the security researchers who exposed this flaw were, in fact, the first people to find it, which would mean that it has only been known about, and exploited, for a few days." |
| 14:04 |
bibliophylum |
Ah, excellent! |
| 14:04 |
bibliophylum |
Thanks, tsbere, jboyer-isl, and csharp :-) |
| 14:10 |
|
ldwhalen joined #evergreen |
| 14:11 |
|
kbutler joined #evergreen |
| 14:17 |
gmcharlt |
eeevil: as far as foks tracking master a concerned, am I on target that selective use of metabib.reingest_record_attributes will fix up mravl after new ccvm rows are added? |
| 14:18 |
eeevil |
gmcharlt: yes. there will be orphaned rows in the uncontrolled table, but only as many as were added to the ccvm table. |
| 14:19 |
gmcharlt |
orphaned rows in that table don't strike me as a big deal -- correct? |
| 14:19 |
eeevil |
correct |
| 14:20 |
eeevil |
eventually we'll want a mechanism for removing them, but it's no worse (and likely much less "bad") than the bloat that will accumulate in metabib.browse_entry |
| 14:22 |
gmcharlt |
the UK on (attr, value) is going to put a strict limit on how far even the most ambitious of fixed fields can bloat that table |
| 14:45 |
tsbere |
eeevil / gmcharlt: Could this help? http://pastebin.com/GFtbyPJy |
| 14:46 |
gmcharlt |
tsbere: on the face of it, looks much nicer than an attribute reingest |
| 14:49 |
eeevil |
agreed. purty |
| 14:49 |
gmcharlt |
tsbere++ |
| 14:50 |
* tsbere |
almost finds the WITH block abuse scary, though |
| 14:53 |
tsbere |
eeevil / gmcharlt: I very lightly tested it. Was thinking it might be best set up as a cron job, but not sure. |
| 14:53 |
jeff |
for evergreen specific impacts, if your ssl-speaking front-ends were apache linked against a vulnerable version of openssl, it was trivial to steal recently used session keys as well as cleartext credentials for recent logins. (or not-so-recent in terms of "wall clock time" if the target system was idle). |
| 14:54 |
* eeevil |
grumbles about CHAP ... ;) |
| 14:54 |
* Dyrcona |
just read some articles saying that exploits may have been circulating as long as last November. |
| 14:55 |
jeff |
if your front end was pound or nginx linked against a vulnerable version of openssl, i make no assertions because i didn't test that. :-) |
| 14:55 |
jeff |
we were happily on squeeze for ssl-speaking production systems. :-) |
| 14:57 |
Dyrcona |
'Ow nice for you. |
| 15:24 |
|
ldwhalen joined #evergreen |
| 15:54 |
jboyer-isl |
Does anyone else have any issues with Clark processes piling up around midnight (when most "I don't care when" reports are run)? Ours can creep up to 40+ processes a night, triggering an icinga alert almost daily. (we only run with -c 5, so that's over 8x the expected number of processes) |
| 15:59 |
|
timhome joined #evergreen |
| 16:01 |
|
alynn26 left #evergreen |
| 16:09 |
bmills |
Hello, I was wondering if the library setting "Patron Login Timeout" (for the selfcheck) is functional? The documentation says that it is not currently supported, and we have a few libraries that are reporting longer timeouts than expected. |
| 16:17 |
jeff |
bmills: can you point me to where in the documentation you're seeing that? |
| 16:18 |
jeff |
bmills: and do you know if you're using the current or the old/legacy self checkout interface? i'm assuming you're talking about evergreen's web based self checkout functionality? |
| 16:18 |
jeff |
bmills: and perhaps last... what is happening, and what do you expect to happen instead? |
| 16:26 |
Bmagic |
Can Dojo 1.3.3 traverse the dom? |
| 16:27 |
bmills |
jeff: i'm looking at http://docs.evergreen-ils.org/2.5/_self_checkout.html, we are using the new web-based self checkout and we have just been getting reports from libraries that the patron's account is left up on the screen if they forget to log out, and hasn't been timing out at the set library settings. thanks! |
| 16:27 |
|
ldwhalen joined #evergreen |
| 16:31 |
jihpringle |
bmills: we have one library using the self check on 2.4 and we found that the timeout just didn't work |
| 16:31 |
jeff |
bmills: the documentation appears to be correct. the older legacy self checkout interface made use of that timeout, and the new interface does not currently. worth a bug, if there's no bug filed yet. |
| 16:34 |
hbrennan |
I would be happy to tag onto the LP bug report, even though we don't currently use self-checkin. The security problems with that alone would be enough to prevent us from implementing it. |
| 16:36 |
jihpringle |
we fixed this for our library but haven't had a chance to push the fix upstream yet, if someone creates a bug let me know and I'll add the bug number to our internal ticket |
| 16:36 |
bmills |
ok, thank you. i'll let the libraries know |
| 16:37 |
bmills |
jihpringle++ jeff++ |
| 16:37 |
bmills |
i think that was correct… |
| 16:41 |
dbs |
Bmagic: what kind of DOM traversal are you looking for? |
| 16:42 |
Bmagic |
Im trying to start simple, like foreach element print an attribute |
| 16:43 |
jeff |
Bmagic: what's your larger goal? |
| 16:44 |
Bmagic |
We would like to increase any font-size css by *1.5 |
| 16:45 |
dbs |
And the larger goal for that? |
| 16:45 |
jeff |
Bmagic: but to answer your question, have you tried dojo.query() combined with dojo.forEach() ? |
| 16:45 |
Bmagic |
I have but I must be using it wrong |
| 16:46 |
Bmagic |
If you tell me that 1.3.3 will work without the documented dojo.require("dojo.NodeList-traverse"); statement then I will continue |
| 16:48 |
Bmagic |
dojo.forEach(obje,function(node){node.children().forEach(function(node){ Look right to you? |
| 16:48 |
dbs |
the CSS3 queries can be tricky. and there's still some browser specificity (hi IE) |
| 16:49 |
* dbs |
squints. been a long time, but I would have expected something like dojo.query().forEach() |
| 16:49 |
Bmagic |
yes... I left out that part: dojo.query("body").forEach(function(node){ |
| 16:50 |
* dbs |
has to ask if this is something that could just be handled via TPAC CSS instead, assuming TPAC |
| 16:50 |
jcamins |
Bmagic: I know nothing about the CSS used by Evergreen, but you did try increasing the font-size on the body and confirming that this didn't increase the size of everything, right? |
| 16:51 |
Bmagic |
dbs: Our inital thought was css of course but we started thinking that if we change the css for other templates, we would need to integrate those changes to this template everytime |
| 16:51 |
Bmagic |
Instead, if we had a JS traverse to do it for those that want it, we can maintain a single css instance |
| 16:52 |
Bmagic |
I started this project with jquery in mind this morning and quickly found out that dojo screws up the DOM for jquery |
| 16:53 |
jeff |
this is also possible: dojo.query('a').addClass('red') |
| 16:53 |
dbs |
jcamins is right, most of our font sizes are relative to body |
| 16:53 |
jeff |
but of course, appending a class if it's not already present leaves you at the mercy of css specificity. |
| 16:54 |
dbs |
Open-ILS/src/templates/opac/parts/css/fonts.tt2 doesn't look horrible to integrate changes into... |
| 16:54 |
dbs |
Again, I'm missing all kinds of context though :) |
| 16:54 |
* dbs |
just avoids JS if at all possible these days |
| 16:54 |
bshum |
swivels! |
| 16:54 |
jcamins |
If you want to use javascript but the change can be done with the simple CSS, you could always do body.styles.fontSize = whatever. |
| 16:55 |
jeff |
likewise. hopefully we've given you a healthy mix of "answering your question" and "cautioning against the approach you're considering" :-) |
| 16:55 |
Bmagic |
:) thanks - I didnt want to do it either but now that I am in the thick of it, I want to see it work |
| 16:55 |
jcamins |
(where body is a placeholder for the element, and styles might be called style) |
| 16:55 |
jcamins |
dbs: BTW, Laurentian's catalog looks fine without JS. |
| 16:55 |
jeff |
bshum: "swivels!" -- talk about missing some context. hopefully you didn't have a terrible run-in with an AMH/sorter? :-) |
| 16:56 |
* jcamins |
just tested it to see if TPAC handled no-JS pleasantly. |
| 16:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:57 |
bshum |
jeff: I was just remarking where dbs mentioned avoiding JS as much as possible and how berick and senator at the hackaway two years ago had thoughts about more swivels with JS to smooth out the transitions in record summary |
| 16:57 |
bshum |
For the added content, etc. |
| 16:57 |
Dyrcona |
jcamins: That was kind of the point of TPAC, no JS. |
| 16:57 |
jcamins |
Dyrcona: I know, but that doesn't mean it _worked_. I was pleased to find that it did. |
| 16:58 |
bshum |
jeff: But no, I managed to avoid harm with the AMH yesterday. |
| 16:58 |
jeff |
good to hear :-) |
| 16:59 |
bshum |
The thing I have to look more closely for them is apparently to do with timing. Our SIP response rate for the checkins is too wildly variable for their liking. |
| 16:59 |
bshum |
Like, oh this went through at 600ms, cool. The next thing is 1300 ms and apparently that's "too long". |
| 16:59 |
jeff |
they're sensitive to varied response time, not just exceeding a max timeout? |
| 16:59 |
bshum |
Mostly just worried about exceeding the time |
| 16:59 |
jeff |
ah |
| 17:00 |
jeff |
because the other seemed odd. |
| 17:00 |
dbs |
jcamins: we've worked hard to make the catalog work with JS... the Laurentian catalogue is a few versions behind |
| 17:00 |
bshum |
They were scratching their heads about the variability though. As far as being unpredictable. |
| 17:00 |
dbs |
with _without_ JS. duh |
| 17:00 |
bshum |
Such is life. |
| 17:01 |
jeff |
i'm all for increasing transaction speed, but did they not understand that it might take a longer amount of time to check in some items than others, with regard to hold capture, etc? ;-) |
| 17:01 |
bshum |
Yeah their tech didn't quite believe that answer when I tried to explain it. |
| 17:01 |
bshum |
:) |
| 17:02 |
bshum |
But holds will probably need more special care anyways. |
| 17:02 |
bshum |
This library will be the first in our consortium to go RFID and sorter. Their stuff will be the only things with tags on them. ILLs won't be tagged, so they're all going to exceptions anyways. |
| 17:02 |
dbs |
> 1 second is pretty long in the world of the web |
| 17:02 |
bshum |
It'll be an interesting prospect. |
| 17:03 |
bshum |
dbs: Indeed, true. |
| 17:05 |
jeff |
i kinda' want to add timelog-like bits to circ, similar to what was added to tpac. obviously it wouldn't be displayed in a browser, and maybe some/all of the bits are there and i'm just not parsing the logs (by hand or in an automated way) well enough... |
| 17:16 |
bmills |
submitted a bug report for the patron timeout setting in the new self check: https://bugs.launchpad.net/evergreen/+bug/1306814 |
| 17:16 |
pinesol_green |
Launchpad bug 1306814 in Evergreen "Self checkout ignoring patron timeout library setting" (affected: 1, heat: 6) [Undecided,New] |
| 17:16 |
gmcharlt |
dbwells: you may find this darkly amusing |
| 17:16 |
gmcharlt |
er, rather, dbs: http://paste.lisp.org/display/142004 |
| 17:17 |
gmcharlt |
a good ISBN to try it with is 9264023607 |
| 17:19 |
hbrennan |
bmills++ |
| 17:25 |
jeff |
gmcharlt: wow. |
| 17:25 |
jeff |
also, ow. |
| 17:27 |
gmcharlt |
jeff: I know -- and somehow, it doesn't seem quite polite to try three different API calls to OL per title to try to find, for a given identifier, the edition that has a cover associated with it |
| 17:28 |
jeff |
i've been considering same for syndetics, though... |
| 17:28 |
jeff |
cover/jacket images at all costs! |
| 17:28 |
jeff |
xkcd 416 |
| 17:28 |
jeff |
http://xkcd.com/416/ Zealous Autoconfig |
| 17:29 |
gmcharlt |
ha! |
| 17:29 |
|
mmorgan left #evergreen |
| 17:41 |
|
ldwhalen joined #evergreen |
| 17:41 |
|
atlas__ joined #evergreen |
| 17:48 |
hbrennan_at_lunc |
It's possible I may be hungry |
| 17:51 |
gmcharlt |
hbrennan_at_lunc: enjoy testing that hypothesis empirically! |
| 18:27 |
dbs |
gmcharlt: I believe it's possible to issue multiple requests per Read API request; travelling back in time to when I was talking with the OpenLibrary folk about their rate-limiting etc |
| 18:28 |
dbs |
I brought up the exact same point: "So, you're not rate limiting the Read API, but I end up making _more_ requests than via the Cover API?" They agreed that was silly. |
| 18:28 |
gmcharlt |
dbs: I've verified that is is; possibly something for mark 2 of my patch for bug 1306258 |
| 18:28 |
pinesol_green |
Launchpad bug 1306258 in Evergreen "more seed data for MARC21 fixed field values would be nice" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1306258 |
| 18:29 |
dbs |
https://blog.openlibrary.org/2011/04/27/coverstore-improvements/ |
| 18:29 |
dbs |
Oh I have no doubt |
| 18:29 |
|
bmills left #evergreen |
| 18:29 |
dbs |
but https://github.com/internetarchive/openlibrary/issues/15 fwiw |
| 18:30 |
gmcharlt |
ah, and https://github.com/internetarchive/openlibrary/commit/14adbafda615b754fcdd3b503a626820856dee75 |
| 18:30 |
dbs |
yes |
| 18:30 |
dbs |
So historically they were receptive, but of course things get lost over the span of 3 years and staff turnover |
| 18:32 |
gmcharlt |
in that case, simplest approach would seem to be direct use of the covers API, since at least for my example, it recognizes both the ISBN13 and ISBN10 without muss and fuss |
| 18:32 |
dbs |
gmcharlt: but that means giving up on tables of contents and... something else |
| 18:32 |
gmcharlt |
I do get the impression from the ol-tech archives that the past couple years has been rough for them |
| 18:33 |
gmcharlt |
also, it doesn't necessary mean giving up TOCs and the like -- just usnig the Read API for the former and the covers API for the covers |
| 18:33 |
dbs |
Oh, I see |
| 18:33 |
gmcharlt |
which yeah, would bump up the number of requests somewhat, but that's why we cache |
| 18:33 |
dbs |
Yes, they're barely in maintenance mode |
| 18:33 |
dbs |
Well, you're clearly on the warpath, so have at it |
| 18:34 |
gmcharlt |
yeah, I'm working with somebody who wants to eke out every last cover image they can |
| 18:34 |
gmcharlt |
do you have a notion of who I should talk to to get my ol-tech post out of moderation? |
| 18:35 |
dbs |
I guess the idea though was that the Read API would give you the added content plus links to any covers, if they exist, so it's still not clear to me why we would do two separate calls |
| 18:35 |
dbs |
gmcharlt: jessamyn? |
| 18:35 |
gmcharlt |
ok |
| 18:36 |
gmcharlt |
oh, and the reason why? inconsistencies like feeding "isbn:9264023607" to the Read API and /not/ get back an edition record that contains links to the covers |
| 18:36 |
gmcharlt |
even though using that same ISBN for the Covers API directly... works |
| 18:37 |
dbs |
Sounds like an upstream issue really |
| 18:37 |
gmcharlt |
IOW, lp1306258 is all abound working around rough edges in OL's data store and/or API implementations :/ |
| 18:38 |
dbs |
pull requests accepted at https://github.com/internetarchive/openlibrary apparently |
| 18:38 |
* dbs |
gets ready to submit a pull request for "Code Oraganization" typo in the README |
| 18:38 |
bshum |
gmcharlt: Am I misreading the bug numbers or did you just link to the wrong bug? |
| 18:38 |
bshum |
link/type to |
| 18:39 |
bshum |
seed data vs. openlibrary |
| 18:39 |
dbs |
Alternately, could just grab the cover dump and have a really big local cache |
| 18:39 |
dbs |
bshum: correctamundo bug 1306823 |
| 18:39 |
pinesol_green |
Launchpad bug 1306823 in Evergreen "available covers not being retrieved from OpenLibrary for some titles" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1306823 |
| 18:40 |
gmcharlt |
and yeah, it /ought/ to be an upstream issue, but glancing at the open vs. closed pullrequest suggests I'd be in for a long wait for anything that isn't a doc fix |
| 18:41 |
bshum |
dbs: Aha |
| 18:44 |
dbs |
most of the 9 pullrequests are typo fixes, I could understand a lack of interest in those |
| 18:45 |
gmcharlt |
dbs: I thnk there probably is space for a new community cover image service, though I'd rather see a way for OL to be funded more stably as a service, not just something that seems to be done just on the back of one techie at the IA and some volunteer time, as laudable as their efforts have been |
| 18:45 |
* dbs |
sees gmcharlt's comment on https://github.com/internetarchive/openlibrary/issues/27 - guess you've been at this for a while :) |
| 18:46 |
gmcharlt |
dbs: eventually I'll catch up with you in this area ;) |
| 18:46 |
dbs |
Sure, I think the challenge is having someone willing to back such a service. Brewster isn't going to fold at the first sign of a copyright challenge; hard to find others with that stance |
| 18:47 |
dbs |
gmcharlt: oh heck, I think you're already well past me |
| 18:48 |
gmcharlt |
yeah, I'd imagine that's where most of the expense would be, not the technology (particularly if a service were limited to /just/ proviing cover images and dipped its toes in bib metadata issues as little as possible) |
| 19:19 |
|
mcooper joined #evergreen |
| 19:29 |
|
ldwhalen joined #evergreen |
| 19:34 |
|
mrpeters left #evergreen |
| 20:26 |
|
ldwhalen joined #evergreen |
| 20:31 |
|
ldwhalen_mobile joined #evergreen |
| 21:01 |
|
dave_bn joined #evergreen |
| 21:05 |
dave_bn |
hi everybody |
| 21:05 |
dave_bn |
I have a difficult question. Can I specify somewhere in TPAC that certain branch be preselected as search location when OPAC is loaded? |
| 21:07 |
dave_bn |
Something like this: http://domain.com/eg/opac/home?locg=14; would preselect branch ID 14 |
| 21:08 |
dave_bn |
bu is there a way to go to http://domain.com/eg/opac/home and already see branch ID 14 preselected as search scope? |
| 21:12 |
dave_bn |
or perheps specify default branch somewhere, so it is selected whenever I visit opac |
| 21:16 |
jihpringle |
dave_bn: I don't know the answer to your question, but I recommend that you ask it on the general list serv or come back and ask it during regular business hours Eastern time when the channel is much busier |
| 21:19 |
dave_bn |
jihpringle: Thanks for the info. I will come back during business hours then :) |
| 21:19 |
jihpringle |
np |
| 21:46 |
bshum |
@later tell dave_bn One way to accomplish what you're asking for is to make use of the "physical_loc" apache variable in various virtualhosts. We do this in our system so that library1.org directs to physical_loc=1, library2.org directs to physical_loc=2, etc. for scoping purposes. |
| 21:46 |
pinesol_green |
bshum: The operation succeeded. |
| 21:50 |
bshum |
@later tell dave_bn See the snippet from http://en.flossmanuals.net/evergreen-in-action/enabling-users-to-find-what-theyre-looking-for/ that describes the "physical_loc" variable. |
| 21:50 |
pinesol_green |
bshum: The operation succeeded. |
| 21:51 |
bshum |
Which unrelated is a very badly named URL because it's really about designing the catalog and customizing TPAC. |
| 21:51 |
bshum |
Well, not "very badly" I guess.... |
| 21:52 |
* bshum |
wanders back to his nap |
| 23:01 |
jeff |
heh. i didn't expect it to take TOO long for the "list list is not to be published to the web" line to be violated. :-) |
| 23:23 |
bshum |
Alas. |
