| Time |
Nick |
Message |
| 01:01 |
|
dbwells joined #evergreen |
| 01:27 |
|
dconnor joined #evergreen |
| 01:27 |
|
book` joined #evergreen |
| 01:27 |
|
Stompro joined #evergreen |
| 01:27 |
|
tfaile joined #evergreen |
| 01:27 |
|
pastebot joined #evergreen |
| 01:27 |
|
egbuilder joined #evergreen |
| 01:27 |
|
jeff_ joined #evergreen |
| 01:27 |
|
pinesol_green joined #evergreen |
| 01:27 |
|
hopkinsju joined #evergreen |
| 01:27 |
|
Bmagic joined #evergreen |
| 01:27 |
|
graced joined #evergreen |
| 01:27 |
|
eeevil joined #evergreen |
| 01:27 |
|
phasefx2 joined #evergreen |
| 01:27 |
|
dreuther_ joined #evergreen |
| 01:27 |
|
jeffdavis joined #evergreen |
| 01:27 |
|
ningalls joined #evergreen |
| 01:27 |
|
RBecker joined #evergreen |
| 01:27 |
|
bshum joined #evergreen |
| 01:27 |
|
mceraso joined #evergreen |
| 01:27 |
|
dcook joined #evergreen |
| 01:27 |
|
jcamins joined #evergreen |
| 01:27 |
|
BigRig joined #evergreen |
| 01:33 |
|
dconnor joined #evergreen |
| 01:33 |
|
book` joined #evergreen |
| 01:33 |
|
Stompro joined #evergreen |
| 01:33 |
|
tfaile joined #evergreen |
| 01:33 |
|
BigRig joined #evergreen |
| 01:33 |
|
jcamins joined #evergreen |
| 01:33 |
|
dcook joined #evergreen |
| 01:33 |
|
mceraso joined #evergreen |
| 01:33 |
|
bshum joined #evergreen |
| 01:33 |
|
RBecker joined #evergreen |
| 01:33 |
|
ningalls joined #evergreen |
| 01:33 |
|
jeffdavis joined #evergreen |
| 01:33 |
|
dreuther_ joined #evergreen |
| 01:33 |
|
pastebot joined #evergreen |
| 01:33 |
|
egbuilder joined #evergreen |
| 01:33 |
|
jeff_ joined #evergreen |
| 01:33 |
|
pinesol_green joined #evergreen |
| 01:33 |
|
hopkinsju joined #evergreen |
| 01:33 |
|
Bmagic joined #evergreen |
| 01:33 |
|
graced joined #evergreen |
| 01:33 |
|
eeevil joined #evergreen |
| 01:33 |
|
phasefx2 joined #evergreen |
| 03:11 |
|
dcook joined #evergreen |
| 04:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:17 |
|
artunit_ joined #evergreen |
| 06:53 |
|
mrpeters joined #evergreen |
| 07:19 |
|
edoceo joined #evergreen |
| 07:55 |
|
jboyer-home joined #evergreen |
| 08:27 |
|
remingtron joined #evergreen |
| 08:40 |
|
akilsdonk joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:43 |
|
Dyrcona joined #evergreen |
| 08:56 |
|
berick joined #evergreen |
| 09:00 |
|
ericar joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:11 |
mrpeters |
since 2.6.1 is out, any word on when that release will be tagged in git? we rely on the tags to build our debs. |
| 09:14 |
dbwells |
mrpeters: I'll do it now |
| 09:15 |
mrpeters |
dbwells: thanks! |
| 09:20 |
jeff |
From git://git.evergreen-ils.org/Evergreen |
| 09:20 |
jeff |
* [new branch] tags/rel_2_5_5 -> origin/tags/rel_2_5_5 |
| 09:20 |
jeff |
* [new branch] tags/rel_2_6_1 -> origin/tags/rel_2_6_1 |
| 09:20 |
jeff |
dbwells++ |
| 09:21 |
|
mllewellyn joined #evergreen |
| 09:23 |
|
dac joined #evergreen |
| 09:24 |
|
dkyle left #evergreen |
| 09:24 |
pinesol_green |
[evergreen|Dan Wells] Forward port 2.5.5 and 2.6.1 upgrade scripts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=65307de> |
| 09:38 |
* Dyrcona |
dives into writing a Template Toolkit filter plugin. |
| 09:38 |
|
Shae joined #evergreen |
| 09:41 |
|
yboston joined #evergreen |
| 09:43 |
csharp |
we've got a report from one of our libraries that their clients are freezing when they apply a new patron barcode to an account - they say it started happening when the moved to Windows 7 64-bit - has anyone else heard of such a thing? |
| 09:43 |
csharp |
another library was reporting the same issue and I couldn't get enough log data on our end to do much and assumed it was LAN/workstation issues |
| 09:43 |
bshum |
I haven't heard of anything like that, and we use 7 64-bit all the time |
| 09:43 |
csharp |
okay - good to know |
| 09:44 |
bshum |
Well, "we" being most of our libraries / all of the rest of Biblio staff |
| 09:44 |
csharp |
well I only have access to 32-bit Windows 7 right now, so that rules out the main thing I was going to test |
| 09:44 |
|
kbeswick joined #evergreen |
| 09:45 |
csharp |
I assume it's one of those bugs that is elicited by a specific workflow |
| 09:54 |
* csharp |
daydreams about the beach he'll be sitting on tomorrow |
| 09:58 |
jeff |
Dyrcona: tt filter plugin for ncip work, or something else? |
| 09:59 |
Dyrcona |
jeff: For Evergren, actually. |
| 09:59 |
Dyrcona |
Evergre[e]n, even. :) |
| 10:09 |
csharp |
Evergree?n |
| 10:10 |
* Dyrcona |
was using the [] in the more traditional print sense of filling in something that was missing in the original. |
| 10:10 |
Dyrcona |
But, anyway. |
| 10:11 |
csharp |
Dyrcona++ |
| 10:12 |
csharp |
what is this "print" of which you speak? |
| 10:12 |
Dyrcona |
I'm working on a filter for CSV fields for use in TT2 files. |
| 10:12 |
Dyrcona |
To do quoting, etc. |
| 10:29 |
|
lchenry joined #evergreen |
| 10:54 |
Dyrcona |
Y'know, = vs. =~ makes a huge difference. :) |
| 10:55 |
jeff |
Dyrcona: Text::CSV not going to do the job for you? :-) |
| 10:59 |
Dyrcona |
jeff: CSV is so simple in principal and our data output so controlled, that using Text::CSV in a Template::Plugin::Filter didn't even occur to me. :) |
| 11:00 |
jeff |
simple in principal in theory. ;-) |
| 11:03 |
bshum |
jeff: Heh, one libraries just noticed the "update expire date" button is new to our upgraded systems. They apparently really love the new button. |
| 11:03 |
jeff |
it's easier to generate than to consume, but i lean toward agreement with thoughts like this: http://tburette.github.io/blog/2014/05/25/so-you-want-to-write-your-own-CSV-code/ |
| 11:03 |
bshum |
jeff++ |
| 11:03 |
jeff |
tadl_staff++ |
| 11:05 |
Dyrcona |
jeff: I agree with not rolling your own, but creating CSV is easy compared to consuming as you say. |
| 11:06 |
Dyrcona |
And, I have written very good code in the past to do both. |
| 11:12 |
Dyrcona |
Looks like we might have to internationalize the comma, though. :) |
| 11:16 |
|
berick joined #evergreen |
| 11:19 |
yboston |
Hello, when my catalogers import bibs (or auth) records, they would love to be able to immediatly find out what DB id (aka bib number) has been assigned to that record. |
| 11:19 |
yboston |
I can't seem to find a simple way, without using SQL, to see what number the just imported bib record has been assigned. I suspect I am missing something right in front of us |
| 11:20 |
jeff |
Dyrcona: i can't tell if you're joking about the comma or not. :-) |
| 11:23 |
Dyrcona |
And, Nautilus decides to take a nap. |
| 11:25 |
Dyrcona |
yboston: Dunno for sure, but don't think you're missing anything. |
| 11:26 |
berick |
yboston: what interace? |
| 11:26 |
yboston |
berick: my apologies, the are using the the GUI batch import |
| 11:26 |
yboston |
on the client |
| 11:27 |
yboston |
Dyrcona: thanks, I was afraid I was missing something obvious. I am currently playing around with Supercat URLs to see recently imported bibs, but I am not seeing DB ids listed so far in my tests |
| 11:28 |
yboston |
for the record, the catalogers import one or two bib records, and then want to immediatly start editing those records. having the bib id would allow them to jump to that record. |
| 11:29 |
yboston |
Right now they immediatly try to search for the record, but I beleive there is a delay for the records to be compeltly ingested, so they don't get a match to the just imported record |
| 11:29 |
yboston |
*immediately |
| 11:30 |
jeff |
or they searched for it in the catalog, then imported, then search again and their search results from the first time are still cached, etc. |
| 11:31 |
jeff |
i thought that there was a way to get to the marc editor from the import queue view, but i could be wrong. one workaround would be to append negative nonsense to their search to force it to not use the cached search results. |
| 11:32 |
jeff |
i.e., if you searched for Example Terms, you could search for Example Terms -sdhkjhgrh |
| 11:32 |
|
kmlussier joined #evergreen |
| 11:33 |
berick |
jeff: it opens the marc editor for the queued record |
| 11:33 |
berick |
not the bib record |
| 11:33 |
berick |
i'm surprised we don't have imported_as in the queue grid, but alas, it's not there |
| 11:34 |
berick |
if importing a record with one match, you could view Matches, then View Marc on the match, then look for the 901c ;) |
| 11:35 |
yboston |
jeff: thanks for alerting me about the search caching behavior, good to know, I knew there was some caching, but not any details about it |
| 11:37 |
yboston |
jeef (or someone else): how long are searches / search results typically cached? (just out of curiosity) |
| 11:40 |
berick |
yboston: default is 5 minutes. it's configurable in opensrf.xml, though |
| 11:40 |
yboston |
berick: thanks for all the info. |
| 11:41 |
yboston |
I guess I can put in a wishlist item for this, I am just glad I was not missing something obvious |
| 11:43 |
yboston |
I wonder what other catalogers do to work around this, though I am sure others have very different workflows or it takes them more than 5 minutes to search for the recently imported record |
| 11:45 |
yboston |
btw, I am trying to get the BD ids by testing out supercat URLs like this one http://catalog.berklee.edu/opac/extras/feed/freshmeat/htmlholdings/biblio/import/200/ |
| 11:45 |
yboston |
but so far I am not getting the db id, can anyone recommend other supercat URLs (or something similar) to try to stumble on the DB ids? |
| 11:46 |
yboston |
thnaks in advance |
| 11:54 |
pastebot |
"berick" at 64.57.241.14 pasted "for yboston -- show imported record ID in Vandelay queue" (20 lines) at http://paste.evergreen-ils.org/59 |
| 11:57 |
berick |
e.g. https://bill-dev2.esilibrary.com/eg/vandelay/vandelay?qid=11&qtype=bib (only works in FF for now -- still importing -- jump to page 100) |
| 11:59 |
|
kmlussier left #evergreen |
| 12:01 |
* jeff |
grins at: |
| 12:01 |
jeff |
Remote XUL |
| 12:01 |
jeff |
This page uses an unsupported technology that is no longer available by default in Firefox. |
| 12:01 |
jeff |
Please contact the website owners to inform them of this problem. |
| 12:01 |
jeff |
(not unexpected -- it was in response to me clicking the Edit link after clicking on a bib) |
| 12:04 |
|
kmlussier joined #evergreen |
| 12:05 |
berick |
jeff: heh, I guess, consider yourself informed! |
| 12:05 |
|
kmlussier left #evergreen |
| 12:10 |
|
hbrennan joined #evergreen |
| 12:29 |
yboston |
berick: very nice, can I offer a sign-off? |
| 12:31 |
berick |
yboston: sounds good. I'll toss it into LP in justa sec |
| 12:31 |
yboston |
berick: take your time |
| 12:32 |
hbrennan |
I am on a quest to figure out why we have two different series search links (Search for related items by series) - one based on 490 (works great) and another based on 800 (no results) |
| 12:33 |
|
kmlussier joined #evergreen |
| 12:37 |
hbrennan |
Since the 490 field gives relevant results, and the 800 link doesn't, can I just prevent the 800 from making a link under the Search For Related Items by Series? |
| 12:37 |
hbrennan |
Leaving the 800 in the record, but turning it off as a link in the OPAC |
| 12:37 |
Dyrcona |
I have a working filter and template. Now, to make this work in Evergreen. |
| 12:38 |
|
bmills joined #evergreen |
| 12:38 |
berick |
yboston: https://bugs.launchpad.net/evergreen/+bug/1327284 |
| 12:38 |
pinesol_green |
Launchpad bug 1327284 in Evergreen "Display "Imported As" in Vandelay queue" (affected: 1, heat: 6) [Undecided,New] |
| 13:11 |
ericar |
dbwells: have you encountered an instance of a previous issue not changing over to the previous issuance copy location set in LS once the new issue is received? |
| 13:19 |
Dyrcona |
BTW, jeff. We already have rolled our own CSV field formatter. Checkout line 344 of OpenILS::Trigger::Reactor. (In case you missed it.) |
| 13:20 |
Dyrcona |
Oops...OpenILS::Application::Trigger::Reactor. |
| 13:21 |
|
ldw joined #evergreen |
| 13:38 |
|
dconnor joined #evergreen |
| 13:44 |
jeff |
Dyrcona: yeah, I was pretty sure that was there... haven't looked at it in detail yet. |
| 13:45 |
Dyrcona |
Well, it just regex replaces " with "" and throws " " around the content if it contains , or ". |
| 13:45 |
Dyrcona |
My filter does the same, but you can configure , or " to be something else. |
| 13:45 |
Dyrcona |
Plus, you can only use csv_datum from an A/T Reactor. |
| 13:46 |
Dyrcona |
Oh, the filter also catches \r or \n. |
| 13:57 |
|
gerson joined #evergreen |
| 13:57 |
jeff |
and strips? |
| 14:07 |
hbrennan |
Okay, after hours of research, new question: Who else has noticed and is concerned that the 800 series link doesn't work properly (produces no results)? |
| 14:08 |
hbrennan |
bshum: I'm looking at you |
| 14:08 |
hbrennan |
:) |
| 14:08 |
* bshum |
tries to look innocent |
| 14:09 |
hbrennan |
bshum: No, I'm happy that your links don't work either |
| 14:09 |
hbrennan |
because it means it's not just us |
| 14:09 |
bshum |
Heh |
| 14:09 |
hbrennan |
http://acorn.biblio.org/eg/opac/record/2921135?qtype=keyword;locg=0;query=lost%20heir;Search=Go%21 |
| 14:09 |
hbrennan |
^ example |
| 14:09 |
* bshum |
does a quick LP search |
| 14:09 |
hbrennan |
the second series link doesn't produce results |
| 14:10 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1102739 |
| 14:10 |
pinesol_green |
Launchpad bug 1102739 in Evergreen 2.4 "TPAC - series link in record fails with non-title series entries" (affected: 2, heat: 12) [Medium,Triaged] |
| 14:10 |
bshum |
Maybe? |
| 14:10 |
bshum |
Yep |
| 14:10 |
* kmlussier |
has a vague recollection of this issue. |
| 14:10 |
hbrennan |
oh yes |
| 14:10 |
bshum |
The second link is an author, followed by other details. |
| 14:11 |
bshum |
So if you click up to the author or even up through title |
| 14:11 |
kmlussier |
It bothers me. |
| 14:11 |
bshum |
Too much stuff |
| 14:11 |
bshum |
So it won't work |
| 14:11 |
hbrennan |
yeah, and it would work if it just pulled the $t |
| 14:11 |
hbrennan |
but instead it's searching author if you click that part, author + title if you click that far, or author + title + volume if you click the end |
| 14:11 |
bshum |
Right. |
| 14:12 |
hbrennan |
so simple solution, have that link JUST search series:series title (subfield t) |
| 14:12 |
hbrennan |
no matter where you click on the link |
| 14:12 |
hbrennan |
We know it worked before our upgrade (when we were on 2.3.4) |
| 14:12 |
kmlussier |
It sounds reasonable to me. |
| 14:13 |
hbrennan |
Our staff can't seem to understand why it isn't of high importance to be fixed |
| 14:13 |
hbrennan |
It's just manipulating the action of that link |
| 14:13 |
bshum |
You know |
| 14:13 |
bshum |
I'm almost sure that showing the series is a mistake in our catalog :) |
| 14:13 |
kmlussier |
Why? |
| 14:13 |
bshum |
I think I used to hide them to avoid people asking questions |
| 14:13 |
bshum |
:D |
| 14:14 |
hbrennan |
yeah, that's what we've found from others |
| 14:14 |
kmlussier |
Because it didn't work as well as it should? |
| 14:14 |
hbrennan |
but that's wrong to hide because it doesn't work |
| 14:14 |
kmlussier |
But, the way to approach that is to improve the way it works, right? |
| 14:14 |
hbrennan |
kmlussier: Yes! |
| 14:14 |
bshum |
Not disagreeing, just setting priorities :) |
| 14:14 |
hbrennan |
and I feel like after staring at this for two hours this morning, the solution is pretty simple |
| 14:14 |
bshum |
*cough* shakes fist at metarecord holds |
| 14:14 |
hbrennan |
Yeah yeah I know there's other stuff |
| 14:15 |
kmlussier |
Why are you blaming metarecord holds for the series links? |
| 14:15 |
* kmlussier |
is baffled. |
| 14:15 |
bshum |
No, I'm just using that as another instance of me turning off a feature that's broken rather than dealing with fixing it while patrons are still trying to use the thing. |
| 14:15 |
hbrennan |
I think that's another priority |
| 14:15 |
hbrennan |
:) |
| 14:16 |
hbrennan |
But series searches are super important and useful! |
| 14:16 |
hbrennan |
:) |
| 14:16 |
bshum |
Turning it off is better than giving them something that's broken. |
| 14:16 |
bshum |
At least for live systems. |
| 14:16 |
bshum |
In my humble opinion.. |
| 14:16 |
kmlussier |
I thought the metarecord holds issue was fixed. Or are there still problems? |
| 14:16 |
hbrennan |
Agreed, but it makes me sad |
| 14:16 |
bshum |
It's fixed now, in the master branch. I'm just lazy, okay! |
| 14:16 |
hbrennan |
and series links are something patrons really use |
| 14:17 |
bshum |
But realistically, not every site in the world has super admins who patch every bug fix the moment they're released :D |
| 14:18 |
bshum |
(or lazy super admins, who'll get around to it when things aren't on fire elsewhere) |
| 14:18 |
hbrennan |
True |
| 14:18 |
hbrennan |
How can our library help? Money? |
| 14:18 |
hbrennan |
We've never contributed to development, but this is a priority for us |
| 14:18 |
hbrennan |
since our catalogers spend a lot of time making sure series info is there |
| 14:18 |
kmlussier |
Seriously, both of my kids have been serious readers of series at different times. Getting results are just the tip of the iceberg. I would love to see that link pull up a list of every title in the series in the order with a clear visual indicator telling you what number book it is. |
| 14:19 |
kmlussier |
hbrennan: You could start by clearly defining what you want to have done. And send it to a couple of people on the support providers list to see if you can get a quote to fix it. |
| 14:19 |
kmlussier |
I imagine it wouldn't be too pricey. |
| 14:20 |
hbrennan |
And it's just a matter of changing the behavior to say "Hey, when I click you, please just search for the 800 $t as a series search" |
| 14:20 |
csharp |
there's also https://bugs.launchpad.net/evergreen/+bug/1259665, which appears to have a fix released |
| 14:20 |
pinesol_green |
Launchpad bug 1259665 in Evergreen "Series search in 2.5 does not retrieve 800 |t" (affected: 4, heat: 24) [High,Fix released] |
| 14:20 |
hbrennan |
ah, that's even closer! |
| 14:20 |
hbrennan |
I just don't know how to do such a thing |
| 14:20 |
hbrennan |
but this is the closest I've come to understand the actual development needed |
| 14:21 |
bshum |
csharp: Yeah, well, that's been fixed already though. And that's an indexing issue. |
| 14:21 |
csharp |
hbrennan: it's easy for end users to imagine the "ease" of a fix, but in my experience "easy" fixes often grow into very difficult ones |
| 14:21 |
bshum |
So that fix helps us get to the next goal with fixing how the link is created on the display |
| 14:21 |
hbrennan |
yes.... so I'm told |
| 14:22 |
hbrennan |
Anyone know exactly where this action is taking place in the db? In other words, where is it telling EG to search all the junk in 800 instead of just the $t? |
| 14:23 |
bshum |
"Free! For only ninety-nine, ninety-nine, ninety-nine......" http://www.youtube.com/watch?v=VXdy3U6S_SQ |
| 14:24 |
bshum |
hbrennan: My gut feeling (as I'm still warming up my laptop to get a look at the code) |
| 14:24 |
bshum |
is that this is actually a template change |
| 14:24 |
hbrennan |
that sounds even better? |
| 14:24 |
bshum |
Either in misc_util.tt2 or record/summary.tt2 |
| 14:24 |
hbrennan |
I feel like i could do it |
| 14:24 |
hbrennan |
haha |
| 14:25 |
bshum |
The underlying data is already supposed to be indexed the right way |
| 14:25 |
hbrennan |
I'm reaching that level of danger |
| 14:25 |
bshum |
Or at least, I would expect it to be, based on the results of the other bug csharp points out |
| 14:25 |
hbrennan |
We're still on 2.5.2 |
| 14:25 |
hbrennan |
so if we upgrade to 2.6 it should work? |
| 14:25 |
hbrennan |
Anyone already on that with series info I can check out? |
| 14:26 |
kmlussier |
Not based on what I saw in bshum's catalog. |
| 14:26 |
bshum |
Okay, we're conflating issues |
| 14:26 |
Dyrcona |
hbrennan: catalog.mvlc.org is on 2.6 |
| 14:26 |
bshum |
The bug csharp mentions is fixed, by 2.5.4 (and that's for indexing purposes, how 800t is included) |
| 14:26 |
jeff |
kmlussier: i want series holds. :-) |
| 14:26 |
jeff |
kmlussier: (and a pony) |
| 14:26 |
bshum |
The bug hbrennan was talking about for display is the other bug and that's not fixed yet. |
| 14:26 |
bshum |
In any version |
| 14:27 |
hbrennan |
okay |
| 14:27 |
dbwells |
ericar: Sorry, we don't use that option in serials, so I don't have much experience with it. That is the first I have heard of it not working, though. |
| 14:27 |
Dyrcona |
jeff: Vote for Vermin Supreme and you might get that pony. ;) |
| 14:27 |
kmlussier |
jeff: Yes! Will you make it happen for me, please? :) |
| 14:27 |
csharp |
@eightball will jeff get his pony? |
| 14:27 |
pinesol_green |
csharp: _I_ don't know. |
| 14:28 |
kmlussier |
hbrennan: You might also want to look at series.tt2 |
| 14:28 |
hbrennan |
kmlussier: Thanks |
| 14:28 |
kmlussier |
It looks like that's where that series block comes from. |
| 14:28 |
hbrennan |
I'm writing these all down to look |
| 14:29 |
Dyrcona |
@eightball Will Vermin Supreme run in '16? |
| 14:29 |
pinesol_green |
Dyrcona: The answer is a resounding no. |
| 14:29 |
ericar |
dbwells: thank you. It's so intermittent. The only "thing" I see differently is copy checkout count in comparing issues. The status timestamp updates correctly. May have to search deeper :) Thank you! If we learn more, I'll update you |
| 14:31 |
jeffdavis |
I'm seeing lots of this error during bib reingest after a 2.4->2.6.1 upgrade: duplicate key value violates unique constraint "browse_entry_sort_value_value_key" - has anyone else seen this? |
| 14:32 |
bshum |
jeffdavis: Yeah, that happened to me due to bad config.metabib_field definitions |
| 14:32 |
bshum |
Where the browse flag was set to TRUE, but the contents were badly formatted. |
| 14:32 |
bshum |
I ended up toggling off the browse flag, since many of my custom indexes weren't actually meant for browse |
| 14:33 |
hbrennan |
Okay, so if I knew what I was doing, I could change how the series link searched in our catalog? |
| 14:33 |
hbrennan |
since it's just a behavior? |
| 14:34 |
Dyrcona |
hbrennan: Depends. You might have to change the code that loads the templates. I haven't looked. |
| 14:35 |
hbrennan |
hmm |
| 14:35 |
bshum |
Yeah, kmlussier is right, it's in series.tt2. |
| 14:35 |
|
jboyer-home joined #evergreen |
| 14:35 |
bshum |
I guess what we need to do is define how to use only specific subfields from a given tag (not all of them) |
| 14:35 |
bshum |
a-z there |
| 14:35 |
* bshum |
finally notes the irony that *I* reported the series link bug :) |
| 14:36 |
Dyrcona |
@blame bshum |
| 14:36 |
pinesol_green |
Dyrcona: Your failure is now complete, bshum. |
| 14:36 |
Dyrcona |
"Don't blame bshum. He voted for irony." |
| 14:37 |
hbrennan |
sorry, circ desk... |
| 14:37 |
hbrennan |
I'm trying to find someone else to cover so I don't have to keep running away |
| 14:38 |
hbrennan |
bshum: Well, it already knows how to use specific subfields |
| 14:39 |
hbrennan |
if you click on the first part (personal name added) it searches just that |
| 14:39 |
bshum |
Well, that's just how the link is constructe |
| 14:39 |
hbrennan |
problem is, it will do name AND title if you click farther right |
| 14:39 |
bshum |
At line 20 |
| 14:39 |
bshum |
NEXT UNLESS code.match('[a-z]') |
| 14:39 |
hbrennan |
so if we could flip flop it with $t first ... that would work! |
| 14:40 |
bshum |
That seems to tell me that it'll do some poking for everything that is (or isn't?) a-z |
| 14:40 |
hbrennan |
a-z meaning the subfields right? |
| 14:40 |
bshum |
It seems to |
| 14:41 |
hbrennan |
And that's normal MARC behavior and I have enough cataloging experience to assume that wouldn't want to be messed with |
| 14:41 |
hbrennan |
or maybe no one cares? |
| 14:41 |
bshum |
series_tags = ['440', '490', '800', '810', '811', '830', '694'] |
| 14:41 |
bshum |
Well at the top it defines all the series tags |
| 14:41 |
hbrennan |
That's one part |
| 14:42 |
bshum |
So, we'd have to list out every subfield for all those tags |
| 14:42 |
hbrennan |
If/when we get the 800 worked I'd prefer to take away the 490 |
| 14:42 |
bshum |
To be sure we didn't strip the wrong ones |
| 14:42 |
hbrennan |
ok |
| 14:42 |
kmlussier |
The problem is the right ones for 490 are the wrong ones for 800 |
| 14:42 |
bshum |
Right |
| 14:42 |
bshum |
So one loop isn't going to be good enough |
| 14:42 |
bshum |
Cause if we remove a from a-z and make it like b-z |
| 14:42 |
bshum |
Then 490 stops working |
| 14:43 |
hbrennan |
well, 490 isn't standardized and 800 is |
| 14:43 |
bshum |
@marc 490 |
| 14:43 |
pinesol_green |
bshum: A series statement for which no series added entry is traced or for which the added entry is traced in one of the 800-830 fields in a form different from the form contained in field 490. (Repeatable) [a,l,v,x,6,8] |
| 14:43 |
hbrennan |
so I guess those are just listed in numerical order rather than importance |
| 14:43 |
bshum |
Meh |
| 14:44 |
hbrennan |
I apologize for making anyone learn any MARC today |
| 14:44 |
Dyrcona |
It's lovely when the meaning in your complex data sets changes over time, and you have a mix of old and new records as far as semantics are concerned. |
| 14:44 |
jcamins |
694? |
| 14:45 |
* bshum |
doesn't know, doesn't want to know |
| 14:45 |
jcamins |
bshum: likewise, except it's really weird. |
| 14:45 |
jcamins |
And weird things make me curious in spite of my better sense. |
| 14:46 |
hbrennan |
hehe |
| 14:46 |
hbrennan |
all I know is that 800 is standardized |
| 14:47 |
hbrennan |
and therefore we want that to be the priority |
| 14:47 |
hbrennan |
We CAN and have moved the same info from 800 into 490, but that's extra work and doesn't fix the 800 |
| 14:48 |
Bmagic |
I am having a problem where my matching circ rule is not enforcing a limit. I know for sure that config.circ_matrix_limit_set_map is connecting my limit of 5 to the circ rule that is getting selected. What is the magic trick to make the staff client stop the checkout? |
| 14:48 |
jcamins |
I went to a talk where the speaker claimed that having the 490 and 800 separate and unconnected was *better*. It wasn't a very good talk. |
| 14:48 |
hbrennan |
yeah I don't believe that |
| 14:48 |
hbrennan |
:) |
| 14:49 |
hbrennan |
and adding the 490 info exactly isn't providing a solution to the broken 800 |
| 14:49 |
hbrennan |
it's just a workaround |
| 14:49 |
bshum |
Bmagic: How was the limit set defined to 5? Just 5, or any specific other criteria? circ_mod, location |
| 14:49 |
bshum |
The checkout isn't stopped per say, but there should have been a prompt that they hit a limit and ask to override and continue, I think. |
| 14:51 |
bshum |
hbrennan: So, maybe what we need is to change the definition, and do like... "FOR tag IN series_tags;" but then remove 800 from it. Then do another loop where we do the same actions again, but for tag 800, we only choose specific subfields we want? |
| 14:51 |
hbrennan |
yes yes |
| 14:51 |
* bshum |
is sure there's a more logical path forward , but that "works" in my head |
| 14:51 |
hbrennan |
specifically, only the t |
| 14:51 |
hbrennan |
because the link shows under the heading Search for related items by series |
| 14:52 |
hbrennan |
and I just don't see how the author/personal name is helpful in a series search |
| 14:52 |
hbrennan |
you can search the author already using another link |
| 14:52 |
hbrennan |
"the series" for me means "the series title" |
| 14:52 |
hbrennan |
which is 800 $t |
| 14:53 |
bshum |
So, maybe something like http://spork1.biblio.org/eg/opac/record/2921135? |
| 14:53 |
hbrennan |
even less relevent is the volume number (800 $v) because then all you get is the item you just came from |
| 14:53 |
bshum |
Oops, darn ? at the end... |
| 14:54 |
hbrennan |
^ Yes |
| 14:54 |
hbrennan |
it still worked |
| 14:54 |
Bmagic |
bshum: It's just plain old 5 nothing else specified other than the owning library=1 and min depth=0 |
| 14:54 |
* bshum |
can't remember if owning library would extend to children or not. |
| 14:55 |
bshum |
But that sounds... normal. |
| 14:55 |
bshum |
Hmm |
| 14:55 |
Bmagic |
bshum: The way I understood that setting, it was the owning library that had access to edit the limit set |
| 14:55 |
Bmagic |
bshum: not who the rule affected |
| 14:55 |
bshum |
Ah, logical |
| 14:56 |
jeff |
regarding series, there's some detailed discussion of this from back in 2009 here, with a few familiar names present: http://bibwild.wordpress.com/2009/09/24/a-reasonable-display-for-series-data-in-marc/ |
| 14:56 |
Bmagic |
bshum: Is there a query or something that I can use to find out if the system or how the system is respecting the max limit rule? |
| 14:57 |
bshum |
Bmagic: Did you set the map option to fallthrough TRUE? |
| 14:57 |
hbrennan |
jeff: I like that |
| 14:57 |
Bmagic |
bshum: select action.find_circ_matrix_matchpoint(4,757375,200524,false) results: "(t,"(261,t,2,2,,,,,,,,,,,,t,33,102,101,,,,,,,,,,)",{261})" |
| 14:57 |
bshum |
Or was it on the limit set. |
| 14:57 |
Bmagic |
bshum: no, fallthrough is false |
| 14:57 |
hbrennan |
jeff: using 490 for text, and 800 for search |
| 14:57 |
bshum |
Perhaps the rule you think it's linking to isn't the complete rule. |
| 14:57 |
bshum |
Though that find seems fairly compelling |
| 14:58 |
jeff |
hbrennan: in the comments, that approach is revised, or proposed revised. |
| 14:59 |
hbrennan |
jeff: gotcha |
| 14:59 |
Bmagic |
bshum: what do you mean the rule that I think it's linking to? In my map, I have a limit_set mapped to matchpoint id 261 |
| 14:59 |
hbrennan |
jeff: Best to stick to 800.. that makes the most sense |
| 14:59 |
hbrennan |
jeff: simple |
| 14:59 |
hbrennan |
"simple" |
| 14:59 |
bshum |
Bmagic: Right, that's what I would expect you'd need. |
| 15:00 |
bshum |
Bmagic: So you're saying, you check out five things (or the patron has five things) and when you go to check out item 6, it doesn't prompt and it just continues checking out? |
| 15:00 |
Bmagic |
bshum: correct |
| 15:00 |
Bmagic |
bshum: it just checks it out without error |
| 15:01 |
|
dkyle joined #evergreen |
| 15:02 |
Bmagic |
bshum: The answer is in the logic code. Where does that take place? Which code reads the limit sets? Furthermore, how in the world does it know that the patron already has 5 checked out? Action.circulation doesn't link to matchpoint |
| 15:02 |
|
mjingle joined #evergreen |
| 15:03 |
bshum |
hbrennan: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/terrible-hackery-800t is not a real solution in my opinion, but I'm curious if maybe we're at least playing in the right area. |
| 15:03 |
bshum |
Probably more to learn from other tt2 code elsewhere |
| 15:03 |
hbrennan |
Terrible hackery... sounds awesome |
| 15:04 |
* bshum |
is not good at code |
| 15:04 |
hbrennan |
bshum: What? I don't believe it |
| 15:04 |
bshum |
Bmagic: I would imagine this is something checked at checkout itself, but don't know all the details offhand. |
| 15:04 |
hbrennan |
you know enough |
| 15:04 |
hbrennan |
bshum++ |
| 15:05 |
hbrennan |
thank you thank you for plugging that into git |
| 15:05 |
hbrennan |
If this gets fixed our library will rejoice |
| 15:06 |
hbrennan |
I will help in any way possible |
| 15:06 |
bshum |
I'm not a fan of how the links are generated in general. I'd kind of prefer if they were more combined in some way, having two links to the same title seems pointless to me (with the 490 and 800 on the same bib) |
| 15:07 |
bshum |
Also, I'm not sure why the hanging punctuation doesn't go away, I thought I saw stuff that seemed to be replacing it, but I have to read it more closely. |
| 15:07 |
bshum |
The hanging ; at the end of the entry on the test record on spork1 annoys me :) |
| 15:07 |
Bmagic |
bshum: perhaps the limit sets need to be "global" let me try that |
| 15:09 |
bshum |
Bmagic: I'd be curious if maybe changing it to use fallthrough = TRUE would alter how it behaves. What that would mean is that if rule 261 is linked to any other rule events, or used in concert with other rules, it might also extend the limit set to those other rule interactions. |
| 15:09 |
hbrennan |
It's definitely not very friendly |
| 15:09 |
bshum |
That and I feel now that I'd want a full series details somewhere else, like maybe in record details. |
| 15:09 |
hbrennan |
I'm still in the boat of If the 800 works, why do we even need to display the 490? |
| 15:09 |
bshum |
Since if we make the link only show the title, then how will I know what volume, etc. it is |
| 15:09 |
hbrennan |
Yes, keep it in the record, so you can see it in the Marc view.. but not in the series links |
| 15:10 |
jeff |
some series info will only be present in a 490 with ind1=0 |
| 15:10 |
hbrennan |
jeff: Keep it, just don't show it as a link |
| 15:11 |
hbrennan |
right? |
| 15:11 |
hbrennan |
I don't propose taking anything out of the record itself, since the more info the better there |
| 15:11 |
bshum |
Right, we're not talking about altering the MARC in any way. |
| 15:11 |
jeff |
while reserving the right to revise my opinion, i'd say show the 490 where ind1=0, because that indicates that there will not be a corresponding 830 |
| 15:13 |
hbrennan |
so if there isn't any 800 info, show a link for the 490? |
| 15:13 |
hbrennan |
I'm rusty on cataloging |
| 15:13 |
bshum |
kmlussier: Do you remember offhand any graphic_880 test bibs in the concerto set that link to series? I want to see how it's presented... |
| 15:13 |
* bshum |
needs more google powers |
| 15:13 |
jeff |
I don't recall offhand what series-related adjustments we've made to our templates (or haven't backported), but http://catalog.tadl.org/eg/opac/record/46650237?locg=22 is an example of a record with a 490 with ind1=0 and no 830. I'd like the information (book 3 of The Hardy boys mystery series) to be displayed somewhere. |
| 15:14 |
bshum |
jeff: Yeah, that's part of what I'm concerned with monkeying with the links. I think we should revise how the links work but also preserve displaying the full series statements. |
| 15:15 |
* kmlussier |
looks. |
| 15:15 |
jeff |
hbrennan: by my understanding, 490 with ind1=1 means "there's an 830 with this same information", so you'd double display things if you showed both. by showing only 490 with ind1=0, you should avoid that duplication. |
| 15:15 |
bshum |
Ah, "chinese" finds me some records |
| 15:16 |
jeff |
I know that there was a period of time where many of our series-related tags were being mangled in the name of working around some issue or issues with dispay (dating back to our old ILS but carrying over somewhat into Evergreen also) |
| 15:17 |
bshum |
hbrennan: The reason this code is complicated (to me) is issues like these records: http://theory.biblio.org/eg/opac/record/209 (where the series link includes also a graphic representing in another language). So I'm wary about how we alter the pieces in there without breaking those components. |
| 15:17 |
bshum |
Course in that exact records, it's a 440? |
| 15:17 |
* bshum |
shrugs |
| 15:18 |
kmlussier |
bshum: Yeah, I don't see anything with an 800. Just the one with the 440 |
| 15:18 |
* bshum |
should learn chinese someday |
| 15:19 |
kmlussier |
bshum: It looks like there's one with an 830 |
| 15:19 |
hbrennan |
hmm |
| 15:20 |
Dyrcona |
Fun with typos: "teh infromation for a patroon" |
| 15:20 |
csharp |
@ana the infromation for a patroon |
| 15:20 |
pinesol_green |
csharp: In front of toothier panorama |
| 15:20 |
* csharp |
apparently can't misspell "the" if he even tries |
| 15:21 |
bshum |
"the" is one of those words that always looks wrong to me when I look too hard at finding errors in spelling. |
| 15:21 |
hbrennan |
haha |
| 15:24 |
hbrennan |
ohh graphic |
| 15:29 |
bshum |
I'll ponder this more when I can, hbrennan, but remind me/others to poke at this more thoughtfully to get a new solution in place by 2.7 in case I forget about it :( |
| 15:29 |
Bmagic |
bshum: The only way I got it to work was to specify a circ mod on the limit set |
| 15:30 |
bshum |
Bmagic: That's interesting. Not exactly what I would have expected. But that said, I know all our limit sets use circ modifiers. We don't globally limit checkouts of any type. |
| 15:31 |
hbrennan |
bshum++ Thank you so much |
| 15:31 |
hbrennan |
this is very promising, and a lot of info for a Friday |
| 15:31 |
bshum |
hbrennan: Actually what I'll do is target the bug to 2.next for consideration. I'll put a few notes on there about where I think we ought to head, but I think it'll be good to get some more input from others on the future of series displaying. |
| 15:31 |
hbrennan |
yes yes |
| 15:31 |
hbrennan |
It's one of those "not priority for developers, but tremendously important for front end" |
| 15:31 |
hbrennan |
thank you thank you |
| 15:32 |
hbrennan |
and Dyrcona++ kmlussier++ jeff++ |
| 15:32 |
hbrennan |
bshum: that's bug 1102739? |
| 15:32 |
pinesol_green |
Launchpad bug 1102739 in Evergreen 2.4 "TPAC - series link in record fails with non-title series entries" (affected: 3, heat: 16) [Medium,Triaged] https://launchpad.net/bugs/1102739 |
| 15:34 |
kmlussier |
So the first of the month has totally passed me by. I should have been scheduling a dev meeting for next week, but it seems a little late now on a Friday afternoon. Should I shoot for the week of the 16th? |
| 15:35 |
bshum |
hbrennan: Yeah that's the one. |
| 15:35 |
hbrennan |
bshum: thanks |
| 15:37 |
bshum |
hbrennan++ # making us think ;) |
| 15:37 |
hbrennan |
Apologies, since it's a Friday (and afternoon for you) |
| 15:38 |
hbrennan |
I've already had a few pats on the back here |
| 15:38 |
hbrennan |
word is spreading |
| 15:38 |
hbrennan |
"There is hope! We are not cataloging wrong!" |
| 15:38 |
bshum |
Eh, I was just looking at the ALA schedule trying to figure out what sessions sounded interesting. |
| 15:38 |
Bmagic |
bshum: It appears that it requires a circ mod in order for it to work. You can specify more than one circ mod and the behavior is: If you exceed the limit of any combination of these circ modifiers |
| 15:38 |
bshum |
Their site makes me want to tear my eyes out sometimes with how everything is structured/presented |
| 15:39 |
hbrennan |
The ALA conference site? |
| 15:39 |
hbrennan |
It's very .... Vegas |
| 15:39 |
bshum |
Bmagic: Right, we do that too, like hey, all of these are circ_mods for videos (like a half dozen or so), add all of them to a bunch of limit sets :) |
| 15:39 |
bshum |
hbrennan: Haha |
| 15:40 |
hbrennan |
stepping away for a minute.... |
| 15:41 |
bshum |
I find myself picking sessions because the names sound fun. Like "Boba Fett at the Circ Desk: Library Leadership Lessons from The Empire Strikes Back" just sounds like it might be interesting. |
| 15:41 |
bshum |
But there's so many concurrent interesting sessions, sigh. |
| 15:43 |
bshum |
Anywho, we'll get there. |
| 15:46 |
hbrennan |
I've never been to a library conference :) |
| 15:51 |
jeff |
are you not counting the Evergreen conference as a "library conference"? |
| 15:51 |
jeff |
(asking because i'm curious) |
| 15:52 |
hbrennan |
Correct, not counting EG |
| 15:52 |
hbrennan |
I consider that software |
| 15:52 |
hbrennan |
I've never been to a conference with majority of "librarians" |
| 15:59 |
* bshum |
always thought the Evergreen conference was mostly librarian, but won't split hairs today |
| 16:00 |
hbrennan |
Really? Isn't that a stat that is taken during registration? I'd be curious to know |
| 16:00 |
hbrennan |
jcamins: yes |
| 16:00 |
hbrennan |
? |
| 16:00 |
jcamins |
Library conference, then. Clearly. ;) |
| 16:00 |
hbrennan |
haha, I thought that was just "conference" |
| 16:01 |
mjingle |
You're missing out hbrennan. They throw great parties at such conferences. |
| 16:01 |
kmlussier |
jcamins++ |
| 16:01 |
mjingle |
lol |
| 16:01 |
* kmlussier |
has always considered the Evergreen conference a library conference because there are so many librarians there. |
| 16:01 |
hbrennan |
mjingle: Yes, I know. I have just chosen EG over other choices |
| 16:01 |
|
ningalls joined #evergreen |
| 16:02 |
hbrennan |
Wish there was budget to attend more |
| 16:02 |
jcamins |
Hehe. Possibly, but it's always been my impression that there's a much better chance of running into fellow conference-goers at a random bar when you're at a library conference than when you're at another big conference. Or maybe librarians are just more recognizable. |
| 16:02 |
bshum |
No, a software conference would be more like when I go to PGCon. |
| 16:02 |
bshum |
Speaking of which, more Evergreen people should go to that! |
| 16:02 |
hbrennan |
What is it? |
| 16:02 |
bshum |
PostgreSQL conference |
| 16:02 |
hbrennan |
oh yikes |
| 16:03 |
* bshum |
managed to find himself on the same plane as jcamins coming back from two different conferences.... so stranger things? :) |
| 16:03 |
hbrennan |
I want to someday be as awesome as dbs, so I can just spend my life going to conferences |
| 16:05 |
jcamins |
hbrennan: spending your life going to conferences sounds like purgatory. |
| 16:05 |
jcamins |
Never quite enough time to accomplish anything. |
| 16:06 |
jcamins |
And it was a mostly empty plane, so I got to upgrade myself to economy plus. It was great! |
| 16:07 |
hbrennan |
jcamins: Yeah |
| 16:07 |
kmlussier |
I don't know. That conference dbs attended in Greece didn't look like purgatory. |
| 16:07 |
hbrennan |
jcamins: In another life, if I was a loner |
| 16:08 |
hbrennan |
and if I didn't actually have to produce anything, it was just my job to absorb |
| 16:08 |
jcamins |
kmlussier: going to some conferences would be nice, it's just the all-the-time conferences. |
| 16:08 |
hbrennan |
That's a thing, right? haha |
| 16:10 |
* bshum |
likes to think he would enjoy the air miles and hotel points from constant conference hopping. |
| 16:10 |
bshum |
:) |
| 16:10 |
hbrennan |
and per diem |
| 16:10 |
bshum |
I mean... also the actual conference itself. |
| 16:10 |
bshum |
:D |
| 16:11 |
hbrennan |
hehe |
| 16:17 |
Dyrcona |
Gotta love programming: One stray comma and the server won't start! |
| 16:17 |
hbrennan |
It's always a comma! |
| 16:19 |
jboyer-home |
Dyrcona: Even more amusing, doing the equivalent of /etc/init.d/networking restart remotely, from a VM. The VM Host drops all of the bridges, including the one you’re talking on. Whee! |
| 16:19 |
jcamins |
jboyer-home: I hate when I do that. I do it about once a month, too. |
| 16:19 |
jboyer-home |
I also seem to have found all of your missing commas in my last message. :/ |
| 16:19 |
bshum |
Haha |
| 16:19 |
jcamins |
I should add an alias to my shell that says "no, you idiot, this is a bad idea." |
| 16:20 |
hbrennan |
jcamins++ |
| 16:20 |
Dyrcona |
jboyer-home: heh. |
| 16:20 |
Dyrcona |
jboyer-home: I had 1 comma too many. Looks like you took it from me. :) |
| 16:20 |
jboyer-home |
jcamins: I have a script that uses brctl and cut to get a list of interfaces to re-add to the bridges, but I just learned that I don’t use it everywhere. |
| 16:20 |
Dyrcona |
And, not my code doesn't do what it is supposed to. |
| 16:20 |
Dyrcona |
s/not/now/ |
| 16:22 |
jboyer-home |
Dyrcona: Code concerns itself not with what is supposed, only with the beauty of abstractions 10000 levels deep based on a foundation of shifting sands. Sometimes it stares too long into the abyss and that’s where infinite loops come from. |
| 16:25 |
Dyrcona |
jboyer-home: Sometimes it is a superfluous @ that causes your code to fail. |
| 16:25 |
Dyrcona |
perl-- |
| 16:26 |
Dyrcona |
Transposing code from a prototype to the actual thing is not always as simple as it sounds. |
| 16:26 |
jboyer-home |
@ looks like a spiral, as in spiraling out of control. Close enough! |
| 16:26 |
pinesol_green |
jboyer-home: Down time is a fact of business when you're a poor 501c3 corporation. |
| 16:27 |
|
ldw joined #evergreen |
| 16:27 |
Dyrcona |
jboyer-home++ |
| 16:28 |
Dyrcona |
Mabye I should test with a patron who has less than 4,196 circs in their history. |
| 16:29 |
bshum |
kmlussier: Oh, uh... your question from like hours ago. Whenever the next week starts is probably fine for the next dev meeting. |
| 16:29 |
* kmlussier |
had already forgotten she asked the question. :) |
| 16:29 |
* bshum |
doesn't have a strong opinion right now |
| 16:30 |
jboyer-home |
Good luck with the new export code Dyrcona. And a happy weekend to one and all. |
| 16:30 |
Dyrcona |
And, after repairing the damage caused by stray punctuation, it works! |
| 16:30 |
Dyrcona |
Happy weekend to yo.... |
| 16:40 |
* Dyrcona |
does a happy dance. |
| 16:51 |
* kmlussier |
has never seen Dyrcona's happy dance. |
| 16:53 |
gmcharlt |
for some reason, I'm imagining that includes elements of the tropak |
| 16:53 |
* gmcharlt |
<-- free association |
| 17:03 |
Dyrcona |
Well, going home for the day. |
| 17:03 |
Dyrcona |
Oddly enough, it feels like I just got here. |
| 17:05 |
|
mmorgan left #evergreen |
| 17:24 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:25 |
Bmagic |
bshum: to your knowledge, in order to allow for example 5 items of 3 different circ mods: dvd,book,audio for a total of 15, can I just associate 3 different limit sets to the same circ policy, or do I need 3 circ policies with a single limit set each? |
| 17:26 |
bshum |
Bmagic: Err, 5 of each sounds like 3 different limit sets to me. |
| 17:27 |
bshum |
Cause you wouldn't allow someone to get 10 of dvd and 5 of book to make up 15? |
| 17:27 |
bshum |
Maybe a fourth limit set actually |
| 17:27 |
bshum |
15 of all three |
| 17:27 |
bshum |
So three limit sets (5 for each circ mod) and a fourth limit set for 15 of all three circ mods |
| 17:27 |
bshum |
So it'll stop them at 5 for each, but also at 15 of all 3 types? |
| 17:28 |
bshum |
And then you'd just need to make sure you had map links between all the circ policies and limit sets |
| 17:30 |
hbrennan_away |
Finally lunchtime! |
| 17:37 |
kmlussier |
Doodle poll for next dev meeting: http://doodle.com/bqwp3e334zpa33f8 |
| 17:39 |
bshum |
kmlussier++ # thanks! |
| 17:47 |
|
kmlussier left #evergreen |
| 17:57 |
|
RBecker joined #evergreen |
| 18:17 |
|
dbwells joined #evergreen |
| 18:26 |
|
kmlussier joined #evergreen |
| 18:33 |
* kmlussier |
wonders what it would take to finish up that display fields work eeevil speaks of in https://bugs.launchpad.net/evergreen/+bug/1102739/comments/5 |
| 18:33 |
pinesol_green |
Launchpad bug 1102739 in Evergreen "TPAC - series link in record fails with non-title series entries" (affected: 3, heat: 16) [Medium,In progress] - Assigned to Ben Shum (bshum) |
| 19:07 |
hbrennan |
Anyone('s brain) still here to quickly explain the difference between mapping and indexing....? Probably asking too much for a Friday |
| 19:14 |
phasefx2 |
hbrennan: maybe too vague without more context, but mapping is taking one concept and relating it to another, and indexing is making it easy to search for. What are you looking at? |
| 19:15 |
hbrennan |
The conversation earlier today about series statements/links |
| 19:15 |
phasefx2 |
ah, I missed all that |
| 19:15 |
hbrennan |
I understand that is an indexing thing |
| 19:15 |
hbrennan |
kmlussier just linked to the bug above |
| 19:16 |
hbrennan |
I'm just rereading the initial report |
| 19:16 |
hbrennan |
and I sorta get indexing, but now I don't know what mappig is |
| 19:16 |
hbrennan |
mapping* |
| 19:17 |
hbrennan |
I understand now why the link "isn't working" - it's because the part the link references isn't indexed.... |
| 19:17 |
hbrennan |
(just thinking out loud now) |
| 19:17 |
hbrennan |
or as I call it "pulling a bshum" |
| 19:17 |
hbrennan |
I think I just need an example of mapping |
| 19:18 |
phasefx2 |
saying a title is these specific set of tags under these conditions would be mapping |
| 19:19 |
hbrennan |
hmm |
| 19:20 |
|
mjingle left #evergreen |
| 19:20 |
hbrennan |
I might need to sleep on it |
| 19:20 |
hbrennan |
(too bad it's only afternoon) |
| 19:21 |
phasefx2 |
map links = define links = configure links |
| 19:21 |
phasefx2 |
dictate links |
| 19:22 |
hbrennan |
okay |
| 19:22 |
phasefx2 |
oh, map links was from a circ policy discussion.. no idea what was discussed earlier :) |
| 19:22 |
hbrennan |
mapping wasn't involved |
| 19:22 |
hbrennan |
but I've been asked before whether something was a index or mapping problem |
| 19:22 |
hbrennan |
and before today I didn't know what either meant |
| 19:23 |
phasefx2 |
indexing in the top of postgres is lower level than what you might care about.. and could deal with stuff like stemming and weighting |
| 19:23 |
phasefx2 |
s/top/context/ |
| 19:24 |
phasefx2 |
but saying such and such concepts should be lumped together or not, that's mapping |
| 19:25 |
hbrennan |
And and index is just that, a list of something or other (in the case from this morning, series titles) |
| 19:26 |
phasefx2 |
it's sort of an abstraction.. the concept of an index in say a book is to make it easy/speedy to look something up.. an index in computer terms can be implemented much differently |
| 19:27 |
phasefx2 |
but the purpose is the same; to make it easy/quick to find something |
| 19:27 |
hbrennan |
Sure, which is why the series link doesn't work when you ask the index to find a series title by giving it an author, because the index is only a "list" of titles |
| 19:28 |
phasefx2 |
I can buy that understanding |
| 19:28 |
hbrennan |
:) |
| 19:33 |
hbrennan |
phasefx2++ |
| 19:57 |
hbrennan |
bshum: I'm curious what library "spork1" is.... That's the library with the same record info, but they've managed to hide the series author info from the link, so the link actually works. Perhaps there is a quick fix for now. |
| 19:59 |
hbrennan |
You can send me a later or I'll just find you next week. I forgot I'm out of here early today |
| 19:59 |
hbrennan |
Thanks! |
| 19:59 |
bshum |
hbrennan: that's my test server |
| 19:59 |
hbrennan |
ohhh |
| 19:59 |
bshum |
It's not a live system |
| 19:59 |
hbrennan |
So is that something you just did today? |
| 19:59 |
bshum |
Yes, it's basically using what I put in the git branch. |
| 20:00 |
hbrennan |
Oh THAT's where that is |
| 20:00 |
hbrennan |
You references it in git, but I couldn't figure out where your info was |
| 20:00 |
bshum |
Correct. Terrible hackery |
| 20:00 |
bshum |
:) |
| 20:00 |
bshum |
But it works |
| 20:00 |
hbrennan |
Yes, it does |
| 20:01 |
hbrennan |
Writing note to self... |
| 20:01 |
hbrennan |
Thank you again for spending so much time on this today |
| 20:02 |
hbrennan |
seeing that "in progress" instead of Triaged really makes me happy |
| 20:02 |
bshum |
Well, eeevil's last comment has me wondering what he's got planned now. |
| 20:02 |
bshum |
But we'll keep at it. |
| 20:03 |
* bshum |
chuckles at "pulling a bshum" |
| 20:03 |
hbrennan |
Yeah, sounds like he's got some fancy thing |
| 20:03 |
hbrennan |
:) It's true! You do it a lot, but it works |
| 20:04 |
hbrennan |
Alright well I'm off to an acupunture appt... perfect time to digest all this new knowledge today |
| 20:04 |
* bshum |
wishes hbrennan a nice weekend |
| 20:04 |
hbrennan |
Same with you, bshum |
| 20:05 |
hbrennan |
and everyone! |
| 20:05 |
|
hbrennan left #evergreen |
| 21:42 |
|
paxed joined #evergreen |
| 21:42 |
|
paxed joined #evergreen |
