| Time |
Nick |
Message |
| 01:35 |
|
Mark__T joined #evergreen |
| 02:51 |
|
Rish joined #evergreen |
| 03:54 |
|
zxiiro joined #evergreen |
| 06:57 |
|
timf joined #evergreen |
| 07:41 |
|
rjackson-isl joined #evergreen |
| 07:41 |
|
rjackson_isl joined #evergreen |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 08:03 |
|
kmlussier joined #evergreen |
| 08:11 |
|
jboyer-isl joined #evergreen |
| 08:16 |
|
akilsdonk_ joined #evergreen |
| 08:38 |
|
mrpeters joined #evergreen |
| 08:40 |
|
kbeswick joined #evergreen |
| 08:52 |
|
collum joined #evergreen |
| 08:54 |
|
adbowling-isl joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 09:03 |
|
Shae joined #evergreen |
| 09:26 |
|
artunit joined #evergreen |
| 09:52 |
|
Dyrcona joined #evergreen |
| 09:52 |
|
mmorgan joined #evergreen |
| 10:23 |
|
mcooper joined #evergreen |
| 10:24 |
|
rfrasur joined #evergreen |
| 10:24 |
remingtron |
csharp++ #for reviewing tons of beta blockers! |
| 10:24 |
berick |
hm, hackaway got in the way of 2.3.11 release cutting.. will have to remedy that. |
| 10:24 |
berick |
csharp++ |
| 10:39 |
remingtron |
berick: I think there's a 2.5beta due today also. Do you have time to push in some remaining beta blockers? Most have been reviewed. |
| 10:40 |
remingtron |
or, since you're busy with 2.3.11, could you nudge other committers? |
| 10:40 |
remingtron |
(sorry for adding more to your plate!) |
| 10:41 |
kmlussier |
At the hack-a-way, we had talked about including the mobile catalog code in 2.5. Is that still the plan? And, if so, do we need to file a Launchpad bug? |
| 10:42 |
remingtron |
kmlussier: launchpad bug couldn't hurt. |
| 10:43 |
berick |
+1 to LP bug and maybe encouraging others to poke the tpac and see if anything seems off |
| 10:43 |
* kmlussier |
will file the bug |
| 10:44 |
remingtron |
kmlussier: I recall dbwells saying he would like to see some separation of code, so that 2.5 upgraders don't get "new mobile catalog! (and other funny changes...)" |
| 10:45 |
remingtron |
kmlussier: and if that comment doesn't make sense, ask dbwells when he's in later this morning. I'm known for mangling his comments. |
| 10:45 |
berick |
remingtron: indeed, i have a few items that csharp reviewed that I'd like to merge today |
| 10:45 |
* berick |
also owes bshum a patch |
| 10:45 |
berick |
or, wait, maybe I pushed it already ready.. /me looks |
| 10:47 |
* dbs |
supposes he could break out some of the TPAC fixes vs. Mobile TPAC enhancements into separate bugs (e.g. change "Search <> for <> <query type> in <>" to "Search: <> Format: <> Query type: <> Library: <>") |
| 10:47 |
kmlussier |
dbs: Should I hold off on filing my bug then? |
| 10:48 |
* kmlussier |
won't be able to help much on this as she is about to join the first of four conference calls for the day. :( |
| 10:48 |
dbs |
kmlussier: No, I think that trying to break all of those pieces out is a huge amount of overhead. |
| 10:49 |
kmlussier |
OK, then, here it is bug 1229226 |
| 10:49 |
pinesol_green |
Launchpad bug 1229226 in Evergreen "Public catalog needs to be more mobile friendly" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1229226 |
| 10:49 |
dbs |
kmlussier++ |
| 10:49 |
berick |
kmlussier++ |
| 10:50 |
|
hopkinsju joined #evergreen |
| 10:54 |
berick |
bshum: the vandelay fix I promised is at working/user/berick/vandelay-ui-load-missing-async-item |
| 11:11 |
|
tspindler joined #evergreen |
| 11:12 |
berick |
grabbing 0833 |
| 11:16 |
pinesol_green |
[evergreen|Bill Erickson] Repair Vandelay async startup data retrieval - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=243dca2> |
| 11:16 |
bshum |
berick++ #pushed that fix to master and I'll go update the bug accordingly. |
| 11:16 |
berick |
bshum: ah, cool. didn't see the bug |
| 11:17 |
bshum |
berick: No worries, I think it got buried. |
| 11:20 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 11:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1218597 tpac self-reg refresh page for privacy - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f579796> |
| 11:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1218597 TPAC honors opac.username_regex setting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2b134c9> |
| 11:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1218597 Load pending patron via double-click - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b720d32> |
| 11:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1218597 pending patron row-date IDL label change - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1276203> |
| 11:20 |
pinesol_green |
[evergreen|Bill Erickson] Stamping 0833 : self-reg timeout - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ada002e> |
| 11:22 |
|
dboyle joined #evergreen |
| 11:39 |
|
smyers_ joined #evergreen |
| 11:44 |
|
dconnor joined #evergreen |
| 11:46 |
|
mrpeters1 joined #evergreen |
| 11:48 |
|
mrpeters joined #evergreen |
| 11:50 |
|
jdouma joined #evergreen |
| 11:53 |
|
mrpeters left #evergreen |
| 11:54 |
|
mrpeters joined #evergreen |
| 12:00 |
jeff |
containers, buckets, bookbags, lists... I'm reminded of the "SEO consultant walks into a bar" joke. :-) |
| 12:01 |
bshum |
jeff: I always liked bookbags |
| 12:01 |
bshum |
Like carrying my bookbag to school :) |
| 12:02 |
|
kmlussier joined #evergreen |
| 12:02 |
jeff |
a long-ago OPAC had the requirement that you add books to your "bookbag" before placing them on hold, and it always struck me as a bit of a stretch to borrow from the (already a bit strained) "shopping cart" metaphor from an e-commerce context, so I'm a bit jaded on that particular term. :-) |
| 12:03 |
jeff |
i like "lists" -- and that seems to be the public-facing term that has been settled upon, so that's good. :-) |
| 12:03 |
jeff |
all of that said, i enjoy my new backpack. it did very well over the week. :-) |
| 12:04 |
kmlussier |
The problem with "bookbags" is that it implies you're only adding books to the bag. |
| 12:05 |
jeff |
an excellent point. who ever heard of a moviebag? ;-) |
| 12:06 |
jeff |
has anyone else here had a desire to sort a list when retrieving / displaying? looks like the data is there, so it shouldn't be too terribly difficult to implement. |
| 12:06 |
kmlussier |
Or a realiabag? ;) |
| 12:06 |
* jeff |
consults launchpad |
| 12:07 |
|
mrpeters1 joined #evergreen |
| 12:07 |
Dyrcona |
I prefer barf bag. |
| 12:08 |
Dyrcona |
IOW, people get so hung up on terminology. |
| 12:12 |
|
mrpeters joined #evergreen |
| 12:12 |
rfrasur |
what's a movie bag? |
| 12:12 |
rfrasur |
(she asked...ten years later) |
| 12:14 |
|
mrpeters joined #evergreen |
| 12:14 |
* Dyrcona |
renames it to tea kettle and is done with it. ;) |
| 12:18 |
Dyrcona |
Don't mind me. I'm just blowing off steam, as usual. :) |
| 12:21 |
rfrasur |
Dyrcona++ |
| 12:22 |
dbs |
For anyone interested in web accessibility, I'm running through https://webaccessibility.withgoogle.com over the next few days |
| 12:23 |
kmlussier |
dbs++ |
| 12:23 |
* kmlussier |
may took a look at it too. |
| 12:37 |
remingtron |
dbs++ #I wish Google had a list of all their courses |
| 12:45 |
jeff |
senator: I was looking around to see if anything currently made use of the "pos" column in the various container.*_bucket_item tables, and found commit 61195ba3 on URLVerify.pm |
| 12:45 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] Link checker: user interface and supporting fixes (part 1) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=61195ba> |
| 12:45 |
dbs |
huh. running latest master + mobile tpac branch gave me a wide-char failure trying to load concerto authorities. hand't run into that before. |
| 12:46 |
jeff |
senator: other than _bucket_flesh in OpenILS::Application::Actor::Container, that seems to be the only place that reads/writes the "pos" column for a container/bucket item. Does that match your understanding of pos, and did you have any particular reason for using it? |
| 12:47 |
* dbs |
doesn't see any recent master commits that would introduce new problems, so must be a Fedora update to perl / Encode :/ |
| 12:48 |
dbs |
error was at auth_concerto.sql:76 |
| 12:48 |
senator |
jeff: hmm, i think setting pos in URLVerify.pm was just cargo cult |
| 12:49 |
jeff |
senator: your self-awareness and honesty are appreciated. thanks! :-) |
| 12:49 |
senator |
it looks to me, too, like nothing actually cares about the position of cbrebi rows. i guess they don't really have an intrinsic order |
| 12:49 |
senator |
no prob. i would want to test that the link checker still works after any patch that loses that field, just to be on the safe side, of course |
| 12:50 |
jeff |
i'm not proposing losing the field, just doing some recon as i consider adding a "sort by date added to bucket" feature somewhere |
| 12:51 |
senator |
ah |
| 12:56 |
dbs |
Fails on the second auth_concerto record, which is the first to contain unicode XML char entities |
| 12:59 |
dbs |
Yikes. Running perl-Encode 2.54 currently, lots of changes in the last few months: http://cpansearch.perl.org/src/DANKOGAI/Encode-2.55/Changes |
| 13:00 |
|
dMiller_ joined #evergreen |
| 13:03 |
|
dboyle joined #evergreen |
| 13:08 |
dbs |
Looks like perl-Encode was upgraded from 2.51 to 2.54 a couple of days ago. And that's where the breakage occurs. |
| 13:09 |
dbs |
Downgrading back to 2.51 resolved the issue. So clearly we were relying on some buggy perl-Encode behaviour. Remains to be seen whether that change in perl-Encode will be reverted or whether we need to adapt |
| 13:09 |
dbs |
Fedora == canary; Evergreen == coal mine |
| 13:10 |
senator |
dbs++ # bleeding all over the edge |
| 13:10 |
jeff |
dbs++ blood donor |
| 13:13 |
* Dyrcona |
notes that there is a blood drive going on elsewhere in the building where he works today. |
| 13:14 |
pinesol_green |
[evergreen|Bill Erickson] Action/Trigger load environment via stream - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=de255ea> |
| 13:14 |
jeff |
dbs is blood type UTF Negative 8? |
| 13:15 |
rfrasur |
jeff++ |
| 13:15 |
Dyrcona |
jeff++ |
| 13:15 |
rfrasur |
oh. my. gosh. I need to wait this long to eat everyday. It tastes WAY better. |
| 13:16 |
gmcharlt |
dbs: meep -- looking to see if I can get MARC::Record and MARC::Charset to break on that version of Encode |
| 13:16 |
dbs |
jeff++ |
| 13:17 |
dbs |
gmcharlt++ |
| 13:17 |
|
stevenyvr2 joined #evergreen |
| 13:24 |
jeff |
so, decode_utf8($octets) used to short circuit and return $octets if is_utf8($octets) -- first they fixed the documentation to be explicit about this, then they changed their minds and removed the short circuiting, and then a release or so later they changed the documentation back so that things were in sync. :-) |
| 13:25 |
jeff |
sounds like we were relying on the short circuiting behavior somewhere. |
| 13:25 |
jeff |
but that's just a guess based on the changes. dbs++ and gmcharlt++ for looking into it. |
| 13:46 |
|
kmlussier joined #evergreen |
| 13:57 |
|
RoganH joined #evergreen |
| 14:14 |
|
mrpeters joined #evergreen |
| 14:21 |
jeff |
well drat. looks like since bookbag display uses queryparser, i'd have to teach queryparser how to sort by a new sort. |
| 14:21 |
jeff |
not just pass a sort to a json query |
| 14:23 |
jeff |
i probably want to do this in supercat instead, adjusting a bookbag feed. |
| 14:25 |
jeff |
...which appear to be already sorted by added-to-bucket-date |
| 14:25 |
jeff |
so i'm done! :-) |
| 14:25 |
jeff |
(maybe not, but we'll go with that pleasant illusion for now) |
| 14:37 |
|
kbeswick_ joined #evergreen |
| 14:42 |
|
Callender joined #evergreen |
| 14:55 |
bshum |
Bleh, B&T-- for wacky looking 852 holding subfields |
| 14:57 |
bshum |
Also MARC-- |
| 14:59 |
pinesol_green |
[evergreen|Pasi Kallinen] New advanced search filter size/layout options - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1b1a28a> |
| 15:02 |
jeffdavis |
@karma MARC |
| 15:02 |
pinesol_green |
jeffdavis: Karma for "MARC" has been increased 0 times and decreased 7 times for a total karma of -7. |
| 15:02 |
jeffdavis |
I expected worse. |
| 15:02 |
Dyrcona |
@karma marc |
| 15:02 |
pinesol_green |
Dyrcona: Karma for "marc" has been increased 0 times and decreased 7 times for a total karma of -7. |
| 15:03 |
Dyrcona |
Guess it is case insensitive. |
| 15:03 |
rfrasur |
case_insensitivity++ |
| 15:03 |
Dyrcona |
caseInsensitivity-- |
| 15:03 |
Dyrcona |
heh. |
| 15:03 |
rfrasur |
heh indeed |
| 15:04 |
dbs |
bshum: pushed a couple of commits for better refine/back_to_hits styling and behaviour, along with some saner CSS for wrapping buttons in the results header |
| 15:04 |
|
sseng_ joined #evergreen |
| 15:04 |
dbs |
bshum: I realize now that I might have run afoul of an nth-child rule for the results header buttons though, will go back and look at that |
| 15:05 |
dbs |
nth-child-- # although occasionally a necessary evil |
| 15:06 |
bshum |
dbs: Cool! I'll poke at getting those installed to theory |
| 15:06 |
bshum |
In a minute or so. |
| 15:06 |
rfrasur |
quarterly_reporting-- |
| 15:06 |
bshum |
After I finish beating these MARC imports into submission |
| 15:06 |
bshum |
Or die trying. |
| 15:06 |
Dyrcona |
apropos of nth-child: dt:not(:first-child) { padding-top: 1em; } |
| 15:08 |
dbs |
bshum: okay, so you didn't want "Advanced search" to appear in the results header buttons? I could give that button a specific ID and swap that for nth-child(2)... |
| 15:09 |
pinesol_green |
[evergreen|Pasi Kallinen] Add missing dojo nls files for FlattenerGrid and PCrudFilterPane to the i18n toolchain. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6eb667c> |
| 15:09 |
senator |
huh. |
| 15:10 |
senator |
paxed++ |
| 15:10 |
senator |
i didn't even know that was a necessary step |
| 15:10 |
dbs |
Or maybe that was just something that ISL put in place to hide Advanced Search utterly from view :) |
| 15:10 |
dbs |
in which case we can remove that particular rule and bring the size of style.css down a few lines! |
| 15:12 |
bshum |
dbs: I think we have advanced search showing now... so maybe those are just leftover pieces from the ISL css that can go away |
| 15:15 |
dbs |
yep, working on it |
| 15:19 |
dbs |
pushed |
| 15:27 |
jeff |
berick: there doesn't seem to be a working branch or a launchpad bug for purging objson from OpenSRF -- re: http://libmail.georgialibraries.org/pipermail/open-ils-dev/2008-July/003391.html -- any idea if your original statements about ripping legacy json out still stand? :-) |
| 15:27 |
jeff |
(don't even ask why I'm thinking about this now, I think I fell down a rabbit hole) |
| 15:28 |
* jeff |
calmly steps back from said rabbit hole and falls into another |
| 15:31 |
berick |
hmm |
| 15:33 |
berick |
jeff: i believe that patch has already been applied |
| 15:33 |
berick |
not seeing any reference in EG for objson |
| 15:33 |
jeff |
berick: right -- I was talking about the OpenSRF side of things. |
| 15:35 |
jeff |
berick: though in Evergreen there is still a defined legacy /gateway in Evergreen -- that expected and was not in-scope for the original patch, as I understand it. |
| 15:35 |
jeff |
And rumor has it there is third party code using the legacy /gateway, but that's unconfirmed. |
| 15:35 |
jeff |
trying to remember who brought that up... |
| 15:36 |
jeff |
berick: none of this is urgent. feel free to ignore until any later time of your choosing, including "NaN"::interval or something equivalent. :-) |
| 15:37 |
berick |
heh |
| 15:37 |
berick |
well, i'm curious |
| 15:40 |
berick |
jeff: ok, yes, I still think it should still be removed from opensrf |
| 15:40 |
Dyrcona |
My vote: Add websockets support and rip out the rest. |
| 15:40 |
berick |
i don't believe there is a LP entry for it |
| 15:41 |
berick |
heh |
| 15:41 |
berick |
Dyrcona: that's the spirit ;) |
| 15:41 |
jeff |
okay, at this point i'm unable to confirm the rumor of any third party code using the legacy /gateway url. the conversation from list+irc of Sep 6 was what I was thinking of, and I just reviewed logs and found no claim that there was still active use. :-) |
| 15:41 |
* jeff |
checks apache logs for signs of use |
| 16:18 |
|
sseng joined #evergreen |
| 16:19 |
jboyer-isl |
jeff, or _bott_, do either of you guys know where NCIP is re: evergreen? We have some interest here, and I know MI was interested in getting it developed at one point. |
| 16:19 |
jeff |
jboyer-isl: NCIP is a many-headed hydra. Do you know anything about where your interest is focused? |
| 16:20 |
jeff |
jboyer-isl: We are using NCIP in a Direct Consortial Borrowing 3 application profile, which is "broker managed inter-library loan". We're using it with Evergreen as the responder and III INN-REACH as the initiator. Evergreen acts as the User or the Item agency. |
| 16:20 |
jboyer-isl |
Resource sharing, specifically with regard to alternatives for FulfILLment I think. |
| 16:22 |
jeff |
What we have is code that was developed on contract for MCLS, used in production at TADL and one other Michigan library. It's a CGI script that you install on your Evergreen application server(s) that responds to NCIP messages from the state resource sharing system. |
| 16:22 |
jboyer-isl |
It sounds like what you've got is enough to get us headed in the right direction. |
| 16:22 |
jboyer-isl |
So it's not part of master or 2.something? |
| 16:22 |
jeff |
Our work in progress (using in production with success, but still working on some issues) can be found here: https://github.com/tadl/iNCIPit |
| 16:24 |
jboyer-isl |
That's great. I'll mention it to the interested parties and see how/if they want to proceed. (I imagine the way they'll proceed is by asking me "so can it do X" and I'll keep saying "let me look.") |
| 16:24 |
jeff |
jboyer-isl: Not our decision, but the NCIP responder wasn't developed as part of Evergreen and there's been no effort to offer it for inclusion. The code's not yet up to snuff for becoming part of Evergreen, even if it had been offered for inclusion. |
| 16:24 |
jboyer-isl |
Thanks jeff. |
| 16:24 |
jboyer-isl |
jeff++ |
| 16:24 |
|
Bmagic joined #evergreen |
| 16:24 |
jeff |
Also, there's a number of things about this kind of thing with NCIP that bring to mind "When you've seen one UNIX... you've seen one UNIX." The responder as it exists today would probably only be appropriate for talking to a III INN-REACH system. |
| 16:25 |
jboyer-isl |
I see. |
| 16:25 |
jboyer-isl |
Kind of like "Works with SIP2!" for varying values of SIP2. And works. |
| 16:25 |
jeff |
jboyer-isl: large portions of iNCIPit (somebody else named it) were copied from Dyrcona's issa.pl (I didn't name that either, but Dyrcona goes into his reasons in the README, iirc). |
| 16:26 |
Dyrcona |
jboyer-isl: https://docs.google.com/document/d/1NuV47145SnEV1f-9BrY2d9jpX8Ij_VxK2a51lotgSsU/edit?usp=sharing |
| 16:26 |
jboyer-isl |
I can pass along some caveats. |
| 16:26 |
jeff |
jboyer-isl: Also, and perhaps lastly, there is another effort (related, and in parallel) to work on NCIP support for Evergreen. I think that's rangi and Dyrcona at the moment, and code is here: http://git.evergreen-ils.org/?p=NCIPServer.git;a=summary |
| 16:27 |
Bmagic |
anyone out there have a knowledge of fine_generator.pl ? |
| 16:27 |
Dyrcona |
http://git.evergreen-ils.org/?p=working/NCIPServer.git;a=summary |
| 16:27 |
jboyer-isl |
Oh, I thought I heard of another NCIP interested party, thanks dyrcona. |
| 16:27 |
jeff |
Dyrcona++ |
| 16:27 |
Dyrcona |
I have some commits from rangi to merge in at the moment. I've been busy with other things. |
| 16:27 |
jboyer-isl |
I get the impression this is a longer term query. The fact that there's any work being done at all will probably make them happy. |
| 16:28 |
Dyrcona |
I have a 'deadline' of December. |
| 16:28 |
jeff |
Dyrcona's linked document above has a not-unfair critique of issues with iNCIPit, though at least one of the criticisms is mostly resolved in TADL's fork (which dbwells has voiced interest in merging back upstream). |
| 16:29 |
Dyrcona |
There's also a mailing list and I was going to announce over a month ago. |
| 16:29 |
Dyrcona |
jeff: I can merge it upstream. I have commit rights to the master github repo. :) |
| 16:29 |
jeff |
Dyrcona: forgot that was both you and dbwells :-) |
| 16:30 |
jeff |
Dyrcona: i'll submit a semi-omnibus pull-request when my work this week is done. :-) |
| 16:30 |
Dyrcona |
All right. |
| 16:30 |
jeff |
(adding multi-branch pickup support, and killing a few more bugs and lurking TODOs by Oct 1) |
| 16:31 |
|
kmlussier joined #evergreen |
| 16:31 |
Bmagic |
I have a question about the fine_generator.pl script - more specifically open-ils.storage.action.circulation.overdue.generate_fines |
| 16:31 |
kmlussier |
@marc 655 |
| 16:31 |
pinesol_green |
kmlussier: Terms indicating the genre, form, and/or physical characteristics of the materials being described. A genre term designates the style or technique of the intellectual content of textual materials or, for graphic materials, aspects such as vantage point, intended purpose, or method of representation. A form term designates historically and functionally specific kinds of materials (2 more messages) |
| 16:32 |
jeff |
Bmagic: What is your question? |
| 16:32 |
Dyrcona |
Bmagic: So, ask your question. |
| 16:32 |
Bmagic |
so, I delete some rows from money.billing hoping that the fine_gererator will make them again |
| 16:32 |
Bmagic |
it doesn't which indicates that it keeps track of what it has inserted |
| 16:32 |
jeff |
Bmagic: what was your original reason for deleting them? |
| 16:32 |
dbwells |
jeff: just waiting on a pull-request. Maybe we can all agree on an "unstable" standard for iNCIPit master, since that's a still a step up from "non-functional" ;) |
| 16:33 |
Bmagic |
we imported a lot of circulation under the wrong rules |
| 16:33 |
jeff |
dbwells: *grin* |
| 16:33 |
Dyrcona |
Bmagic: Check the transaction. It probably has a stop fines reason set. |
| 16:33 |
Dyrcona |
dbwells: heh. |
| 16:33 |
Bmagic |
migrated a new library into our system from an old system with the circ rules set incorrectly |
| 16:33 |
Bmagic |
now we have a billing issue |
| 16:34 |
Dyrcona |
Bmagic: That's to be expected. |
| 16:35 |
Bmagic |
so, fine_generator knows not to create those rows.... my question is which table is it using to decide weather or not to generate inserts into money.billing |
| 16:35 |
jeff |
Bmagic: i think Dyrcona's advice is going to be most useful for you -- you may find that you need to clear the stop_fines and stop_fines_reason for the circulations in question. |
| 16:35 |
Dyrcona |
Bmagic: action.circulation |
| 16:35 |
jeff |
Bmagic: but please consider doing this on a test copy of the database -- it would make me feel much better. :-) |
| 16:36 |
Bmagic |
do you mean the action.circulation - stop_fines (text) stop_fines_time ? |
| 16:36 |
Dyrcona |
yep. |
| 16:37 |
jeff |
Bmagic: yes. sorry, i stated their names incorrectly. :-) |
| 16:37 |
Bmagic |
didnt see stop_fines_reason |
| 16:37 |
Bmagic |
thanks for the tip, I will see if I can get it to recreate those rows again |
| 16:38 |
Bmagic |
And perhaps I should ask a bigger question.... Am I going about this the right way? |
| 16:38 |
jeff |
seems quite reasonable from my somewhat limited migration experience, and somewhat less-limited understanding of circs and bills. |
| 16:38 |
Dyrcona |
Bmagic: Well, there isn't a wrong way. |
| 16:38 |
Bmagic |
:) |
| 16:38 |
Dyrcona |
Just no good way. |
| 16:39 |
Dyrcona |
Bmagic: You have also updated the values for fines, etc in the action.circulation entries? |
| 16:39 |
|
tspindler left #evergreen |
| 16:39 |
Dyrcona |
If not, the fine generator is going to use the bad data again. |
| 16:39 |
Bmagic |
we used the staff client to correct the rules |
| 16:40 |
jeff |
i can caution that if you want NO fines generated on a circ, it is best to set values in those stop fines columns, as (at least in past versions of the code) the fine generator would happily generate millions of 0.00 fines on overdue items. :-) |
| 16:40 |
Bmagic |
I was assuming it would do all the right things |
| 16:40 |
jeff |
Bmagic: ah. no. |
| 16:40 |
Dyrcona |
Bmagic: You still need to update the action.circulation entries in the database. |
| 16:40 |
Bmagic |
this is good info |
| 16:41 |
Bmagic |
this table was puzzling me also - money.materialized_billable_xact_summary |
| 16:41 |
Bmagic |
which gets messed with by triggers from money.billing |
| 16:41 |
Dyrcona |
Bmagic: You can ignore it for your problem. |
| 16:41 |
Bmagic |
great! |
| 16:42 |
jeff |
Bmagic: you will want to adjust the value of fields such as fine_interval, recurring_fine, recurring_fine_rule, max_fine, and max_fine_rule. also possibly duration and/or duration_rule... and possibly grace_period. all those are on action.circulation. |
| 16:42 |
jeff |
most/all of those are set at checkout time. changing the policy/matchpoints in the staff client will not affect existing checkouts. |
| 16:42 |
Bmagic |
I see, would it be cleaner to wipe the rows and import from csv again? |
| 16:43 |
Dyrcona |
Bmagic: maybe. how many rows are you talking about? |
| 16:43 |
jeff |
Bmagic: depends on how you originally imported things. possibly. experimentation on a test copy may be required to answer that question -- lots of variables involved that are only specific to your situation. |
| 16:43 |
Bmagic |
less than 1k |
| 16:44 |
Bmagic |
stop_fines needs to be blank for fine_generator to go again? |
| 16:44 |
Bmagic |
My test set shows "MAXFINES" |
| 16:44 |
jeff |
i'm torn between the trouble of disabling triggers and deleting the rows from action.circulation vs just fixing things in place. i'd almost lean toward fixing in place for that smaller number. |
| 16:44 |
Dyrcona |
both stop_fines and stop_fines_time should be null. |
| 16:45 |
Bmagic |
GOTCHA |
| 16:45 |
* Dyrcona |
leans toward agreeing with jeff. :) |
| 16:45 |
jeff |
ideally you'd have a test copy where this issue was discovered, and could just re-do everything from a pristine copy, but ideals are elusive. |
| 16:45 |
Bmagic |
yeah - the deal is, there have been 3 weeks of live updates to the db since the migration |
| 16:45 |
jeff |
we had lots of "not apparent until in production" post-migration cleanup. :-) |
| 16:46 |
jeff |
(and there are several present who may declare that a huge understatement) |
| 16:46 |
* Dyrcona |
commiserates. |
| 16:47 |
Dyrcona |
I did our migration from our previous ILS, and I'm going to be adding a new member this weekend. |
| 16:47 |
* Dyrcona |
knows all about the post-migration blues. |
| 16:47 |
Bmagic |
null stop_fines and stop_fines_time, update rules applied to action.circulation. delete related billing rows in money.billing. run fine_generator and done!? |
| 16:48 |
Dyrcona |
Bmagic: Not just the rules, the values need to be updated too. |
| 16:48 |
Dyrcona |
But overall, that sounds about right. |
| 16:48 |
Bmagic |
you guys/gals have been most helpful! |
| 16:49 |
Dyrcona |
Bmagic: Good luck! |
| 16:49 |
Bmagic |
thank you! |
| 16:51 |
jeff |
good luck / you're welcome! |
| 16:51 |
Dyrcona |
rangi++ #for something totally unrelated to what is happening at the moment. |
| 16:54 |
* Dyrcona |
has been working too much in his own repos lately..... |
| 17:18 |
|
mmorgan left #evergreen |
| 17:33 |
dbwells |
grabbing 0834 |
| 17:51 |
pinesol_green |
[evergreen|Bill Erickson] LP 1212456 customize items out display - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a0ee19f> |
| 17:51 |
pinesol_green |
[evergreen|Dan Wells] Stamping 'Items Out' config settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5ef27d7> |
| 17:51 |
pinesol_green |
[evergreen|Bill Erickson] LP 1212456 Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1885372> |
| 18:27 |
|
depesz joined #evergreen |
| 18:49 |
csharp |
Bmagic: just FYI, there's also the money.materialized_billable_xact_summary table which will likely need refreshing for whichever bills you're deleting/readding |
| 18:49 |
* csharp |
unfortunately does not recall the details of how that all works at the moment, though :-/ |
| 19:29 |
|
kbeswick joined #evergreen |
| 20:32 |
|
jdouma joined #evergreen |
| 22:10 |
|
hopkinsju joined #evergreen |
| 23:53 |
|
hopkinsju joined #evergreen |
