| Time |
Nick |
Message |
| 01:30 |
|
Mark__T joined #evergreen |
| 01:58 |
|
eby joined #evergreen |
| 03:45 |
|
Christineb_away joined #evergreen |
| 04:09 |
|
collinanderson joined #evergreen |
| 04:17 |
|
sbrylander joined #evergreen |
| 04:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:12 |
|
sarabee joined #evergreen |
| 05:45 |
|
sarabee joined #evergreen |
| 07:51 |
|
ericar joined #evergreen |
| 08:00 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
krvmga joined #evergreen |
| 08:08 |
|
Callender joined #evergreen |
| 08:29 |
|
Stompro joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:41 |
|
mrpeters joined #evergreen |
| 08:41 |
|
Shae joined #evergreen |
| 08:49 |
|
akilsdonk joined #evergreen |
| 09:07 |
|
maryj joined #evergreen |
| 09:15 |
|
mdriscoll1 joined #evergreen |
| 09:25 |
|
jonadab_znc joined #evergreen |
| 09:27 |
|
eady joined #evergreen |
| 09:30 |
|
yboston joined #evergreen |
| 09:44 |
|
mrpeters joined #evergreen |
| 10:35 |
|
akilsdonk_ joined #evergreen |
| 10:36 |
|
sbrylander joined #evergreen |
| 10:42 |
|
kmlussier joined #evergreen |
| 10:42 |
|
mceraso joined #evergreen |
| 10:42 |
|
bshum joined #evergreen |
| 10:42 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 10:44 |
|
RoganH joined #evergreen |
| 10:48 |
|
jboyer_isl joined #evergreen |
| 10:52 |
|
jboyer-isl joined #evergreen |
| 11:02 |
|
david-library joined #evergreen |
| 11:11 |
|
kmlussier joined #evergreen |
| 11:11 |
|
mceraso joined #evergreen |
| 11:11 |
|
bshum joined #evergreen |
| 11:11 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 11:40 |
Bmagic |
welcome bshum |
| 11:45 |
phasefx |
bshum Bmagic, b excellent to one another <air guitar> |
| 11:45 |
Bmagic |
ha |
| 11:52 |
|
sandbergja joined #evergreen |
| 11:53 |
kmlussier |
phasefx++ |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:32 |
|
collum joined #evergreen |
| 12:37 |
Bmagic |
So, I am starting to rely on the working repo. Is there any concern about that repo going away and losing all my work? I have heard others using private repos. I assume this is the reason? |
| 12:39 |
phasefx |
Bmagic: keep a local copy and if it ever did go away, you'd be okay |
| 12:40 |
hopkinsju |
Anyone ever set up a post-commit hook to push local changes to the working repo? |
| 12:40 |
Bmagic |
Roger that. I guess I will need to setup some sort of a server in our environment for this. |
| 12:40 |
hopkinsju |
I'm curious about the workflow. Remembering to push both places sounds error prone |
| 12:41 |
hopkinsju |
Bmagic: Feel free to create a repo in our github account. |
| 12:41 |
hopkinsju |
(read: Please do that) |
| 12:41 |
phasefx |
Bmagic: but no, there's no plan for that stuff to dissappear or get purged, etc, as far as I know |
| 13:13 |
|
jboyer_isl joined #evergreen |
| 13:15 |
|
jboyer_isl joined #evergreen |
| 13:22 |
|
RoganH_ joined #evergreen |
| 13:27 |
dbs |
hopkinsju: just wait until you commit your passwords to your local repo and that auto-push shares them with the world :) |
| 13:35 |
|
jboyer-isl joined #evergreen |
| 13:57 |
jeff |
hrm. i need to look into how hold/copy counts are scoped for display in tpac. |
| 14:00 |
berick |
@eightball do we use tea leaves to find hold/copy counts? |
| 14:00 |
pinesol_green |
berick: The outlook is poor. |
| 14:07 |
jboyer-isl |
miker (or anyone else who's fought these things): when you have a minute to talk about how multi position fixed fields work (fun times) let me know. |
| 14:10 |
jeff |
in terms of 007 and friends? |
| 14:10 |
jeff |
or something else? |
| 14:16 |
dbs |
fixed fields work? :) |
| 14:24 |
tsbere |
jboyer-isl: I have some knowledge of how they work (don't ask me which are which though, I have to look that info up) |
| 14:25 |
jboyer-isl |
jeff: 008 specifically (I minimized my client shortly after posting that, sorry) |
| 14:26 |
jboyer-isl |
tsbere: I'm looking at adding additional fixed fields, but I can't fully make sense of what the code to extract fields is doing. |
| 14:27 |
tsbere |
ahhh |
| 14:27 |
jboyer-isl |
It looks like it either only saves the full value (multi = true) or the first value (multi= false). |
| 14:27 |
tsbere |
Well, yea, that would potentially be the case there. But 008 is non repeatable anyway... |
| 14:28 |
jboyer-isl |
And of course, there are plenty of multi-position fields that are "lists" as opposed to "these 2 characters means X, these 2 mean Y..." |
| 14:28 |
tsbere |
jboyer-isl: Perhaps we should start with "which one(s) are you looking to add?" |
| 14:28 |
jboyer-isl |
The 008 is not repeatable, but the Cont field for instance, is 4 independent values, ordered from most to least important. |
| 14:29 |
jboyer-isl |
tsbere: The rest of them. ;) |
| 14:29 |
jboyer-isl |
Comp is my current concern. It's 2 chars that have to be taken as a set, I don't want to accidentally set it up as a 2-position where only the first position is used. |
| 14:29 |
tsbere |
Well, that shouldn't be too hard, overall |
| 14:31 |
tsbere |
Looks like it isn't there already |
| 14:32 |
tsbere |
jboyer-isl: So, what does Comp actually stand for? <_< I hate the fact that there are all these short forms of the name but no good list of short->long |
| 14:33 |
jboyer-isl |
Several of them aren't defined yet. I'm adding entries to config.marc21_ff_map_pos, config.record_attr_definition, and config.coded_value_map |
| 14:33 |
jboyer-isl |
Sorry, meant to paste this earlier: |
| 14:33 |
jboyer-isl |
http://www.oclc.org/bibformats/en/fixedfield/comp.html |
| 14:34 |
tsbere |
ok. That would require....four entries in marc21_ff_map_pos as it is also available in the 006 and looks to be valid across two record types |
| 14:35 |
* dbs |
hopes this isn't OCLC's version of MARC vs. LoC MARC21 |
| 14:35 |
jboyer-isl |
Actually, I've been ignoring the 006, because we don't currently use it correctly. |
| 14:35 |
jboyer-isl |
dbs: No, they're in LC also, OCLC's page was just easier to read at the time. |
| 14:35 |
tsbere |
jboyer-isl: If you are going to do something do it all. Then you don't have to go back and add later and it is better for the community if you share it when it is all there for the fields you add. |
| 14:36 |
dbs |
jboyer-isl: okay. I'm jumpy every time I see oclc.org/bibformats because they do define local variations without noting them as local :/ |
| 14:36 |
jboyer-isl |
tsbere: I don't mean "we" as in Evergreen Indiana, I mean "we" as in Evergreen period. Getting actually useful information out of 006 fields requires a ton of work that we're not doing. |
| 14:37 |
* tsbere |
looks at all the 006 defs that are already in the very tables he is looking at |
| 14:37 |
dbs |
http://www.loc.gov/marc/bibliographic/bd008m.html would be the equivalent I guess |
| 14:37 |
tsbere |
jboyer-isl: I think you are missing a detail or two if you think Evergreen *period* isn't looking at the 006 info |
| 14:37 |
jboyer-isl |
Yes, and they're not working correctly. They are based on the rec_type from the leader, but that's only valid for the 008. 006 rec_types come from 006 position 1, which none of our functions are looking at. |
| 14:38 |
dbs |
In this case, it looks like the OCLC version is missing such critical entries as "sd - square dance music" |
| 14:38 |
jboyer-isl |
I don't mean not looking at it, I mean looking at the wrong things. |
| 14:38 |
jboyer-isl |
dbs: no, I remember adding that one specifically. (because I was misaligned and had to nudge everything 1 line...) |
| 14:39 |
tsbere |
jboyer-isl: I am looking at the LOC docs and what I see there does *not* match up with what you are telling me. |
| 14:40 |
* tsbere |
could also be looking at the wrong docs, so would appreciate the link with the info in question |
| 14:40 |
dbs |
jboyer-isl: oh, i see, alphabetical not by code (as LoC has) but by the spelled-out version, weird |
| 14:41 |
dbs |
Sorry for the noise :) |
| 14:41 |
jboyer-isl |
tsbere: the 006 first position is Form of Material, that's not the same as the Form fixed field. Check out the Field Def and Scope here: http://www.loc.gov/marc/bibliographic/bd006.html |
| 14:43 |
jboyer-isl |
006/00 is another leader/06 for a piece of accompanying material of a different type than specified by the leader/06 |
| 14:43 |
jboyer-isl |
That didn't come out quite as clear as I'd hoped. |
| 14:43 |
jboyer-isl |
dbs: don't worry, that irritated me too. |
| 14:44 |
jboyer-isl |
"But they're jumping around? Why?" |
| 14:44 |
tsbere |
jboyer-isl: Is there a launchpad bug for that issue? Because it likely isn't that hard to solve, overall... |
| 14:44 |
tsbere |
(Reingest required once fixed, obviously...) |
| 14:45 |
jboyer-isl |
tsbere: Not for the 006 specifically no. I'm working on lp 1371647 which is pretty vague. |
| 14:45 |
pinesol_green |
Launchpad bug 1371647 in Evergreen "config.marc21_ff_pos_map needs an audit" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1371647 |
| 14:45 |
jboyer-isl |
I should file the 006 one separately, I know. |
| 14:47 |
jboyer-isl |
I'll through the 006 inserts into marc21_ff_pos_map while I'm adding things, I didn't mean to drag us off course with all of the 006 talk. |
| 14:47 |
jboyer-isl |
*throw*, that is. |
| 14:51 |
jeff |
hrm. i may have started one such audit. |
| 14:51 |
jeff |
then shelved it because of existing work going in with fixed fields |
| 14:52 |
jboyer-isl |
jeff: what existing work are you referring to? |
| 14:53 |
jeff |
jboyer-isl: fixed field wizard and some related changes, iirc. |
| 14:53 |
jeff |
looks like i last looked at this in detail in Feb 2014 |
| 14:54 |
jboyer-isl |
I see. |
| 14:56 |
jeff |
jboyer-isl: here are my notes from the start of that work. i'd be interested in contributing again on the mentioned "audit": |
| 14:56 |
jeff |
https://docs.google.com/document/d/1MAds_a3_jU49opWHquGHj0-pjTBsnaNAoQQ0hZvzWp8/edit |
| 14:56 |
jeff |
https://docs.google.com/spreadsheets/d/14ak2Ya4yWliyhZ9UD1rxvfNaXvNXN7q7QRd-GLet-5c/edit |
| 14:56 |
jeff |
one doc, one spreadsheet. |
| 14:56 |
jboyer-isl |
It looks like I'm worried about nothing, if fields like Ctry and Lang are any indication, they're also multiple characters and appear to be fine. |
| 14:56 |
jeff |
very very rough notes -- and i'm fairly certain at least some of the potential bugs that i described there have since been fixed. |
| 14:57 |
jeff |
That document was also my attempt at sussing out what some of the OCLC abbreviations that are in the current MARC editor mean. |
| 14:58 |
* tsbere |
dislikes the use of all the OCLC abbreviations |
| 14:59 |
jboyer-isl |
Ah, I'm fairly certain the interface has had some things improved, but I'm currently only looking at the database. (This all started because we want to use LTxt and Cont in some coded value maps, and they're not defined at all.) |
| 15:00 |
|
krvmga joined #evergreen |
| 15:01 |
|
buzzy joined #evergreen |
| 15:01 |
pastebot |
"jboyer-isl" at 64.57.241.14 pasted "My notes re: 006/008 fixed fields" (81 lines) at http://paste.evergreen-ils.org/18 |
| 15:01 |
krvmga |
According to the coded value map for e-book the icon/filter for e-book includes form ‘o’ or ‘s’. Apparently this is also true if this code is in an 006 field and not just in the fixed field. This is making print books which have an 856 field for additional online content, and so the MARC record has an 006 field with the code ‘o’ for online resource, show as an e-book. |
| 15:01 |
krvmga |
is this a bug or a feature? |
| 15:02 |
jeff |
krvmga: can you link to an example record? |
| 15:02 |
krvmga |
example: http://catalog.cwmars.org/eg/opac/record/3603219?contains=contains;_special=1;qtype=identifier%7Ctcn;query=3603219;locg=1 |
| 15:03 |
jeff |
jboyer-isl: i think my notes (shared above) were starting with the UI first -- documenting what the various fixed fields in the editor were referencing / keying off of |
| 15:06 |
tsbere |
jboyer-isl: on the 006 is read wrong front, I wonder if the easy solution is to add a new column to the rec_type_map table for the 006 value, then teach the appropriate code point(s) to look that up? |
| 15:10 |
jboyer-isl |
krvmga: hard to say! Ideally once all fixed field concerns are no longer a concern, a record like that would have a full-size book icon, and then perhaps a smaller icon for each "piece" with an 006. So you'd have a book that includes and ebook, something like that. |
| 15:11 |
jboyer-isl |
tsbere: I'm not sure how best to address it since any one record can have any number of 006's and they can all have different form of item values. |
| 15:12 |
krvmga |
jboyer-isl: thanks |
| 15:26 |
Bmagic |
We are seeing strange options in our org unit dropdown menu. Suddenly we have shelving locations beneath one of our libraries! In the DOM they are known as "loc_grp" with values like "128:4". What is that? |
| 15:28 |
dbwells |
Bmagic: sounds like Copy Location Groups |
| 15:28 |
Bmagic |
ah, let me look |
| 15:29 |
jeff |
opac/parts/org_selector.tt2 generates those -- sounds like you might have something a bit off, though. |
| 15:29 |
Bmagic |
thats it! Copy location groups |
| 15:29 |
jeff |
possibly a mis-match between templates? |
| 15:29 |
Bmagic |
never used that feature |
| 15:29 |
jeff |
node_value = node_value _ ':' _ loc_grp.id; |
| 15:30 |
jeff |
oh, i thought you were saying that you were seeing literal 128:4 values in your selector. nevermind my comment about mis-matched templates. |
| 15:31 |
Bmagic |
thanks, it's copy location groups.... Off to research that! |
| 15:33 |
jeff |
aww. i'm almost disappointed to see zero results for marc tag 355 in our db. |
| 15:34 |
dbs |
3 here |
| 15:36 |
kmlussier |
Hmmm...I don't think these copy location group docs ever made it to the community repository. http://esilibrary.com/documentation/2-2-copy-location-groups/ |
| 15:37 |
jboyer-isl |
@marc 355 |
| 15:37 |
pinesol_green |
jboyer-isl: Specifics pertaining to the security classification associated with the document, title, abstract, contents note, and/or the author. In addition, it can contain handling instructions and external dissemination information pertaining to the dissemination of the document, title, abstract, contents note, and author. The field may also contain downgrading or declassification data, the name of (1 more message) |
| 15:37 |
jboyer-isl |
@more |
| 15:37 |
pinesol_green |
jboyer-isl: the classification system, and a country of origin code. Code from: MARC Code List for Countries (Repeatable) [a,b,c,d,e,f,g,h,j,6,8] |
| 15:41 |
jboyer-isl |
Huh, we also have 3, but given their values I'm almost certain they're 655 typos, that's no fun. |
| 15:41 |
jboyer-isl |
Oops, 2. (one has 2 subfields) |
| 15:53 |
bshum |
berick++ # bug 1476370, the second half is something I was starting to look at once, cause the timeout thing is happening to us a lot lately. |
| 15:53 |
pinesol_green |
Launchpad bug 1476370 in Evergreen "Selfcheck warn on patron auto-logout, reset activity timer on checkout" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1476370 - Assigned to Bill Erickson (berick) |
| 15:53 |
bshum |
berick: We'll be glad to test whatever you come up with as you work on it. |
| 15:54 |
berick |
bshum: awesome, thanks. |
| 15:54 |
berick |
glad we're not the only ones |
| 15:55 |
berick |
not that I wish pain on others.. you know what I mean ;) |
| 15:57 |
|
jlitrell joined #evergreen |
| 16:45 |
|
maryj joined #evergreen |
| 16:59 |
|
mdriscoll1 left #evergreen |
| 17:10 |
Bmagic |
how long does the fine generator run for everyone? |
| 17:15 |
|
mmorgan left #evergreen |
| 17:17 |
|
buzzy joined #evergreen |
| 17:26 |
berick |
Bmagic: just over an hour here w/ 4 parallel |
| 19:37 |
|
dcook joined #evergreen |
| 20:56 |
|
dcook joined #evergreen |
| 22:34 |
|
buzzyn joined #evergreen |
