| Time |
Nick |
Message |
| 01:06 |
|
Mark__T joined #evergreen |
| 02:16 |
|
jonadab_znc joined #evergreen |
| 07:24 |
|
Dyrcona joined #evergreen |
| 07:37 |
|
jboyer-isl joined #evergreen |
| 07:44 |
|
collum joined #evergreen |
| 07:45 |
|
ericar joined #evergreen |
| 07:45 |
|
mrpeters joined #evergreen |
| 07:58 |
|
Dyrcona joined #evergreen |
| 08:07 |
|
rjackson_isl joined #evergreen |
| 08:30 |
|
maryj joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 09:04 |
|
jwoodard joined #evergreen |
| 09:10 |
|
Khanson_ joined #evergreen |
| 09:11 |
Dyrcona |
It's alive! |
| 09:14 |
remingtron |
Dyrcona++ #leading quite fearlessly |
| 09:14 |
Dyrcona |
That doesn't mean it is uploaded, just that a fresh install from the tarball works. |
| 09:15 |
Dyrcona |
I, uh, don't actually know if I can upload to the webserver, and even if so, dunno what credentials, etc. |
| 09:15 |
mmorgan |
Dyrcona++ |
| 09:18 |
|
Shae joined #evergreen |
| 09:23 |
|
yboston joined #evergreen |
| 09:29 |
jboyer-isl |
Dyrcona++ |
| 09:31 |
bshum |
FYI to web admins, I just gave Dyrcona an account on lupin |
| 09:32 |
Stompro |
Dyrcona++ |
| 09:32 |
kmlussier |
Dyrcona++ |
| 09:42 |
bshum |
kmlussier: Can you remind me, do we put 2.9 onto the farthest left column of the egdownloads page? Or do we only move it there after it becomes "stable"? |
| 09:42 |
kmlussier |
My recollection is that 2.8 was on the farthest left column when it was still in beta. |
| 09:43 |
bshum |
Okay works for me. |
| 09:43 |
* bshum |
starts shifting html |
| 09:43 |
kmlussier |
Also, I imagine it's easier for you that way, rather than shuffling all the releases around in another few weeks. :) |
| 09:43 |
bshum |
"easier" sure |
| 09:54 |
|
RoganH joined #evergreen |
| 09:58 |
berick |
@praise bshum |
| 09:58 |
* pinesol_green |
bshum is one of the few who deserves to be praised |
| 09:58 |
bshum |
And downloads page updated |
| 09:59 |
Dyrcona |
bshum++ |
| 09:59 |
bshum |
I took 2.6 off the page, since that's traditionally how it's done. |
| 09:59 |
bshum |
Removing that means we likely can also take OpenSRF 2.3 off that page too |
| 10:00 |
bshum |
Since all current versions of Evergreen rely on OpenSRF 2.4 now |
| 10:01 |
kmlussier |
bshum++ |
| 10:03 |
Stompro |
Good morning Evergreeners, Has anyone ever setup a batch process to move users from one permission group to another. We have Child, Youth and Adult permission groups, and I'm just wondering if there are any gotchas to moving patrons between groups based on their age? Is it as simple as changing actor.usr.profile? |
| 10:04 |
kmlussier |
I'm sure there are still several typos in the release notes, but the Authoirty one that made it into a heading is bugging me. |
| 10:04 |
tsbere |
Stompro: In theory it is that easy. In practice there may be issues if limits differ between them requiring a re-gen of standing penalties.... |
| 10:05 |
jeff |
also if you make use of the "juvenile" flag -- there's an existing script that can be used for removing that. |
| 10:07 |
Stompro |
tsbere, jeff thanks, I'll look into the standing penalties and I'll make sure I know why we are not using the juvenile flag feature. |
| 10:07 |
tsbere |
Stompro: Probably because it is only able to do two levels (juvenile and non-juvenile) instead of the three you have, plus probably isn't exported quite a nicely in places like SIP ;) |
| 10:08 |
jeff |
Stompro: to be clear, I'm not advocating that you start using the Juvenile flag if you aren't already, I just wanted to mention it as something you should remember if you DO use it / care about it. :-) |
| 10:11 |
|
rdf19802001 joined #evergreen |
| 10:11 |
bshum |
kmlussier: Heh, yeah I cringed when I saw that too :) |
| 10:12 |
berick |
bshum: hm, the server_upgrade.txt file has to be manually changed each time? |
| 10:13 |
kmlussier |
bshum: It will provide me with motivation to copy edit the release notes sooner rather than later. |
| 10:13 |
bshum |
berick: I've been doing it since Stompro made LP tickets and code to do it during 2.8 cycle. |
| 10:13 |
bshum |
Or maybe it was someone else... and Stompro |
| 10:13 |
Stompro |
tsbere, I don't think we will be using any of the standing penalties across those permission groups.. so hopefully that won't be a problem. |
| 10:13 |
bshum |
So to avoid having them continually open tickets, I just made it a habit :) |
| 10:13 |
berick |
bshum: tell me more of this code... |
| 10:14 |
bshum |
berick: By code I just mean, that they provided a patch to update the doc files |
| 10:14 |
berick |
ah, gotcha |
| 10:14 |
berick |
i'll add a note to the release wiki about that |
| 10:14 |
bshum |
I've just been hand editing as I go as a reminder to myself post-release, oh yes, we're on version X now. |
| 10:14 |
Stompro |
I've been toying with idea of setting variables in the docs for the version, etc, the stuff that has to be updated. It makes reading the plain asciidocs harder, but it would make updating the install docs easier. |
| 10:16 |
jeff |
Hrm. Does asciidoc offer an ascii output option? Seems almost... wrong. |
| 10:16 |
kmlussier |
Stompro: For all of the docs? |
| 10:17 |
* berick |
still needs to push his tag branch |
| 10:18 |
kmlussier |
Never mind. I just realized my follow-up question was not an issue. |
| 10:18 |
Stompro |
kmlussier, I hadn't thought about doing it for all the docs, just the install and upgrade sections. I don't know how often the specific version is mentioned in the docs in general, and if it would work to have that auto set. |
| 10:18 |
bshum |
Dyrcona: When you can push your tag branch for 2.9-beta out, we should forward port any i18n changes to master. |
| 10:19 |
kmlussier |
Stompro: No, I don't think it would work to auto set it there. I sometimes see a version mentioned in the context of "this feature is new to 2.x" |
| 10:19 |
bshum |
So that it gives time for LP to start churning through changes during the next sync-ups |
| 10:19 |
kmlussier |
I try to edit those references out when I happen to be in the file. |
| 10:20 |
Stompro |
kmlussier, I've been adding those in when I document features.... why don't you like that info in the docs? |
| 10:20 |
Dyrcona |
To git git.evergreen-ils.org:Evergreen.git |
| 10:20 |
Dyrcona |
* [new branch] rel_2_9_beta -> tags/rel_2_9_beta |
| 10:21 |
kmlussier |
Stompro: Because it usually sticks around in the docs from release to release. I think it's useful when it's first documented, but it sometimes looks odd four releases down the road. |
| 10:21 |
Dyrcona |
Otherwise, I'm busy setting up coloring book limits. ... |
| 10:21 |
bshum |
Okay |
| 10:23 |
Stompro |
kmlussier, the reason I find it useful is it helps me know where to look for more info if the docs are not detailed enough. I know which release to search the commits for, to find more details. |
| 10:24 |
kmlussier |
Stompro: I guess it all depends in how it's worded. If it says something like "now, in release 2.x" we have clients that serve you coffee" it's odd to read when you're on 4.x. |
| 10:25 |
kmlussier |
If it's a simple statement of which release the feature was introduced, then I think that's fine. |
| 10:25 |
Stompro |
kmlussier, That makes sense... I've been adding something like "Released: Evergreen 2.4 in 2012" as more of a tag. |
| 10:25 |
kmlussier |
When I say I edit it out, I think it's happened maybe once or twice with a statement that made it seem like it was a new feature. |
| 10:26 |
|
sallyf joined #evergreen |
| 10:26 |
kmlussier |
Stompro: Yeah, that seems fine to me. |
| 10:26 |
* mmorgan |
didn't know the clients could serve coffee. How did I miss that? ;-) |
| 10:26 |
berick |
mmorgan: it's decaf |
| 10:26 |
mmorgan |
:-( |
| 10:26 |
kmlussier |
mmorgan: I'm just going to start putting my personal wishlist into the documentation. |
| 10:26 |
mmorgan |
berick++ |
| 10:26 |
kmlussier |
berick: Boo! |
| 10:27 |
berick |
heh, we'll get there! |
| 10:27 |
pinesol_green |
[evergreen|Bill Erickson] Forward porting 2.8.2->2.8.3 SQL upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ed4280c> |
| 10:27 |
* mmorgan |
ponders writing a launchpad bug for a YAOUS: Decaf or Regular... |
| 10:28 |
kmlussier |
mmorgan: And for flavors! |
| 10:31 |
jboyer-isl |
Much like the MCP's transition from playing Chess to running all of ENCOM, today is the day that Evergreen begins it's transition from mere ILS to Barista Management System that can also organize some books. |
| 10:36 |
Stompro |
I'll start a bug about possibly using macros in asciidoc for the install/upgrade instructions to make updating them a little easier. |
| 11:03 |
|
Christineb joined #evergreen |
| 11:09 |
|
mllewellyn joined #evergreen |
| 11:20 |
|
kmlussier left #evergreen |
| 11:20 |
|
kmlussier joined #evergreen |
| 11:42 |
|
sandbergja joined #evergreen |
| 11:48 |
|
dcook__ joined #evergreen |
| 11:54 |
kmlussier |
Bmagic: I just set bug 1436987 to Confirmed. But that's something you can do too when confirming a bug - just to help get some of those bugs out of New status. :) |
| 11:54 |
pinesol_green |
Launchpad bug 1436987 in Evergreen "Patron search parameters not retained" (affected: 3, heat: 14) [Undecided,Confirmed] https://launchpad.net/bugs/1436987 |
| 11:55 |
remingtron |
Dyrcona: I think bug 1484281 is a release-blocker. I marked it as "high". |
| 11:55 |
pinesol_green |
Launchpad bug 1484281 in Evergreen "authority data may be deleted during propagation with current values of authority.control_set_authority_field" (affected: 1, heat: 10) [High,Confirmed] https://launchpad.net/bugs/1484281 |
| 11:56 |
remingtron |
Dyrcona: I just didn't want it to get overlooked. |
| 11:56 |
Dyrcona |
If "High" was a release blocker, we'd never release. |
| 11:56 |
* Dyrcona |
was actually considering dropping all of the High importance bugs to Medium, 'cause no one seems to be working on them. |
| 11:57 |
yboston |
remingtron & Dyrcona: I have a working branch for that authoirty bug |
| 11:57 |
remingtron |
Dyrcona: how would you like me to mark it then? release-blocker tag? This bug loses data, so maybe it's "critical"? |
| 11:57 |
Dyrcona |
Critical would be better. :) |
| 11:57 |
yboston |
remingtron & Dyrcona: I even have a pgTAP test; I just need to learn how to write code for upgrades :( |
| 11:58 |
Dyrcona |
I changed it. |
| 11:58 |
Dyrcona |
yboston: push the branch and update the bug, please. |
| 11:58 |
yboston |
even without the upgrade code? |
| 11:58 |
remingtron |
Dyrcona: okay, thanks. |
| 11:58 |
yboston |
Dyrcona: the branch is on working already, for the record |
| 12:00 |
remingtron |
yboston: yeah, post your working branch to the bug with a note about the missing upgrade script and maybe someone can add it |
| 12:00 |
yboston |
remingtron: OK |
| 12:01 |
remingtron |
yboston++ #already has a branch |
| 12:01 |
Dyrcona |
better, yet, yboston could write the upgrade script. :) |
| 12:01 |
yboston |
Dyrcona: yes, I was goign to get on IRC today to ask about it |
| 12:05 |
csharp |
decaf++ |
| 12:05 |
mmorgan |
I'm trying to test run a Mark Lost trigger and am getting this error in the logs: [2015-08-20 11:43:25] open-ils.trigger [ERR :796:MarkItemLost.pm:35:1440085239182770] trigger: MarkItemLost failed with event NO_SESSION |
| 12:06 |
mmorgan |
Any suggestions? |
| 12:06 |
yboston |
this is my branch, but I now realize the editor I sued screwed up the line endigns on one fo the files; and thinks every line has a change http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ysuarez/lp1465830_fix_auth_data_propagation_deletes |
| 12:06 |
csharp |
mmorgan: how are you testing? |
| 12:06 |
yboston |
will add update to the bug |
| 12:07 |
|
bmills joined #evergreen |
| 12:07 |
mmorgan |
csharp: in the client, entering a barcode in the Test box for the action trigger. |
| 12:07 |
csharp |
yboston: this may help: https://help.github.com/articles/dealing-with-line-endings/ |
| 12:08 |
Dyrcona |
decaf-- |
| 12:08 |
csharp |
@karma decaf |
| 12:08 |
pinesol_green |
csharp: Karma for "decaf" has been increased 1 time and decreased 1 time for a total karma of 0. |
| 12:08 |
csharp |
heh |
| 12:08 |
RoganH |
decaf-- |
| 12:08 |
csharp |
decaf++ |
| 12:08 |
csharp |
decaf++ |
| 12:08 |
csharp |
decaf++ |
| 12:08 |
csharp |
ha! |
| 12:08 |
yboston |
csharp: thanks, but this is the first time it has happened, though I think ti was because of a new editor I was using. Actually it was Github's Atom editor. My regular Mac editor has never caused this so far |
| 12:09 |
RoganH |
csharp: Ah, but I have sleepless dogs so at 2 am the victory will be mine. |
| 12:09 |
yboston |
csharp: I will still look over the link |
| 12:09 |
Dyrcona |
I should have brought a knife for my salad. |
| 12:10 |
|
grharry2 joined #evergreen |
| 12:10 |
csharp |
yboston: maybe the editor composes file with CRLF line endings by default in an attempt to be helpful to windows users :-) |
| 12:10 |
|
grharry2 left #evergreen |
| 12:11 |
yboston |
csharp: that is what I need to look at; I used Atom because it handled coloring PG comments better than my editor (textmate) |
| 12:13 |
* Dyrcona |
opines: It is 2015 and we're still dicking around with line endings...Seriously? |
| 12:13 |
Dyrcona |
We're doomed as a species. |
| 12:14 |
mmorgan |
...and we have no knives for our salads. ;-) |
| 12:15 |
* bshum |
enjoys Sublime Text |
| 12:16 |
RoganH |
yboston: can you customize the highlighting in textmate like you can in bbedit? |
| 12:17 |
yboston |
RoganH: maybe |
| 12:18 |
RoganH |
yboston: bbedit (mac) has a plugin like sturucture so you can build your own highlighting, share them with other folks, etc... |
| 12:19 |
RoganH |
yboston: and I apologize for butchering english spellings there. gah, I'm leaving in ten minutes, thank goodness. |
| 12:49 |
|
tProkrym joined #evergreen |
| 12:56 |
|
jihpringle joined #evergreen |
| 13:05 |
jeff |
seems downright dead in here compared to yesterday's hustle and bustle. :-) |
| 13:06 |
|
dkyle joined #evergreen |
| 13:08 |
gsams |
I'm not dead! |
| 13:08 |
bshum |
I see your patch, and raise you 20. |
| 13:15 |
kmlussier |
Yesterday was fun. We should do it again sometime soon! :) |
| 13:47 |
|
collum joined #evergreen |
| 14:00 |
|
TanyaP joined #evergreen |
| 14:00 |
kmlussier |
I know the volume/copy editor code went into master, but is it on webby yet? |
| 14:01 |
kmlussier |
Oh, never mind, I see it now. |
| 14:08 |
|
TanyaP joined #evergreen |
| 14:10 |
TanyaP |
no EOB meeting today? |
| 14:11 |
kmlussier |
TanyaP: No, I saw that bshum canceled it on the eob list. |
| 14:12 |
TanyaP |
ok. thanks. Do you know if the EOB has looked at the budget, sponsorship, and logo at all? |
| 14:12 |
kmlussier |
Is there a way to add a volume in the web client? I'm not seeing anything, but maybe I'm missing something obvious. |
| 14:13 |
kmlussier |
TanyaP: hmmm...I haven't been paying close attention, but I thought I saw the budget approved? But I might have been dreaming or remembering the last conference. |
| 14:14 |
kmlussier |
bshum / yboston: Could either of you answer TanyaP's questions? |
| 14:14 |
kmlussier |
TanyaP: While you're organizing the conference, you might want to sign u p for the eob list since conference stuff sometimes comes up there. |
| 14:16 |
kmlussier |
Actually, it's not a bad idea for anyone to sign up even without the conference. Just to keep our eye on things. :) |
| 14:19 |
miker |
kmlussier: re webby, vol/ copy is not complete in master. it's in heavy flux right now, too. just as a head's up... |
| 14:20 |
kmlussier |
miker: OK, good to know. Do you know if we'll have a nice one-click Add Volumes link in the header like we currently do? |
| 14:21 |
kmlussier |
miker: Sorry to put you on the spot while things are still in flux, but enquiring minds want to know. :) |
| 14:22 |
|
jlitrell joined #evergreen |
| 14:25 |
yboston |
TanyaP: are you still around? |
| 14:27 |
miker |
kmlussier: I'm not in front of a computer atm, so I lack the context to answer... sorry |
| 14:28 |
kmlussier |
miker: No problem |
| 14:28 |
|
jihpringle joined #evergreen |
| 14:33 |
kmlussier |
yboston: I don't know if TanyaP's still around, but do you have a moment for a quick pm? |
| 14:49 |
|
dkvit joined #evergreen |
| 14:51 |
csharp |
argh - more acq issues... |
| 14:51 |
csharp |
EDI message processing is failing with the error "Can't call method "id" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/Application/Acq/EDI.pm line 855." |
| 14:52 |
csharp |
that line is within the cancel_lids subroutine in that file, and I can't seem to figure out why it's even being called, and why it's failing when there isn't a cancel_reason present |
| 14:53 |
kmlussier |
csharp: Is the EDI message an order response with a cancellation? |
| 14:53 |
csharp |
in any case, the effects of this is that multiple EDI accounts with the same vendor are downloading and trying to process the same file every night and failing, causing a proliferation of unhelpful EDI messages |
| 14:54 |
csharp |
kmlussier: I don't think so |
| 14:54 |
csharp |
still trying to suss this out |
| 14:54 |
csharp |
god I hate acq |
| 14:54 |
csharp |
having to learn to read EDI strings to debug this kind of thing is just icing on the cake |
| 14:55 |
csharp |
the remote file that's being evaluated worked once, and since then it's failing every time it gets processed |
| 14:56 |
csharp |
apparently the duplicate detection needs to read the EDI before deciding whether the file has already been retreived |
| 15:00 |
|
TanyaP left #evergreen |
| 15:18 |
|
berowskim joined #evergreen |
| 15:21 |
|
dkvit joined #evergreen |
| 15:26 |
|
yboston_ joined #evergreen |
| 15:26 |
|
dcook joined #evergreen |
| 15:33 |
|
jacobsd joined #evergreen |
| 15:33 |
|
Christineb_away joined #evergreen |
| 16:01 |
Stompro |
Question about billing for item replacement + processing fee? Is there any way to vary the amount of time before we bill based on the circ rule? Or is it just controled by running the lost/long-overdue A/T? We are used to it being tied to the circ rule in Millennium. |
| 16:03 |
Dyrcona |
Stompro: It's done by A/T |
| 16:03 |
Dyrcona |
Nothing in the circ matrix about it. |
| 16:03 |
Stompro |
We are used to charging a one time overdue fee at the same time we charge for replacement and processing. If they bring back the item, the replacement and processing fee go away and they just owe the fine. |
| 16:04 |
|
mrpeters joined #evergreen |
| 16:05 |
Dyrcona |
Stompro: Well, there's a setting to control if overdues are voided for lost items, so you can charge overdue + lost + processing fee. |
| 16:06 |
Dyrcona |
Stompro: You can also control what is voided at checkin. |
| 16:06 |
kmlussier |
You can also enable a setting that adds a new overdue fines that have accrued since the item was set to lost. |
| 16:06 |
mmorgan |
So the fine part could be in the circ matrix, right? |
| 16:07 |
Dyrcona |
The overdue fine is determined by the circ_matrix: recurring_fine_rule |
| 16:07 |
Dyrcona |
And max_fine_rule |
| 16:11 |
mmorgan |
So the recurring fine/max fine could be set up to apply at the same time the Lost trigger runs. Adding all those charges at the same time. |
| 16:11 |
mmorgan |
Then the options to void the lost billing and processing fee when the item is returned could be true, leaving only the fine. |
| 16:12 |
Dyrcona |
mmorgan: No, it's better letting them accrue. |
| 16:12 |
kmlussier |
mmorgan: That's good problem solving there! |
| 16:13 |
Dyrcona |
I seriously do not want yet another logical branch in fine calculation that does something totally different from the current code, all hanging off of a setting. |
| 16:13 |
Dyrcona |
The code is messy enough already. |
| 16:14 |
Stompro |
The only problem is that we have varying grace periods. So we want DVD's to get billed 14 days after overdue, we want books to be billed 21 days after overdue... |
| 16:14 |
mmorgan |
Why another setting? |
| 16:15 |
Dyrcona |
mmorgan: Because not everyone wants to have fines generated that late, so there would need to be a setting to have the newly described behavior occur. |
| 16:16 |
kmlussier |
But I don't think mmorgan is suggesting something that changes the code. |
| 16:16 |
kmlussier |
Unless I misunderstood. |
| 16:16 |
mmorgan |
When setting up a recurring fine rule, couldn't the recurrence interval be set to something like 14 days? |
| 16:17 |
mmorgan |
I wasn't suggesting a code change. |
| 16:17 |
Stompro |
Yes, I don't think having the single $2 fine is the problem, that is in the rules. But the A/T move to lost seems like it can only be run based on x number of days from due date. |
| 16:18 |
Dyrcona |
It could be, but then if it is a day or two late, fines are not calculated at all. |
| 16:18 |
Dyrcona |
Or, really, if it is late less than 14 days, no fines. |
| 16:18 |
Stompro |
Where X is the same for the whole org unit. |
| 16:19 |
mmorgan |
Stompro: Do you use different circulation modifiers for books vs dvds? |
| 16:19 |
kmlussier |
Stompro: So you want the lost fee to apply at different intervals depending on the circ rule that's in play? |
| 16:20 |
Stompro |
mmorgan, Yes, that is what I'm looking to do. We do have different circ modifiers for books vs dvds. |
| 16:21 |
kmlussier |
OK. I can't think of a way to do that. |
| 16:22 |
Stompro |
But we can adapt also. .... but the more I think about it, the more it really doesn't matter. Since if they bring it back... I think we just like the scare factor of sending out a bill with the replacement charge on there, a few weeks after the due date.... Maybe we add in a second overdue or something. |
| 16:22 |
mmorgan |
Stompro: For our overdue notices, we have triggers that use filters so that this trigger runs for items checked out at this ou, etc. I expect the same sort of thing could be done for the Lost trigger. |
| 16:22 |
mmorgan |
Using a filter to say only run this trigger for items with this circ modifier. |
| 16:23 |
* mmorgan |
has not actually done this. |
| 16:24 |
Stompro |
That would be great. Is that in the action_trigger_filters.json? |
| 16:24 |
Stompro |
Can I see what your overdue filter looks like? |
| 16:26 |
Stompro |
Do you setup a seperate hook for each group? |
| 16:27 |
mmorgan |
We have a bunch of separate filters, like a_t_filters.7_day_od.json, etc. I'll grab a sample... |
| 16:27 |
kmlussier |
Shouldn't MARC Batch Import/Export (aka Vandelay) be listed on this page? http://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:dev_sprints:2 |
| 16:28 |
bshum |
kmlussier: It is, it's squashed with the z39.50 section and crossed out? |
| 16:28 |
bshum |
Probably should be its own bullet |
| 16:28 |
bshum |
Likely bad wiki syntax |
| 16:28 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "a_t_filters.7_day_od.json" (14 lines) at http://paste.evergreen-ils.org/26 |
| 16:28 |
kmlussier |
bshum: Ah, I see. Last one. |
| 16:29 |
bshum |
Yep |
| 16:29 |
bshum |
</dev> instead of </del> for two lines |
| 16:29 |
bshum |
Well lots of them |
| 16:29 |
bshum |
Like all of them in that block |
| 16:30 |
bshum |
That's what's causing the wrong display |
| 16:30 |
mmorgan |
Stompro: each filter is called by the crontab entry that runs the trigger |
| 16:30 |
* bshum |
assumes jeff is fixing it |
| 16:31 |
mmorgan |
Stompro: We don't have separate hooks. |
| 16:31 |
jeff |
it was a markup error -- fixed. |
| 16:31 |
bshum |
jeff++ |
| 16:31 |
hopkinsju |
Yo kids! Who's got a bunch of authority records loaded into their system that they want to show off? |
| 16:31 |
hopkinsju |
First week of school here in MO, time for show and tell. |
| 16:33 |
mmorgan |
Stompro: Adapting can be good :) Current practices are often the result of how the current system works. |
| 16:34 |
kmlussier |
jeff++ |
| 16:39 |
Bmagic |
anyone work with MARC in perl? I get utf8 "\xC5" does not map to Unicode at /usr/lib/perl/5.14/Encode.pm line 174. and it quits. I need MARC::Record to continue to the next record. gmcharlt ? |
| 16:41 |
Dyrcona |
Bmagic: Wrap that in an eval{} |
| 16:41 |
Bmagic |
ah! Of course |
| 16:43 |
Stompro |
Ahhh, ok, so each filter is in it's own file, and you use the --custom-filters= to select it. It is beginning to make sense. |
| 16:43 |
Stompro |
mmorgan, thanks for the info. |
| 16:43 |
Stompro |
mmorgan++ |
| 16:53 |
jeff |
The Merit Support Center has updated Service Request [number]. You may view the full request by visiting: [url that doesn't work] |
| 16:53 |
jeff |
[we are not including the actual content of the update here because that would be too useful] |
| 16:53 |
jeff |
[and probably "omg insecure" or something, we're not really sure.] |
| 16:57 |
jeff |
and... wrong channel. sorry! :-) |
| 16:57 |
jeff |
</rant> |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:09 |
mmorgan |
</day> Good Night All! |
| 17:09 |
Stompro |
mmorgan, excellent, since the grace period is in the circ, it will be easy to filter on that. I think this will work without too much pain. |
| 17:10 |
Stompro |
And we don't need to ever change the way we do things tradition++ |
| 17:10 |
mmorgan |
Stompro++ |
| 17:10 |
|
mmorgan left #evergreen |
| 17:12 |
|
buzzy joined #evergreen |
| 17:34 |
|
Christineb joined #evergreen |
| 18:07 |
|
finnx joined #evergreen |
| 19:33 |
pinesol_green |
[evergreen|Ben Shum] LP#1486800: Remove Penalty.pm from MANIFEST - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=062365c> |
| 21:44 |
|
dcook__ joined #evergreen |
| 23:58 |
|
ldw joined #evergreen |
