| Time |
Nick |
Message |
| 00:04 |
|
hopkinsju joined #evergreen |
| 01:33 |
|
BigRig_ joined #evergreen |
| 01:33 |
|
Mark__T joined #evergreen |
| 01:33 |
|
Mark__T joined #evergreen |
| 06:47 |
|
artunit joined #evergreen |
| 06:56 |
|
timf joined #evergreen |
| 07:09 |
|
artunit joined #evergreen |
| 07:32 |
|
rjackson-isl joined #evergreen |
| 07:38 |
|
jboyer-isl joined #evergreen |
| 07:38 |
|
artunit joined #evergreen |
| 07:52 |
|
graced_ joined #evergreen |
| 08:04 |
|
kmlussier joined #evergreen |
| 08:05 |
kmlussier |
At what point in the release process do we usually generate a preview of the release notes? |
| 08:09 |
|
graced_ joined #evergreen |
| 08:15 |
|
collum joined #evergreen |
| 08:16 |
|
RoganH joined #evergreen |
| 08:35 |
|
kbeswick joined #evergreen |
| 08:40 |
|
akilsdonk_ joined #evergreen |
| 08:41 |
|
mrpeters joined #evergreen |
| 08:42 |
|
Shae joined #evergreen |
| 08:48 |
|
Dyrcona joined #evergreen |
| 08:50 |
|
asimon joined #evergreen |
| 08:54 |
|
ericar joined #evergreen |
| 09:04 |
|
mmorgan joined #evergreen |
| 09:07 |
|
hopkinsju joined #evergreen |
| 09:11 |
kmlussier |
@later tell dbs Should we have a release notes entry for your schema.org work? |
| 09:11 |
pinesol_green |
kmlussier: The operation succeeded. |
| 09:14 |
|
Dyrcona joined #evergreen |
| 09:22 |
jeff |
kmlussier: the release notes for 2.5 (as they stand now) are linked from the downloads page, iirc. Were you asking if we should do a preview of release notes earlier in the next release? |
| 09:22 |
|
graced_ joined #evergreen |
| 09:24 |
kmlussier |
jeff: You're right. They are. Sorry about that. |
| 09:24 |
|
hopkinsju joined #evergreen |
| 09:25 |
kmlussier |
Although it looks like they didn't generate the way one would have expected. |
| 09:25 |
dbwells |
kmlussier: As jeff points out, I generated release notes for the beta, but looking more carefully, I didn't do a very good job. I used the script in the docs folder, then added a bunch of :leveloffset: commands until the output looked reasonable and didn't have errors, though I now see I didn't offset some things enough. |
| 09:27 |
|
akilsdonk_ joined #evergreen |
| 09:28 |
kmlussier |
dbwells: Yes, I know eeevil did a lot of wrangling with the release notes last time and had created the script with the hope of making it a little easier. |
| 09:28 |
kmlussier |
Are the leveloffsets required because people are using different heading levels in their entries? |
| 09:30 |
dbwells |
right, exactly. And that is actually probably fine, it makes the files a little more flexible overall, I think. |
| 09:33 |
paxed |
dbwells: i've got an updated finnish translation, will it make to 2.5 if i put it up in a branch? |
| 09:33 |
kmlussier |
Dyrcona: Your phonelist release notes make excellent documentation. I think I'm going to move most of it into the core 2.5 documentation and keep the first section for the release notes. |
| 09:33 |
kmlussier |
Dyrcona++ |
| 09:35 |
paxed |
*snrk* |
| 09:36 |
Dyrcona |
kmlussier: I basically created the release notes by altering an odt that I wrote for the librarians using the software, so it was basically documentation to begin with. |
| 09:40 |
paxed |
dbwells: that's actually... perfect translation. |
| 09:43 |
dbwells |
paxed: sure, we've got a few more chances to get updated translations in. You had also asked about not using LP, I think. Now that I have at least a small understanding of how to build translations in EG, if you send me whatever files you think I need, I can see if adding them to the process manually would be a big burden going forward. |
| 09:47 |
|
yboston joined #evergreen |
| 09:49 |
paxed |
dbwells: ok. i'll do the branch later today.. |
| 09:56 |
|
mllewellyn joined #evergreen |
| 09:59 |
Dyrcona |
storing_json_in_the_database-- |
| 10:13 |
|
artunit joined #evergreen |
| 10:21 |
|
ericar_ joined #evergreen |
| 10:24 |
Bmagic |
I am attempting to come up with some basic sanity checks on all/most of the openSRF services. The API documentation doesnt seem to have examples of how to call the methods within. Anyone have some basic pointers on this subject? An example that I have found so far is my( $user, $evt ) = simplereq( STORAGE(), 'open-ils.storage.direct.actor.user.retrieve', 1 ); which seems to do a quick and |
| 10:24 |
Bmagic |
easy job of interfacing with the storage component and will tell me if it's alive or not. I would like to test some of the other services with a basic perl script. I am looking at /opac/extras/docgen.xsl - perhaps there is a better resource? |
| 10:27 |
|
mrpeters1 joined #evergreen |
| 10:27 |
senator |
Bmagic: combine the api documentation you get from docgen.xsl with this article (see parts 1 and 2) in order to know how to invoke the methods in general: http://journal.code4lib.org/articles/3284 |
| 10:28 |
senator |
if you're impatient you can skip down to "Calling OpenSRF methods from Perl applications", but all of both parts of the article are worth the read for getting the big picture |
| 10:28 |
Bmagic |
oh yeah, I've read through that, some good stuff there. It seems like each of the services have different ways to interact, am I wrong? |
| 10:29 |
Bmagic |
open-ils.vandelay and open-ils.fielder and open-ils.acq for example |
| 10:30 |
senator |
not sure what you mean. you call methods from any service in the same way. the number and type of arguments required by any given method can be totally different, as can the shape of results |
| 10:30 |
Bmagic |
right on, sounds like I'm on the right path |
| 10:30 |
jeff |
some services may not have a suitable method to call for testing purposes. others may require the creation of test objects for them to be suitable. |
| 10:31 |
jeff |
Bmagic: what are your goals? |
| 10:31 |
Bmagic |
we find ourselves having to restart these services after clients call to tell us about it |
| 10:31 |
Bmagic |
we would like to know before hand |
| 10:31 |
|
mrpeters joined #evergreen |
| 10:44 |
csharp |
Bmagic: what version of EG and OpenSRF are you running? |
| 10:54 |
kmlussier |
Do we typically put new SIP featuers in the release notes? There were a few that were added during the 2.5 window that aren't in the notes. But, in looking at previous release notes, it doesn't look as if we typically include SIP changes there. I'm just not sure if I should add them or not. |
| 10:55 |
gmcharlt |
kmlussier: if it's along the lines of Evergreen support new SIP feature X, sure, they belong -- anything that's just about the separate SIPServer project, not so much |
| 10:55 |
kmlussier |
gmcharlt: OK, thanks! |
| 11:07 |
Bmagic |
csharp: EG 2.4.1 |
| 11:11 |
Bmagic |
csharp: OpenSRF 2.2.0 |
| 11:37 |
|
smyers_ joined #evergreen |
| 11:50 |
|
rfrasur joined #evergreen |
| 12:02 |
|
jdouma joined #evergreen |
| 12:49 |
|
hopkinsju joined #evergreen |
| 13:00 |
Dyrcona |
How do we i18n-ize our Perl? Do we? |
| 13:00 |
Dyrcona |
I was looking at the gettext documentation this past weekend and it doesn't look like we're doing any of that on our Perl, or at least the parts of the Perl that I was looking at. |
| 13:01 |
jeff |
are you talking about things like utility scripts? |
| 13:01 |
Dyrcona |
yeah, mainly. |
| 13:02 |
jeff |
i don't think we currently do any i18n there. i could be wrong. |
| 13:02 |
jeff |
i'd be interested if you find any. :-) |
| 13:02 |
Dyrcona |
jeff: That's what I thought. |
| 13:02 |
Dyrcona |
Well, nothing uses Locale::TextDomain, which looks like the main way to do it with gettext and Perl. |
| 13:03 |
Dyrcona |
I was considering paxed's bug on marc_export about the messages not being localizable and considering making them localizable in my reimplementation. |
| 13:04 |
paxed |
nope no i18n in perl |
| 13:16 |
|
artunit joined #evergreen |
| 13:16 |
|
kbutler joined #evergreen |
| 13:25 |
kmlussier |
I posted a message to the list a while back regarding the error message that displays when a renewal is blocked because the # of holds exceeds the available copy/holds ratio. http://georgialibraries.markmail.org/thread/jusvpi3hqxmawegd |
| 13:26 |
kmlussier |
I didn't get a response on the list, but I was wondering if anyone here might have thoughts on how I could change the message that displays to the patron. |
| 13:28 |
|
StephenGWills joined #evergreen |
| 13:33 |
csharp |
kmlussier: I looked around for that in the code and never found it |
| 13:34 |
kmlussier |
csharp: ok, thanks for looking! :) |
| 13:34 |
* csharp |
looks again though |
| 13:36 |
csharp |
yeah no dice for grepping the source directory for "available_copy_hold_ratio" |
| 13:39 |
* Dyrcona |
is not having the best of days technologically. Everything seems to be in a conpsiracy againts me. |
| 13:40 |
* Dyrcona |
also wonders why Thunderbird loads the Google Talk plugin, but knows it is for the same reason that the staff client would load it. |
| 13:41 |
csharp |
Open-ILS/src/templates/opac/parts/hold_error_messages.tt2 |
| 13:41 |
csharp |
17: "config.circ_matrix_test.available_copy_hold_ratio" => l("The available item-to-hold ratio is too low"), |
| 13:41 |
csharp |
kmlussier: ^^ |
| 13:41 |
csharp |
line 17 |
| 13:41 |
csharp |
(in current master) |
| 13:41 |
kmlussier |
Yes, but that file is for messages for blocking a hold. |
| 13:42 |
Dyrcona |
its in the circ matrix matchpoint it isn't a stand alone setting. |
| 13:42 |
kmlussier |
The block should be for renewals. I looked at that one a while back and couldn't figure out why it didn't work. |
| 13:42 |
Dyrcona |
Or was that not the question? |
| 13:43 |
kmlussier |
Dyrcona: The question is for customizing the message that displays when a renewal is blocked because of the copy/holds ratio. |
| 13:44 |
jeff |
i don't know that there's one for checkout and one for renewal. i suspect that they share the same message. |
| 13:44 |
jeff |
oh. |
| 13:44 |
jeff |
nevermind. i see, hold. |
| 13:44 |
jeff |
rather, "holds". don't hold waiting for me. :) |
| 13:44 |
csharp |
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/100.circ_matrix.sql;h=ef829dbc1923a1977a2f170824f95ef73daa0a2d;hb=HEAD#l565 |
| 13:45 |
csharp |
that's the function that checks for that |
| 13:46 |
Dyrcona |
I'm not that familiar with the renewal mechanics in tpac, but I imagine some code might need to be changed or a new message file added with the actual message. |
| 13:46 |
csharp |
"RETURN NEXT result;" is what I would assume is pushing the 'config.circ_matrix_test.available_copy_hold_ratio' message out |
| 13:46 |
Dyrcona |
It is likely displaying the config.circ_matrix_test.available_copy_hold_ratio because tpac is failing to find the message. |
| 13:47 |
Dyrcona |
It probably needs similar plumbing added to what is being done for holds. |
| 13:48 |
csharp |
<!ENTITY circ.fail_part.config.circ_matrix_test.available_copy_hold_ratio "The available item-to-hold ratio is too low"> - |
| 13:48 |
csharp |
Open-ILS/web/opac/locale/en-US/opac.dtd line 736 |
| 13:49 |
csharp |
doesn't that look like the plumbing is already there? |
| 13:49 |
Dyrcona |
so change the entity to config.circ_matrix_test.available_copy_hold_ratio and see if that resolves it then. |
| 13:49 |
Dyrcona |
kmlussier reports not getting the message so something is messed up. |
| 13:50 |
Dyrcona |
I should shut up now 'cause I've not really looked into it beyond what I've done here. |
| 13:50 |
* csharp |
doesn't have full context either |
| 13:50 |
kmlussier |
I was wondering if the entry from opac.dtd was a leftover from jspac. |
| 13:50 |
csharp |
nor a good way to set that up for testing (quickly, anyway ;-)) |
| 13:51 |
csharp |
kmlussier: yeah - you may be right - that's the only occurrence of 'circ.fail_part.config.circ_matrix_test.available_copy_hold_ratio' I can find |
| 13:52 |
kmlussier |
Thanks for looking into it anyway! csharp++ Dyrcona++ |
| 13:53 |
Dyrcona |
I say open a launchpad bug. 'cause it looks like something is missing or at least not looking up the right string in a file somewhere. |
| 13:54 |
kmlussier |
Dyrcona: Sure, I'll do that. |
| 13:58 |
jeff |
looks like the overdrive circulation API is generally available now. we'll see if they take the full week to approve our access. |
| 13:58 |
kmlussier |
jeff: That's good news! |
| 14:00 |
jeff |
Mostly. I followed their process for submitting an inquiry regarding the API documentation (needed something clarified), and their web contact form assures me that they will route my request to the proper folk... then I received an email auto-reply stating that my message had been sent to their Sales department. :-) |
| 14:07 |
dbwells |
kmlussier: Not sure if this is in fact the problem you are having with the circ_matrix message, but the text you have pasted in MarkMail appears to have a zero width space in the middle of it. |
| 14:08 |
dbwells |
It is something like: a<ZERO WIDTH SPACE>vailable_copy_hold_ratio |
| 14:08 |
dbwells |
obviously, you can't see it :) |
| 14:10 |
kmlussier |
Heh, no I can't. :) |
| 14:10 |
dbwells |
If you try and copy/grep for 'available_copy_hold_ratio', but copy from your email on MarkMail, it magically doesn't find anything. |
| 14:10 |
csharp |
dbwells: yeah - that's what I saw too |
| 14:11 |
kmlussier |
Yeah, I tried grepping back early on, but I found the same things that csharp found when he was looking. |
| 14:11 |
dbwells |
Even if it isn't the actual source of the problem, it's a facinating little trick. Amaze your friends! |
| 14:11 |
csharp |
heh |
| 14:11 |
rfrasur |
csharp: sorry to interrupt. Is the option to turn on check out history still available in 2.3 in their account? |
| 14:11 |
csharp |
rfrasur: yes'm |
| 14:12 |
kmlussier |
I think the confusing thing is that it shows up in the file for holds messages. I have to think that was a mistake. |
| 14:12 |
rfrasur |
csharp: thank you, sir |
| 14:12 |
csharp |
rfrasur: we have those options hidden in PINES pending a policy discussion |
| 14:12 |
dbwells |
In fact, if you just copy the 'a' from the beginning of 'available', you also get the zero-width-space, so even "ack-grep a" finds nothing at all. |
| 14:13 |
rfrasur |
csharp: You have no idea how much I LOATHE the word "policy" right now...but even so. ty |
| 14:13 |
csharp |
dbwells: very interesting |
| 14:13 |
csharp |
@love policy |
| 14:13 |
pinesol_green |
csharp: The operation succeeded. csharp loves policy. |
| 14:14 |
csharp |
it's the only thing that keeps our huge consortium out of an "anything goes" state that would be very difficult to administer |
| 14:14 |
rfrasur |
@love meaningful_policy |
| 14:14 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur loves meaningful_policy. |
| 14:14 |
dbwells |
kmlussier: so, one possible theory is that, despite being basically unfindable by grep, that zero-width-space is in the DB code, and thus it fails to be the proper key on the TT side. |
| 14:14 |
rfrasur |
@hate governmental_busywork |
| 14:14 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur hates governmental_busywork. |
| 14:14 |
csharp |
@eightball is there less busywork today?> |
| 14:14 |
pinesol_green |
csharp: Yes! |
| 14:15 |
kmlussier |
dbwells: So, how can you tell if it's in the DB code? |
| 14:15 |
* kmlussier |
can't remember where she copied the text from to begin with. |
| 14:17 |
dbwells |
kmlussier: that's a good question, especially since, if it exists, it might just be in a certain upgrade script or whatnot. Have you tested this on master, or just your local install? Like I said, it might just be a weird anomaly in the email, and not related to the problem. |
| 14:18 |
kmlussier |
dbwells: It was on master from maybe a month ago. I was using Dyrcona's dev server. |
| 14:19 |
csharp |
a<200b>vailable_copy_hold_ratio |
| 14:19 |
csharp |
that's the way it displays in vim |
| 14:23 |
jeff |
there are not currently any files in master that match vailable_copy_hold_ratio and do NOT match available_copy_hold_ratio. doesn't rule out the possibility of a single-line instance of the character. |
| 14:26 |
paxed |
dbwells: user/paxed/fi-update |
| 14:27 |
dbwells |
If we don't know where the string in the email came from, that also lowers the likelihood that it was the explanation. It was surprising enough to me that I thought it worth mentioning, but it was more as something to consider for anyone doing more than guessing, which is not me today. |
| 14:27 |
csharp |
dbwells++ |
| 14:31 |
paxed |
dbwells: actually, i'll add the new translation files for finnish there too, if you wait a bit. (PCrudFilterPane.js and FlattenerGrid.js |
| 14:31 |
paxed |
) |
| 14:32 |
kmlussier |
OK, I just forced the error to display again, copied it, and pasted it into vim. The paste looks good, so I'm guessing it was something funky with the way I originally pasted it or something that was done to it in e-mail. |
| 14:33 |
kmlussier |
Well, not error, but the block message. |
| 14:33 |
kmlussier |
dbwells++ |
| 14:38 |
paxed |
dbwells: ok, those files added too. |
| 14:40 |
paxed |
and on that note, i'm off to bed. |
| 14:44 |
jeff |
wacky. git diff to the rescue, as i think I hit a stray keystroke in my editor: |
| 14:44 |
jeff |
- OpenSRF::AppSession->create('open-ils.search') |
| 14:44 |
jeff |
+ opensrf::appsession->create('open-ils.search') |
| 15:09 |
jeff |
kmlussier: bad news from overdrive... their circulation api does not work with libraries using ezproxy. they're working on it, might be a month or so. |
| 15:10 |
jeff |
i've actually no idea why it couldn't work, but that's what they say. |
| 15:10 |
jeff |
and i don't have knowledge of their internal systems. |
| 15:10 |
bshum |
o.O |
| 15:10 |
rfrasur |
(ridiculous...they've known about this for how long?) |
| 15:10 |
jeff |
i realize that it would be on us to resolve from patron to ezproxy overdrive token, if we opt to use those tokens (and we do), but i was anticipating that, and have no problem with that. :-) |
| 15:11 |
jeff |
it's possible that the matter they're working on is the "how do you create a new account" bit, but even that... seems to be more of an ezproxy thing. dunno. |
| 15:11 |
jeff |
i voiced interest in hearing more details from a developer, but we'll see. they're obviously busy and can't interact with every client. |
| 15:11 |
rfrasur |
jeff: that month means they're actively dealing with it? |
| 15:11 |
jeff |
rfrasur: that is what i was informed. |
| 15:11 |
rfrasur |
okay |
| 15:12 |
jeff |
so hopefully once they've figured out a solution to those issues, we'll be able to experiment more with the new API. |
| 15:13 |
jeff |
but i have no interest in moving to SIP-based authentication with OverDrive at this time. |
| 15:14 |
jeff |
rfrasur: you can stand down. :-) |
| 15:14 |
* rfrasur |
stands down |
| 15:14 |
rfrasur |
barely |
| 15:15 |
Dyrcona |
heh |
| 15:15 |
* senator |
remembers to pick rfrasur for dodgeball teams |
| 15:15 |
Dyrcona |
double heh. |
| 15:16 |
Dyrcona |
Anyway, I feel the same could be said about some of our bugs, "They've known about it for how long?" |
| 15:16 |
kmlussier |
jeff: hmmm, I think our consortia would be looking to do SIP-based authentication with Overdrive. Not sure though. I know they don't all use ezproxy. |
| 15:16 |
Dyrcona |
I tend to cut others a little slack with things like this. |
| 15:16 |
kmlussier |
Dyrcona++ |
| 15:16 |
rfrasur |
Dyrcona: truth...but EG is a community driven development project. |
| 15:17 |
Dyrcona |
Overdrive may be for profit, but they still have limited resources. |
| 15:17 |
|
gsams joined #evergreen |
| 15:17 |
Dyrcona |
the one thing I will not forgive is spitting out "MARC" records, that only vaguely resemble the actual MARC format. |
| 15:17 |
Dyrcona |
;) |
| 15:18 |
csharp |
@karma "MARC" |
| 15:18 |
pinesol_green |
csharp: Karma for "MARC" has been increased 0 times and decreased 7 times for a total karma of -7. |
| 15:18 |
csharp |
@karma MARC |
| 15:18 |
pinesol_green |
csharp: Karma for "MARC" has been increased 0 times and decreased 7 times for a total karma of -7. |
| 15:18 |
Dyrcona |
MARC-- |
| 15:19 |
Dyrcona |
rfrasur: Dealing with gubmint will do that. |
| 15:19 |
* rfrasur |
growls |
| 15:19 |
Dyrcona |
I'm having a pretty good day, even though I locked myself out of my home LAN, panicked, and texted my wife to shut everything off. |
| 15:20 |
Dyrcona |
The rest of the day has been about the same with little details catching me up. |
| 15:20 |
|
darth_tater joined #evergreen |
| 15:20 |
rfrasur |
And it's only Tuesday. Although...on the bright side...it's Tuesday which is my de facto favorite day right now. |
| 15:20 |
* rfrasur |
shrugs |
| 15:22 |
rfrasur |
it's impressive that you give yourself access to your home LAN anyway. |
| 15:22 |
|
jeff__ joined #evergreen |
| 15:22 |
Dyrcona |
It requires public key encryption and only certain keys are allowed. |
| 15:22 |
|
bshum_ joined #evergreen |
| 15:22 |
rfrasur |
and then automatic lockout if you mess it up? |
| 15:23 |
Dyrcona |
What I did was trip a firewall rule that locks you out if attempt 3 or more ssh connections in 30 seconds. |
| 15:23 |
rfrasur |
huh....that's kinda cool....to me. Probably pretty annoying to you. |
| 15:23 |
|
jeff___ joined #evergreen |
| 15:24 |
Dyrcona |
I think I might actually remove the rule tonight. |
| 15:24 |
Dyrcona |
I usually trip myself up with it once a year or so. |
| 15:27 |
|
ldwhalen_ joined #evergreen |
| 15:27 |
Dyrcona |
Whee! Ride the net split! |
| 15:28 |
rfrasur |
Which is why I don't need to know certain things. |
| 15:28 |
* rfrasur |
is too irresponsible for great power |
| 15:29 |
* Dyrcona |
is too powerless for responisibility.... |
| 15:29 |
Dyrcona |
responsibility, that's how you spell it. |
| 15:29 |
rfrasur |
;-) |
| 15:30 |
|
rri joined #evergreen |
| 15:33 |
rfrasur |
On the plus side, our implementation of EG is workin' like a champ today. w00t. |
| 15:34 |
Dyrcona |
We have been fielding a lot of questions today. |
| 15:34 |
Dyrcona |
Most related to our new member coming online, but others not. |
| 15:34 |
Dyrcona |
It is interesting how "events" bring out the bug reports and questions. |
| 15:34 |
rfrasur |
what kind of questions? |
| 15:35 |
Dyrcona |
Mostly about duplicate bibs and patrons. |
| 15:35 |
Dyrcona |
One about a receipt macro not working in the header. |
| 15:35 |
Dyrcona |
Another about pre-cat workflow and deleting claims returned copies. |
| 15:36 |
RoganH |
no deduping questions |
| 15:36 |
* RoganH |
hides in a deep dark hole |
| 15:36 |
rfrasur |
you have to deal with workflows? for an established member? |
| 15:36 |
bshum |
edi-- #I hate EDI questions. |
| 15:36 |
* rfrasur |
eyes RoganH |
| 15:37 |
Dyrcona |
rfrasur: yeah, but it was more about the deleting bit, the pre-cats came up because she asked about duplicate barcodes. |
| 15:37 |
Dyrcona |
Turns out their work flow is a good one for that. |
| 15:38 |
rfrasur |
Gotcha. |
| 15:38 |
Dyrcona |
bshum: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/marque-export |
| 15:38 |
Dyrcona |
That is about as working as it will get for a while. I've been given other marching orders. |
| 15:38 |
bshum |
Pretty! |
| 15:38 |
bshum |
Dyrcona++ tsbere++ |
| 15:38 |
bshum |
And aww :( |
| 15:38 |
Dyrcona |
You have to update Fieldmapper.pm, and you still have to sed Marque.pm by hand. |
| 15:39 |
Dyrcona |
When it is finally finished in my new branch, things will work nicely. |
| 15:40 |
Dyrcona |
I'd actually recommend pulling the Fieldmapper bits from another branch: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1223903-MARC-export-Mk.2 |
| 15:41 |
Dyrcona |
I have been debating with myself about splitting that one commit into its own bug. |
| 15:41 |
Dyrcona |
So far, I'm losing. :) |
| 15:41 |
bshum |
Heh |
| 15:41 |
Dyrcona |
tsbere++ # for seeing what I did wrong with the --since option. |
| 15:43 |
rfrasur |
If I run a daily recurring report (that seems redundant), do the results overwrite or is a new file name generated for each result? |
| 15:44 |
|
kbeswick joined #evergreen |
| 15:44 |
jeffdavis |
The latter, I believe. |
| 15:45 |
bshum |
That's what I would expect too. That each report output would be its own file. |
| 15:45 |
* jeffdavis |
mumbles something about where "clearing out old report output" falls on his todo list |
| 15:45 |
bshum |
jeffdavis: I did it once. A few years ago manually. |
| 15:46 |
bshum |
Or maybe it was last year... |
| 15:46 |
rfrasur |
jeffdavis++ bshum++ #thanks |
| 15:46 |
bshum |
Time flies :( |
| 15:46 |
Dyrcona |
storage is free, isn't it? ;) |
| 15:46 |
* jeffdavis |
twitches |
| 15:46 |
bshum |
I think we have policy in place to remove things after X time, but I just never got around to finishing automating all that. |
| 15:46 |
rfrasur |
it's free for member libraries >:-) |
| 15:47 |
rfrasur |
or..."free" |
| 15:47 |
Dyrcona |
Just got a fun ticket. |
| 15:48 |
rfrasur |
for real? |
| 15:48 |
Dyrcona |
I feel like saying, "Buy us an IPad 2 and we'll look into it. Otherwise, there is nothing we can do." |
| 15:48 |
rfrasur |
heh |
| 15:49 |
Dyrcona |
And boom! Added as a comment seen by our ticket handler, who is out at our new member library today. |
| 15:50 |
jeff__ |
grr. |
| 15:50 |
|
jeff__ joined #evergreen |
| 15:50 |
* Dyrcona |
plays some Entrain...seems about right for the mood. |
| 15:51 |
Dyrcona |
jeff: Grring at insipid? |
| 15:51 |
jeff |
so, pretty sure these were lost in the split: |
| 15:51 |
jeff |
kmlussier: i would want to make some changes to SIP before using it for vendor authentication. there's no reason for most vendors to have staff credentials, or to have ready access to patron contact and circulation information. |
| 15:51 |
jeff |
if more vendors supported oauth, we might have some interesting possibilities. |
| 15:51 |
jeff |
probably a bit of a chicken/egg thing, there. |
| 15:52 |
Dyrcona |
Oh, that's rich, pulling Library Vendors out of the early 1990s. Good luck with that! |
| 15:52 |
rfrasur |
even I laugh at that. but not out loud. |
| 15:52 |
Dyrcona |
Most of their products can't resolve hostnames, and you expect them to do oauth? |
| 15:53 |
jeff |
i'm not even sure *I* want to do oauth. :-) |
| 15:53 |
Dyrcona |
heh |
| 15:53 |
jeff |
probably should have said "oauth or similar" |
| 15:54 |
|
dMiller_ joined #evergreen |
| 15:54 |
tsbere |
I wouldn't mind if vendors would stop wanting referrer auth. Even if I have to give them access to SIP2. >_> |
| 15:54 |
* tsbere |
*hates* referrer auth |
| 15:54 |
Dyrcona |
That's not even auth. That's just a test if you can fake a HTTP header or not. |
| 15:55 |
Dyrcona |
bshum: 65,454 records exported in under 1 hour, more like 40 minutes. |
| 15:55 |
Dyrcona |
Just the new records I added this weekend. |
| 15:55 |
bshum |
That sounds awesome. |
| 15:55 |
Dyrcona |
With items, no less. |
| 15:56 |
jeff |
hrm. i'm using wheezy on this... i wonder if its tmux package supports iTerm2 integration yet |
| 15:57 |
jeff |
oh, nevermind. squeeze on THIS vm. |
| 15:57 |
Dyrcona |
tmux++ |
| 15:57 |
Dyrcona |
I can debug threaded perl applications with it! |
| 15:57 |
Dyrcona |
or forked ones. |
| 15:57 |
Dyrcona |
rather. |
| 15:58 |
rfrasur |
Just thinking...it'd be nice if there were autodeletes on report outputs after a certain time period. I mean, if people want the information, they can just run another report. 99 times out of a 100 nobody looks at the output twice...or they save it in spreadsheet or something locally. |
| 15:58 |
Dyrcona |
I'm wagering 99 times out of 100 nobody looks at the output even once. |
| 15:59 |
jeff |
rfrasur: do you create many report templates, or exclusively use those created by your consortium? |
| 15:59 |
rfrasur |
well, I only run reports that I want...and I look at the output. |
| 15:59 |
jeff |
(i think there's a cron script for cleaning up old report output) |
| 15:59 |
rfrasur |
Jeff..I make some...or modify existing |
| 15:59 |
jeff |
(unrelated to my inquiry) |
| 15:59 |
rfrasur |
I try to modify ones that work |
| 15:59 |
gmcharlt |
Dyrcona: I have a vision of a cronjob that checks the Apache log, then yanks reporting permission for any user that racks up 5 or more instances of never retrieving their results ;) |
| 15:59 |
* rfrasur |
has infinite looped before |
| 15:59 |
* rfrasur |
hangs head in shame again |
| 16:00 |
Dyrcona |
gmcharlt: +1 |
| 16:00 |
|
StephenGWills left #evergreen |
| 16:00 |
|
StephenGWills joined #evergreen |
| 16:01 |
jeff |
rfrasur: if you have any time now or later, i'd be interested in hearing more details / examples of a report that you've started with, and modified (the how and why). feel free to go into detail here or in msg if you're able/willing. |
| 16:01 |
jeff |
rfrasur: and thanks in advance, either way. :-) |
| 16:02 |
|
StephenGWills left #evergreen |
| 16:03 |
rfrasur |
gmcharlt: would there be a time frame though? I'd like to run a recurring report for our computer use...and I wouldn't check it until the end of the month...all the outputs. |
| 16:03 |
gmcharlt |
rfrasur: now you're taking my joke seriously! ;) |
| 16:03 |
rfrasur |
jeff: I'd love to talk about reports, but later on. |
| 16:04 |
jeff |
rfrasur: sure thing. appreciate it! |
| 16:04 |
rfrasur |
gmcharlt: because I think it's a good idea :D |
| 16:04 |
gmcharlt |
though you do raise a good point about actual usage patterns needing to be determined by asking ... actual users |
| 16:04 |
* rfrasur |
didn't realize there were people that didn't check their outputs |
| 16:04 |
jboyer-isl |
rfrasur: we do wipe out everyone's report outputs after 30 days. Recurring reports survive to report again, but their outputs go to carousel at 30. |
| 16:04 |
rfrasur |
jboyer-isl++ #because y'all rock |
| 16:07 |
|
kbeswick joined #evergreen |
| 16:08 |
jboyer-isl |
Understandable. I don't have time to be everyone's nemesis. Choosing your battles, etc. |
| 16:08 |
gmcharlt |
heh |
| 16:09 |
|
kbeswick joined #evergreen |
| 16:09 |
rfrasur |
I think I'm dealing w/ inadvertant nemesi...i? I'm fairly sure they don't realize the mess they're causing. I think. |
| 16:17 |
|
kbeswick joined #evergreen |
| 16:20 |
|
ktomita_ joined #evergreen |
| 16:21 |
Dyrcona |
bshum: At 9:30 pm tonight, I dump all the marc records with items. |
| 16:21 |
|
dMiller_ joined #evergreen |
| 16:21 |
Dyrcona |
Whee! Fines are so much "fun." |
| 16:22 |
* Dyrcona |
wonders if the nickels and dimes are worth the hassle. |
| 16:23 |
jboyer-isl |
Dyrcona: Next week I find out if I have a ton of manual billing math to deal with here, from 2 projects. :/ |
| 16:24 |
rfrasur |
jboyer-isl++ #because you put up with our mess |
| 16:24 |
jboyer-isl |
Possibly trying to distribute the "loss" from online CC payments, and trying to determine how much of a payment goes toward other lib's lost billings vs. your own overdue billings. (Because those overdue fees for items you don't own are keeping the lights on!) |
| 16:27 |
* rfrasur |
agrees, more and more, with the no fine model. Alas. |
| 16:28 |
|
smyers__ joined #evergreen |
| 16:36 |
|
smyers_ joined #evergreen |
| 17:04 |
|
ktomita joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 18:04 |
|
dMiller__ joined #evergreen |
| 18:05 |
|
smyers_ joined #evergreen |
| 18:26 |
|
leofseige joined #evergreen |
| 18:34 |
|
dMiller_ joined #evergreen |
| 18:59 |
|
dMiller joined #evergreen |
| 19:05 |
smyers_ |
phasefx: Hey are you around to talk about your experiance with lp 1161122 moving a xul page to tt2 |
| 19:05 |
pinesol_green |
Launchpad bug 1161122 in Evergreen "rejiggered staff client patron search, summary, display" (affected: 3, heat: 16) [Wishlist,Triaged] https://launchpad.net/bugs/1161122 |
| 19:31 |
|
fparks_ joined #evergreen |
| 20:59 |
jeffdavis |
Given an org unit SYS1 with children BR1, BR2, and BR3, is it possible to expose SYS1 as a Z39.50 target database that shows BR1 and BR2's holdings but not BR3's? |
| 21:21 |
jeffdavis |
I guess this is equivalent to asking if it's possible to (a) do a Supercat search across multiple specified org units, and (b) express that search via an SRU GET request. |
| 21:22 |
* jeffdavis |
notes that loc.gov is unavailable to due the gov't shutdown, shakes fist at [insert your preferred political adversary here] |
| 22:52 |
|
moodaepo_nb joined #evergreen |
