2010-12-02T00:28:16 *** dbs has quit IRC 2010-12-02T04:16:17 *** artunit has quit IRC 2010-12-02T04:16:33 *** artunit has joined #evergreen 2010-12-02T04:19:55 *** artunit_ has joined #evergreen 2010-12-02T04:21:08 *** artunit has quit IRC 2010-12-02T04:21:18 *** artunit_ is now known as artunit 2010-12-02T06:34:06 *** rsinger has quit IRC 2010-12-02T06:42:13 *** rsinger has joined #evergreen 2010-12-02T07:19:13 *** bshum has joined #evergreen 2010-12-02T07:56:22 *** sfortin has joined #evergreen 2010-12-02T08:02:09 *** collum has joined #evergreen 2010-12-02T08:12:48 *** Meliss has joined #evergreen 2010-12-02T08:19:07 *** Meliss has quit IRC 2010-12-02T08:36:13 *** kmlussier has joined #evergreen 2010-12-02T08:45:51 *** alxp has joined #evergreen 2010-12-02T08:57:45 *** kmlussier has quit IRC 2010-12-02T09:01:01 *** bshum has quit IRC 2010-12-02T09:01:34 *** kmlussier has joined #evergreen 2010-12-02T09:03:44 guys - upon an OPAC renewal - action.circulation.circ_lib = actor.usr.home_ou or does it = asset.copy.circ_lib ? 2010-12-02T09:06:40 and I assume the "Circulation Library" column in the staff client is the asset.copy.circ_lib 2010-12-02T09:07:15 while the "Checkout Library" is the action.circulation.circ_lib 2010-12-02T09:14:33 phasefx to the rescue!? 2010-12-02T09:15:37 mrpeters-isl: Check out a book from library A to a patron from library B at library C, then opac renew it and see what libraries show up where? 2010-12-02T09:16:13 tsbere: we're kind of at the point we need a real definitive answer from the developers 2010-12-02T09:16:45 "Checkout Library" from the picker = which table/column, "Circulation Library" is so and so, etc. 2010-12-02T09:25:03 *** dbs has joined #evergreen 2010-12-02T09:27:09 mrpeters-isl: From a very brief look at the code, it looks like it would grab the original circ's info for that? Maybe. 2010-12-02T09:30:55 tsbere: I'm not so sure. I have a patron from library "A" who checked out an item owned by library "B" but did the initial checkout in the building of library "C" 2010-12-02T09:31:04 the "Circulation Library" is library "B" 2010-12-02T09:31:18 As I said, very brief look at the code. 2010-12-02T09:31:18 "Owning Library" is "B" --- which makes sense 2010-12-02T09:31:35 i know...just explaining further once someone can jump in on this and confirm finally 2010-12-02T09:32:00 meanwhile...the "Checkout Library" is Library "C" 2010-12-02T09:32:12 I would expect Checkout Library = Circulation Library but that's not the case 2010-12-02T09:32:25 so i need a definition for each of these 3 values so we can adjust policy accordingly 2010-12-02T09:33:29 *** AaronZ has joined #evergreen 2010-12-02T09:34:54 I assume that "checkout library" on a renewal should stay as where the original checkout was, regardless of what kind of renewal it was. That assumption may be outright wrong. 2010-12-02T09:35:14 right, and i think that is true 2010-12-02T09:35:53 my new question is how does the "Owning Library" of them item (which i assume to be asset.copy.circ_lib) become the "Circulation Library" when the patron never entered that branch to do a checkout, renewal, etc. 2010-12-02T09:36:28 I assume there has to be some case where Circulation Library != Owning Library -- otherwise why have two redundant options in the picker? 2010-12-02T09:36:49 *** jenny has joined #evergreen 2010-12-02T09:37:26 If I recall correctly, actor.usr.home_ou is the "Checkout library" in the default circ scripts when a person does an OPAC renewal; caught us by surprise initially 2010-12-02T09:37:47 dbs - yes! see that was something I remember being involved in discussing 2010-12-02T09:38:03 owning library is defined at the volume/call number level. circ lib is defined on each copy, and also defined on each circulation. 2010-12-02T09:38:08 but i'm being told by the "front lines" that isnt the case 2010-12-02T09:38:17 circ lib can differ on a copy and a circulation related to that copy. 2010-12-02T09:38:23 jeff: wow, ok that is very interesting 2010-12-02T09:38:58 so if you're looking at a list in the staff client that focuses on copies, you're looking at the circ lib from asset.copy. if you're looking at a list that focuses on circulations, you're looking at the circ lib on action.circulation. 2010-12-02T09:39:14 ahh jeff that helps 2010-12-02T09:39:37 circ lib on a circulation is whatever library the item was checked out from -- the workstation's OU. on a renewal, it can depend, as dbs noted. i don't have any insight on renewal circ lib quirks. 2010-12-02T09:40:09 right - its these OPAC renewals that are causing us the most trouble 2010-12-02T09:40:16 but i can see potential for them to differ from the original circ lib of the first circulation, and i can see the renewal behavior being different for desk vs opac renewals. 2010-12-02T09:40:18 i remembered it as dbs does but i'm getting some resistance on that 2010-12-02T09:40:36 test! empirical evidence! 2010-12-02T09:40:58 heh we have lots of skeptical people here 2010-12-02T09:41:01 jeff: exactly 2010-12-02T09:41:14 especially since in this case there are configuration factors that prevent a "definitive" answer from someone outside your system. 2010-12-02T09:42:09 this information will help. thank you jeff, dbs and tsbere 2010-12-02T09:43:51 actuallly...i'm still not clear on what "Circulation Library" ties to 2010-12-02T09:44:00 Owning Library = asset.call_number.owning_lib 2010-12-02T09:44:11 Checkout Lib = action.circulation.circ_lib 2010-12-02T09:44:21 Circulating Library = asset.copy.circ_lib? 2010-12-02T09:44:49 *** yboston has joined #evergreen 2010-12-02T09:45:13 well, meetings and other junk prevented me from cutting b4 yesterday ... so, I'm starting that now 2010-12-02T09:45:23 * dbs suggests creating an item with asset.call_number.owning_lib = A, action.circulation.circ_lib = B, actor.usr.home_ou = C and testing different scenarios 2010-12-02T09:45:26 eeevil++ 2010-12-02T09:45:47 mrpeters-isl: where are you seeing the label "Circulation Library"? 2010-12-02T09:46:01 jeff: items out page 2010-12-02T09:46:03 in the picker you can add it 2010-12-02T09:46:04 aha: 96: 2010-12-02T09:46:37 just from that id, i'd say it's the copy's circ_lib 2010-12-02T09:46:45 but, test and verify. :) 2010-12-02T09:47:07 that is what it appears to be i'm just trying to wrap around a case where Owning Library and Circulating Library wouldn't be the same thing 2010-12-02T09:47:33 mrpeters-isl: there are cases where the owning library is a branch but the circulation library is a bookmobile 2010-12-02T09:47:47 jeff: that makes sense. ok 2010-12-02T09:47:49 line 611 of Open-ILS/xul/staff_client/server/circ/util.js would agree with jeff 2010-12-02T09:48:12 or rotating collections / floating items 2010-12-02T09:48:15 mrpeters-isl: we don't have any examples of that, but that kind of scenario is what i see described most often 2010-12-02T09:48:21 and what dbs said 2010-12-02T09:48:22 patches to disabmbiguate those would be great ... note: we avoided "home library" for asset.copy.circ_lib because of concerns over copying (and being yelled at by) other vendors, but that's the best description of that field 2010-12-02T09:48:34 fair enough 2010-12-02T09:48:48 "residing library", "shelving library"... 2010-12-02T09:49:35 current residence library 2010-12-02T09:49:47 transition library 2010-12-02T09:49:50 halfway house library 2010-12-02T09:50:23 dbs: wait though - if its transited away, wouldnt the transit desination be the "residing library" 2010-12-02T09:50:38 and the owning library is the "home base" where the item actually belongs 2010-12-02T09:50:48 mrpeters-isl: no. 2010-12-02T09:51:11 mrpeters-isl: that's the copy's "circulation library". the "owning library" is the library that owns the item, but not always where the item sits on a shelf by default. 2010-12-02T09:51:40 ok, so shouldnt the Owning Library then be the same as the "Checkout Library" 2010-12-02T09:51:48 mrpeters-isl: sorry, i realize now you were just giving feedback on the brainstorming. :) 2010-12-02T09:51:50 because thats the library that is currently in custody of the item 2010-12-02T09:52:02 mrpeters-isl: custody != ownership 2010-12-02T09:52:13 checkout library is where the checkout happened; so if you bring your books to a different branch for renewal, that's where they were checked out 2010-12-02T09:52:22 right i'm totally clear on that 2010-12-02T09:52:29 its owning/circulating that get fuzzy 2010-12-02T09:52:56 ergo - when renewing online, what library renewed them? Unless you create a branch for "TEH INTERWUBS"... :) 2010-12-02T09:53:10 dbs: i always thought the home ou of the patron was fair 2010-12-02T09:53:24 since they are using an extension of their local branch to renew it 2010-12-02T09:53:36 some libs will think differently. 2010-12-02T09:53:59 jeff: this is a universal constant :) 2010-12-02T09:53:59 jeff: very true! you see why i'm having a hard time grasping the definitions 2010-12-02T09:54:07 becuase someone is going to tell me they "see it differently" 2010-12-02T09:54:33 to me, an opac renewal getting the circ_lib of the parent circ makes sense, and a desk renewal getting a circ_lib of the library whose desk it was renewed at... but then there's potential for a "renewal" to have different duration/fines/etc from the original circ. :) 2010-12-02T09:54:46 (not an issue if you have uniform policy there) 2010-12-02T09:54:54 yeah, that portion is always going to differ from consortium to consortium 2010-12-02T09:55:11 thankfully we have universal circ policies 2010-12-02T09:55:40 probably sanest for the libs that circ each other's items to have uniform policy, but not always practical/attainable. 2010-12-02T09:56:08 so what we run into is - overdue fines for an item go to "Checkout Library" but lost item bills must be paid to the "Owning Library" 2010-12-02T09:56:28 heh 2010-12-02T09:56:32 some people are looking at "Circulation Library" however, as the destination for the overdue money which is incorrect since the circulation didn't take place at that particular branch 2010-12-02T09:56:52 so people are getting "Checkout" and "Circulation" intertwined since the terms are so similar 2010-12-02T09:56:56 *** agJohn has quit IRC 2010-12-02T09:57:14 yeah, we have that also, and it's why i'm working getting mmpbbt live. just found an old policy on "refunding to patrons" where staff were trained to generate negative billings -- i wonder how badly that will confuse things... 2010-12-02T09:57:30 yeah we try to avoid those negative bills at all costs 2010-12-02T09:57:34 ive seen the haavoc it causes! 2010-12-02T09:57:53 death, pestilence... 2010-12-02T10:00:56 is the mmpbbt view what we've been pestering you for? 2010-12-02T10:01:34 yes :) 2010-12-02T10:01:51 heh ok. my mistake! i thought it was something already developed and in use for quite a while there :) 2010-12-02T10:02:01 should have been. 2010-12-02T10:20:10 if anyone wants an overview of continuous integration in the hopes of resurrecting that for Evergreen, http://www.agilejournal.com/events/webcasts/3418 is an upcoming webcast (albeit sponsored by a company with a CI product to sell, no doubt - still, the principles should be the same) 2010-12-02T10:23:22 *** Melissa1 has joined #evergreen 2010-12-02T10:24:23 or heck, http://bugs.koha-community.org:8080/ ;) 2010-12-02T10:24:44 *** jenny has quit IRC 2010-12-02T10:30:18 gmcharlt: that's an instance of a CI server, not an explanation of principles and best practices. Unless those are encoded somewhere in the HTML source... 2010-12-02T10:30:37 dbs: just suggesting some practice to go along with the theory 2010-12-02T10:30:38 and there's still testing.esilibrary.com, waiting for requests for user accounts of motivated CI-inclined folken 2010-12-02T10:31:46 eeevil: I know! I'm trying to provide a method for CI-inclined folken who might want some more exposure to the theory before feeling comfortable tackling testing.esilibrary.com 2010-12-02T10:32:12 *** Dyrcona has joined #evergreen 2010-12-02T10:33:06 gmcharlt: as eeevil points out, there's been a server available for people to practice their art on for a long time. So opportunity to put theory into practice isn't a problem. 2010-12-02T10:33:27 ergo, a lack of theory to put into practice might be a problem. ergo, a free webcast might help 2010-12-02T10:33:42 * dbs shuts up 2010-12-02T10:33:52 *** dbs has quit IRC 2010-12-02T10:34:12 b4 up at normal spot ... COME AN' GIT IT! 2010-12-02T10:35:11 if someone would be kind enough to put together a staff client (not that much has changed, of course, in the SC) I'll update the downloads page 2010-12-02T10:36:38 curse you eeevil! you're too quick for me! hehe 2010-12-02T10:36:51 thanks for the new beta 2010-12-02T10:47:10 curious if anyone has any thoughts on this: http://dev198.esilibrary.com/~berick/theswamp/js_common.xml.patch.txt. idea being that a small perl script would scoop up the 10 files between START/END COMPRESSION and create a combined.js file, which can then be run through shrinksafe (yuicompressor, whatever) 2010-12-02T10:48:00 it works fine, just not sure if it's the best approach and or easiest to integrate into the build process 2010-12-02T10:50:13 berick: if you have an incantation for the build process to use (or a script that'll just do it), I'm fine with that 2010-12-02T10:51:01 berick: probably obvious ... I'd prefer shrinksafe, since we already use that for the dojo layer build 2010-12-02T10:51:28 sed + bash + cat + (compressor) + sed should be able to do it, actually. I may be able to whip something up easily too, if desired. 2010-12-02T10:51:52 eeevil: *nod* 2010-12-02T10:51:54 actually, bash + sed, not sed + bash at the start 2010-12-02T10:52:12 tsbere: i have a chunk of perl, but sed/bash would be better for build integration if you're up for it 2010-12-02T10:53:38 hrm... this should happen at `make` time, not release building time, which is what I was referring to ... if it's at `make` then I have no concern whatsoever -- doesn't affect me! ;) 2010-12-02T10:54:33 'make' time works for me.. 2010-12-02T10:54:42 since it can still be turned on/off via apache config 2010-12-02T10:55:31 of course, then we don't have a compressor ... I suppose it would require more autotools stuff, like a location of a/the compressor, perhaps? 2010-12-02T10:56:22 fwiw, I don't think requiring perl during make is too onerous (given, ya know, the fact that EG is mostly perl ;) ) 2010-12-02T11:03:01 berick/eeevil: I can one-line cat the entire set of filenames into any command we want, actually. 2010-12-02T11:04:25 *** dchristens has joined #evergreen 2010-12-02T11:04:34 Example: cat `sed -n -e "//,// s/.*\?\/\([^']*\.js\)'.*/\1/p" js_common.xml` | compressor 2010-12-02T11:05:55 Obviously paths need to be taken into account 2010-12-02T11:08:08 *** dmc186 has joined #evergreen 2010-12-02T11:12:46 tsbere: cool, thanks 2010-12-02T11:13:16 I suggest dumping to combined.js and then compressing that, and then if the compression doesn't happen at least combined.js still exists and is up to date 2010-12-02T11:14:19 agreed 2010-12-02T11:16:19 dbs++ # dnsmasq investigation 2010-12-02T11:23:43 Hi folks. I'm still on 1.6.0.4 - is there something I need to do to enable Vandelay to actually import records? Currently it zips through the "loading" part, and gives me "Total: 0, Imported: 0" 2010-12-02T11:24:16 dchristens: properly formatted? 2010-12-02T11:24:34 tsbere: bash doesn't seem to like the sed http://paste.lisp.org/display/117251. (note, the first 2 lines are really 1 line). 2010-12-02T11:24:38 mrpeters-isl: the MARC? looks like it to me :-) 2010-12-02T11:24:38 i used to make the mistake of trying to load MARCXML records thinking thats what it wanted :) 2010-12-02T11:25:17 :-) 2010-12-02T11:25:37 *** shopkins has joined #evergreen 2010-12-02T11:26:19 berick: Throw a \ in front of each ! to placate bash. 2010-12-02T11:26:34 nothing ever shows up in vandelay_unix.log, either. 2010-12-02T11:26:34 berick: hrm... should we, perhaps, have autogen do this? the chance of change within any given skin (particularly, other than "default") is relatively high, I think, and 'make' may be way too early 2010-12-02T11:27:01 +1 # autogen sounds good 2010-12-02T11:27:15 dchristens: does anything make it into vandelay.queued_bib_record? 2010-12-02T11:27:39 probably not... 2010-12-02T11:27:46 autogen works for me 2010-12-02T11:28:10 tsbere: wee, now there's no oubput ;) 2010-12-02T11:28:41 dchristens: open-ils.vandelay processes are running too, i assume? 2010-12-02T11:28:41 berick: Dunno what oubput is, but if you want output make sure your patch was applied to js_common.xml in your path there ;) 2010-12-02T11:30:18 s/oubput/output/ 2010-12-02T11:30:28 mrpeters-isl: there are some records in vandelay.queued_bib_record, but none recent. (Yep, the open-ils.vandelay processes are running) 2010-12-02T11:30:41 interesting. so it was working at some point hehe 2010-12-02T11:30:52 have you tried another set of records? 2010-12-02T11:31:24 yep, just tried a second (completely unrelated) set of recs; same problem. 2010-12-02T11:31:30 fun 2010-12-02T11:31:33 :-) 2010-12-02T11:31:51 i wish i could help more! my experience with vandelay has really only been on the client side. maybe we can both learn something here 2010-12-02T11:31:52 doesn't seem to be a rights issue - admin can't do it either 2010-12-02T11:31:59 :-) 2010-12-02T11:32:50 any ERR messages in the logs right after you try an upload? maybe even in the apache access logs? 2010-12-02T11:32:54 tsbere: does that command create output for you? 2010-12-02T11:33:06 i dont know if the binary marc gets uploaded via apache or not? maybe a permissions error there? 2010-12-02T11:33:50 berick: Let me test yours (with my test js_common.xml file, anyway, and the extra two \ in there) 2010-12-02T11:34:09 Aha: 2010-12-02T11:34:13 [2010-12-02 10:20:06] open-ils.vandelay [WARN:4549:Vandelay.pm:269:1291305612332323] Encountered a bad record at Vandelay ingest: Exception: OpenSRF::EX::ERROR 2010-12-02T10:20:06 OpenILS::Application::Vandelay /openils/lib/perl5/OpenILS/Application/Vandelay.pm:269 System ERROR: Attempt to update DB while not in a transaction : open-ils.cstore.direct.vandelay.queued_bib_record.create 2010-12-02T11:34:13 [2010-12-02 10:20:06] open-ils.vandelay [ERR :4549:CStoreEditor.pm:669:1291305612332323] Attempt to update DB while not in a transaction : open-ils.cstore.direct.vandelay.queued_bib_record.create 2010-12-02T11:34:13 [2010-12-02 10:20:06] open-ils.vandelay [ERR :4549:EX.pm:66:1291305612332323] Exception: OpenSRF::EX::ERROR 2010-12-02T10:20:06 OpenILS::Utils::CStoreEditor /openils/lib/perl5/OpenILS/Utils/CStoreEditor.pm:670 System ERROR: Attempt to update DB while not in a transaction : open-ils.cstore.direct.vandelay.queued_bib_record.create 2010-12-02T11:34:13 [2010-12-02 10:20:06] open-ils.vandelay [WARN:4549:Vandelay.pm:269:1291305612332323] Encountered a bad record at Vandelay ingest: Exception: OpenSRF::EX::ERROR 2010-12-02T10:20:06 OpenILS::Application::Vandelay /openils/lib/perl5/OpenILS/Application/Vandelay.pm:269 System ERROR: Attempt to update DB while not in a transaction : open-ils.cstore.direct.vandelay.queued_bib_record.create 2010-12-02T11:34:36 nice! 2010-12-02T11:34:37 berick: I get 10 lines of output on my test js_common.xml file 2010-12-02T11:35:14 That "bad record" has me concerned... I'll try poking at it with a stick. 2010-12-02T11:35:29 i dont think thats referring to a bad MARC record though 2010-12-02T11:35:32 tsbere: dag, i see the problem. i had a slightly different version of the file w/ some extra spaces. berick-- 2010-12-02T11:35:37 Oh, ok :) 2010-12-02T11:35:40 the "update db not in transaction" is what worries me 2010-12-02T11:36:03 tsbere++ thanks 2010-12-02T11:36:07 dchristens: the record peobably isn't bad ... are there any (relevant) errors (insert or update) in the PG logs? 2010-12-02T11:36:14 probably, even 2010-12-02T11:37:03 could it still be hung up in an old transaction still? and not allowing a new record to be createD? 2010-12-02T11:37:42 berick: n/p. BTW, if you want to have the files have paths when cat sees the filenames add the path before the \1 (with \/ instead of / in the path, obviously). Although I would recommend having anything doing this cd to the js directory first. 2010-12-02T11:37:43 if thats the case, you'd probably be looking for a transaction that began, but never got to COMIMT; 2010-12-02T11:38:38 dchristens: of course, you may really want to consider upgrading to 1.6.0.10 ... significant bug fixes abound 2010-12-02T11:40:49 Hmm, nothing in the apache log. I'll check the pg logs... 2010-12-02T11:41:09 if it is a hung transaction, would stopping/restarting eg services clear that? 2010-12-02T11:41:30 i would think restarting postgresql would? but i don't know if a transaction could hang like that...i was curious myself 2010-12-02T11:41:36 eeevil: upgrade is definitely on the radar.... 2010-12-02T11:41:54 i may be feeding you bad information...sorry if i am 2010-12-02T11:42:54 mrpeters-isl: no worries :-) 2010-12-02T11:43:03 it's not a hung transaction, it's the fact that there isn't one (or was, but now it's gone (timeout, error, etc)) 2010-12-02T11:43:43 postgres log is filled with "WARNING: there is no transaction in progress" 2010-12-02T11:43:55 uh oh 2010-12-02T11:44:05 dchristens: grep'ing for 1291305612332323 in your osrfsys.10.log will show you the whole API stack for the call that ended in that 2010-12-02T11:44:21 dchristens: most of those are fine, useless rollbacks 2010-12-02T11:44:33 dchristens: I'm concerned about INSERT and UPDATE records 2010-12-02T11:44:39 s/records/errors 2010-12-02T11:45:35 eeevil: does the conversion from binary MARC to MARCXML happen before the queued bib record gets inserted to the db? 2010-12-02T11:46:00 if so, then you could probably grep the postgres logs for maybe the TCN value of the marc record...to see what procedures it actually attempted, righT? 2010-12-02T11:49:19 Hmm, my paste.lisp.org never showed up... let's try that again.... 2010-12-02T11:50:17 heh do you have it on ignore like i did from the flood several months ago? 2010-12-02T11:50:52 http://paste.lisp.org/display/117257 2010-12-02T11:51:29 mrpeters-isl: didn't know there was such a setting :-) 2010-12-02T11:52:14 dchristens: maybe grep your postgres logs for "PLSb10006796" 2010-12-02T11:52:26 see if that ever gets an insert attempt 2010-12-02T11:52:50 im betting not 2010-12-02T11:53:09 c-store has an error, so i'm betting vandelay can't talk to the database 2010-12-02T11:53:35 open-ils.cstore 2010-12-02 10:20:06 [WARN:31686:osrf_application.c:386:1291305612332323] Returning method exception with message: An unknown server error occurred 2010-12-02T11:54:14 http://paste.lisp.org/display/117258 2010-12-02T11:55:06 what about before and after that? 2010-12-02T11:55:20 a begin or a commit or maybe a rollback? 2010-12-02T11:56:13 heck, it should probably have an error somewhere close by those lines 2010-12-02T11:57:16 no commit or rollback; the previous couple of lines were: 2010-12-02T11:57:18 2010-12-02 10:18:51 CST WARNING: there is no transaction in progress 2010-12-02T11:57:18 2010-12-02 10:18:52 CST ERROR: value "36757001034118" is out of range for type integer 2010-12-02T11:57:18 2010-12-02 10:18:52 CST CONTEXT: PL/pgSQL function "ingest_items" line 238 at assignment 2010-12-02T11:57:44 (before that there's a bunch of the "no transaction in progress" lines) 2010-12-02T11:58:04 ok, so those 3 and then your paste of the INSERT's that are attempted twice? 2010-12-02T11:58:07 36757xxxxxxxxxx looks like one of our barcodes 2010-12-02T11:58:42 its the 852$p so yeah thats your barcode 2010-12-02T11:59:04 so i guess this is probably trying to generate an asset.copy record too? 2010-12-02T11:59:09 dchristens: looks like you've got vandelay trying to ingest embedded items, and the item attr profile thinks $p is the item id 2010-12-02T11:59:49 yep - the above, then a bunch of "no transaction...", then the same WARNING / ERROR / CONTEXT and the second IMPORT 2010-12-02T12:00:05 i think eeevil nailed it 2010-12-02T12:00:41 maybe try without importing the holdings? 2010-12-02T12:00:57 eeevil: what 852 subfield should be used for barcodes to avoid this? 2010-12-02T12:01:02 ok, sec.... 2010-12-02T12:02:15 dchristens: i bet you used the "Evergreen 852 export format" for the profile? 2010-12-02T12:02:21 the default EG export format indeed uses p for barcode 2010-12-02T12:02:33 hmm, nope. even without trying to import holdings, no records get processed 2010-12-02T12:02:35 why did it think it was the itemid? 2010-12-02T12:03:07 *** jenny has joined #evergreen 2010-12-02T12:03:25 mrpeters-isl: without the full INSERT statement, we can't confirm thats actually the problem 2010-12-02T12:03:32 ok 2010-12-02T12:03:42 i'm super interested in this now 2010-12-02T12:03:59 could one create their own profiles for different ils's? 2010-12-02T12:04:37 say, spectrum - i always know 852$h is the call number, 852$9 is the price, etc. 2010-12-02T12:04:43 not the "Evergreen 852 export format" - built one in vandelay.import_item_attr_definition and used that 2010-12-02T12:05:30 oooh this is cool!~ 2010-12-02T12:05:52 cool is good... :-) 2010-12-02T12:09:21 man im jacked about this. this will help a lot of we can set up some new profiles for baker/taylor, etc. 2010-12-02T12:09:31 libraries had just been importing the bibs, then manually attaching holdings 2010-12-02T12:10:26 yeah, we get records with holdings from LSC for our shelf-ready items... it would be nice just to slurp them :-) 2010-12-02T12:13:10 fwiw, it's working much better in 2.0 (and even 1.6.1) 2010-12-02T12:13:28 Do you think that giving postgres a kick (and then restarting eg services) would do the trick here? If so, I'll wait until after hours and do that :-) 2010-12-02T12:13:28 cool! 2010-12-02T12:13:50 eeevil: cool. Might have to fast-track the upgrade :-) 2010-12-02T12:14:56 eeevil: are there a minimum number of fields that must be in the vandelay.import_item_attr_definition? 2010-12-02T12:15:05 or must all be present 2010-12-02T12:15:41 for example - one probably couldn't import a record that only had holdings information containing the barcode, call number and price 2010-12-02T12:16:19 the "Evergreen 852 export format" doesn't seem to have all fields filled... 2010-12-02T12:16:20 since you'd be missing the circ mod, status, owning lib, copy location, etc. - or would those be set based on the home ou of the person doing the import, put into stacks, etc. 2010-12-02T12:18:01 I'd love to see a "if you don't find xxxx in the record, use yyyy" for any of those fields :-) 2010-12-02T12:18:18 yeah i was wondering if it did something like that 2010-12-02T12:18:35 mrpeters-isl: barcode, circ_lib, owning_lib ... I think that's it 2010-12-02T12:18:38 so, take the Unicorn format -- if there was no "location" in 999$l then set it = stacks 2010-12-02T12:19:09 mrpeters-isl: the defaults on the asset.copy table take care of that 2010-12-02T12:19:19 cool! 2010-12-02T12:19:22 ahh 2010-12-02T12:19:52 good job eeevil! you've given me a new feature to bug everyone with questions about! 2010-12-02T12:20:01 :-) 2010-12-02T12:20:09 mrpeters-isl++ 2010-12-02T12:20:13 eeevil++ 2010-12-02T12:20:47 thanks for your help, guys. I'm going to give the entire system a swift kick tonight, and take this up again in the morning :-) 2010-12-02T12:21:10 good lucK! 2010-12-02T12:21:44 * dchristens wishes he hadn't completely borked his test box.... 2010-12-02T12:22:40 I'm upgrading from 1.6.0.8 to 1.6.1.4 on a test machine, following the instructions at http://evergreen-ils.org/dokuwiki/doku.php?id=upgrading:evergreen:1.6.0.8_to_1.6.1.2 ... 2010-12-02T12:23:27 when I attempt to run the 1.6.1.0-1.6.1.1-upgrade-db.sql script, I get a no such file error, and in fact, there is no such file 2010-12-02T12:23:52 csharp: from what tarball? 2010-12-02T12:24:13 eeevil: http://evergreen-ils.org/downloads/Evergreen-ILS-1.6.1.4.tar.gz 2010-12-02T12:25:03 < /full/path/to/1.6.1.0-1.6.1.1-upgrade-db.sql fails too? 2010-12-02T12:25:09 csharp: it's essentially empty: http://svn.open-ils.org/trac/ILS/browser/tags/rel_1_6_1_1/Open-ILS/src/sql/Pg/1.6.1.0-1.6.1.1-upgrade-db.sql 2010-12-02T12:25:10 not in SVN either 2010-12-02T12:25:25 eeevil: ah 2010-12-02T12:25:57 eeevil: looks like it didn't make it into 1.6.1.4, FYI 2010-12-02T12:26:16 i can confirm that...i'm working with that tarball right now 2010-12-02T12:26:18 looks that way 2010-12-02T12:26:29 eeevil: thanks for the link - I'll go from there 2010-12-02T12:26:30 skips over to 1.6.1.1-1.6.1.2-upgrade-db after 1.6.0.4-1.6.1.0-upgrade-db.sql 2010-12-02T12:31:51 *** jamesrf has joined #evergreen 2010-12-02T12:54:51 *** brian_f has joined #evergreen 2010-12-02T13:15:53 *** collum has left #evergreen 2010-12-02T13:22:58 I'm wondering if anyone here monitors the open-ils-dev list. I've sent an email (twice now) and I haven't seen it sent. Not sure if there is an approval path I missed or something. Thanks for any help. 2010-12-02T13:23:36 dmc186 what's your email address? i can check and see if i've received the messages form the list 2010-12-02T13:23:48 or the subject of your messages perhaps 2010-12-02T13:23:49 danny@psu.edu 2010-12-02T13:23:59 subject "problems with multiple service calls" 2010-12-02T13:24:00 hmm nothing here from you 2010-12-02T13:24:15 i'm sure one of the admin's will see this and let you know what's happening 2010-12-02T13:24:17 I'm wondering if I signed up as dmc186@psu.edu and sent the emails with return to as "danny@psu.edu" 2010-12-02T13:24:32 if that would cause a problem :/ 2010-12-02T13:24:59 dmc186: also, i believe there's still a greylist filter on the list for first time posters. 2010-12-02T13:25:42 ok, I apologize for nagging. I just didn't want to keep sending emails and was a little confused if I didn't follow the proper process 2010-12-02T13:25:46 revenge for the opensrf.rb debacle, no doubt 2010-12-02T13:26:10 I blame denials_. 2010-12-02T13:26:16 dmc186: don't worry -- you did the right thing :) 2010-12-02T13:26:28 *** sarahc has joined #evergreen 2010-12-02T13:26:36 alright, thanks. 2010-12-02T13:27:44 dmc186: you can confirm which address is subscribed from either your original subscription confirmation, or here: http://libmail.georgialibraries.org/mailman/listinfo/open-ils-dev 2010-12-02T13:28:12 dmc186: look for the "To unsubscribe from Open-ils-dev, get a password reminder, or change your subscription options enter your subscription email address:" line at the bottom 2010-12-02T13:32:25 jeff: thanks. I'll try sending one more time 2010-12-02T13:33:49 jeff: that seemed to do the trick. Thanks again. 2010-12-02T13:34:13 jeff++ 2010-12-02T13:43:19 back to the discussion about vandelay.import_item_attr_definition - 2 questions 2010-12-02T13:43:33 there is no "loan_duration" column.... 2010-12-02T13:43:43 is that overlooked and maybe in 2.0? set elsewhere? 2010-12-02T13:44:41 also, age_protect 2010-12-02T13:47:23 also, considering the Unicorn format that is already defined - for something like "owning_lib" which maps to 999$m - what is the expected value? an actor.org_unit.id? a actor.org_unit.shortname? 2010-12-02T13:47:48 and really, the same questions for things like status, location, circ_modifier, etc. 2010-12-02T13:47:56 will it match a text string, or just an integer 2010-12-02T13:51:34 *** b_bonner has joined #evergreen 2010-12-02T13:53:45 *** sarahc has quit IRC 2010-12-02T14:10:09 maybe http://paste.lisp.org/display/117260 helps clarify what I'm trying to accomplish... 2010-12-02T14:10:36 would the new profile inserted there, then handle a binary MARC with a 949 containing those values? 2010-12-02T14:23:44 * Dyrcona is doing his first evergreen install from scratch in 3 years. tsbere has done all the others for me. 2010-12-02T14:32:39 ^^ no dice on a record with =949 \\$a4 $b4 $cCD BTNHR $d1 $e5 $f1 $gt $hf $jf $kt $l9.99 $m1234567891234 $ncd-music $pPrivate alert message here $qt $rPublic $sPublic Note Here $tPrivate Note $uPrivate Note Here 2010-12-02T14:38:40 everything comes into vandelay.import_item except for owning_lib, circ_lib, status, and location (crucial things!) 2010-12-02T14:39:16 i've tried both "id" values that match in the db and text strings that match my workstation registration shortname and the string for a copy location at that shortname 2010-12-02T14:42:56 Dyrcona: How goes it? 2010-12-02T14:53:11 so far so good, just started configure in openils. opensrf is already installed. 2010-12-02T14:54:28 tsbere: any suggestions on a client build_id? rel_trunk r[whatever it is]? 2010-12-02T14:55:54 *** jenny has quit IRC 2010-12-02T14:58:56 patch from earlier js combine/compress discussion. -isl> back to the discussion about vandelay.import_item_attr_definition - 2 questions 2010-12-02T14:59:05 copy/past-- 2010-12-02T15:00:29 patch from earlier js combine/compress discussion: http://dev198.esilibrary.com/~berick/theswamp/compress_js_patch.txt on my dev box, reduces empty-cache load from 6.4 to 4.2 secs to onload (with compression) 2010-12-02T15:00:54 Dyrcona: The default? 2010-12-02T15:01:15 tsbere: used rel_trunk. just copied from the README. :) 2010-12-02T15:04:07 *** alxp has quit IRC 2010-12-02T15:07:52 heh berick tricked me! i thought you had a magic answer :) 2010-12-02T15:07:56 Something I don't get from the ILS README: It says to configure the "Evergren" opensrf config files like the "OpenSRF" opensrf config files, and the example shows copying the *.example files in /openils/conf just like with the OpenSRF installation. 2010-12-02T15:08:50 Dyrcona: yep - Evergreen installs new examples during the install 2010-12-02T15:09:20 so the OpenSRF'ified versions become Evergreen versions with all of the Evergreen processes in the opensrf.xml 2010-12-02T15:09:29 ok. the README should make that clear. 2010-12-02T15:10:02 perhaps! 2010-12-02T15:10:33 maybe a opensrf.xml.OpenSRF.example and an opensrf.xml.Evergreen.example structure? 2010-12-02T15:11:08 *** bshum has joined #evergreen 2010-12-02T15:12:05 * Dyrcona feels cheated into configuring what is basically the same thing twice. 2010-12-02T15:12:20 * Dyrcona absolutely despises repetitious work. 2010-12-02T15:12:21 ah, but its not! 2010-12-02T15:12:30 there is MUCH more to configure in the Evergreen version 2010-12-02T15:12:46 maybe not out of the box, but there are more things to tweak at least... 2010-12-02T15:12:46 it is if you don't start opensrf to test it. you still do that work again. 2010-12-02T15:13:13 That is why I rarely do the opensrf config steps and go straight to evergreen these days. 2010-12-02T15:15:07 *** dbs has joined #evergreen 2010-12-02T15:15:07 *** dbs has joined #evergreen 2010-12-02T15:23:46 tsbere: just created and ran a reloaddb.sh. :) 2010-12-02T15:24:23 so, I think it's done. 2010-12-02T15:26:18 bshum: I think you should chime in on Repke's thread about setting up org_units. You could explain to him how you do it in PGAdmin. I'd like to know what you do, myself. 2010-12-02T15:26:33 Dyrcona: Oh, sure :) 2010-12-02T15:26:54 * Dyrcona now has a clean database, but still has to configure apache. 2010-12-02T15:26:58 Dyrcona: I just got back home so I'm poking at my list of acorn troubles first. But I'll try and get to that as soon as I can. 2010-12-02T15:27:27 bshum: no hurry. 2010-12-02T15:28:51 Question about something 2010-12-02T15:28:52 http://www.open-ils.org/dokuwiki/doku.php?id=upgrading:evergreen:1.6.0.2_to_1.6.0.3 2010-12-02T15:29:02 In step 5 of this, it asks you to perform a billing view hotfix 2010-12-02T15:29:05 What is that all about? 2010-12-02T15:37:01 Hmm 2010-12-02T15:42:50 * Dyrcona takes a break from setting up Evergreen to create an import source in his legacy ILS for some bib imports. 2010-12-02T15:48:07 bshum: it's probably the fix that PINES needed to allow the viewing of patron bills when they had huge numbers of xacts in their histories 2010-12-02T15:48:31 before that, the billing screen would sometimes take a full minute to load for certain patrons 2010-12-02T15:49:58 * csharp doesn't really know if that's what it is though ;-) 2010-12-02T15:57:59 *** b_bonner has quit IRC 2010-12-02T15:58:19 *** shopkins has quit IRC 2010-12-02T16:00:41 Okay 2010-12-02T16:00:52 csharp: Heh, thanks 2010-12-02T16:00:57 New question 2010-12-02T16:00:59 Beta4 Staff Client for Windows is now available here https://docs.google.com/leaf?id=0BzQXgF79e0mNNjcxZDczOGMtZGJkMy00YmFhLTlhOGQtMDMxMjVlYzZjZWZh&sort=name&layout=list&num=50 2010-12-02T16:01:20 Should be public share 2010-12-02T16:01:20 What is the due date entry supposed to be? 00:00:00 or 23:59:59 2010-12-02T16:01:34 For an action.circulation event 2010-12-02T16:01:49 (we've got one day in fines disappearing during backdating) 2010-12-02T16:02:20 So for example, an item due on 11/30 that was returned on 12/2, but backdated to 12/1 2010-12-02T16:02:23 bshum: in PINES it's always 00:00:00 and our libraries aren't complaining ;-) 2010-12-02T16:02:24 Is having no fines due on it 2010-12-02T16:02:41 csharp: The items with this behavior are 23:59:59 2010-12-02T16:03:06 that's ringing a bell... but I'm not able to remember why 2010-12-02T16:03:09 Hence my worry that maybe there's some legacy issue from our previous data from our 1.6.0.2 days before our recent upgrade 2010-12-02T16:03:16 I know that there was a fine bug resulting in a fine into the future 2010-12-02T16:03:34 also, there may be a grace period in effect - I don't think that's just a PINES thing 2010-12-02T16:03:45 We don't have grace enabled. 2010-12-02T16:03:51 * csharp waits for someone who knows to tell him he's got it all wrong 2010-12-02T16:04:00 ah, ok 2010-12-02T16:04:24 csharp: Let's just say I don't want to think about trying to write something to go in and fix all the due dates :) 2010-12-02T16:04:33 At least not tonight 2010-12-02T16:04:44 heh - I've been there 2010-12-02T16:06:35 *** mtcarlson has joined #evergreen 2010-12-02T16:07:53 Okay, no difference between one or the other actually 2010-12-02T16:08:02 Just checked in two different items on our test system 2010-12-02T16:08:11 One with 00:00:00 and another with 23:59:59 2010-12-02T16:08:15 Both due on 11/29 2010-12-02T16:08:20 And backdated to 12/1 2010-12-02T16:08:54 Unless maybe I'm counting wrong to myself... 2010-12-02T16:08:55 bshum: there's some weird thing with days after closed dates that PINES has seen 2010-12-02T16:09:44 csharp: I thought of that, because we ended up having a closed date on 11/27 for the library in question 2010-12-02T16:09:48 I don't recall the specifics, but that may be what your situation is reminding me of 2010-12-02T16:10:02 Which would have been in the middle of things 2010-12-02T16:10:26 Well, right before it actually 2010-12-02T16:10:30 Still, quite strange 2010-12-02T16:12:46 Maybe I'll try a different org unit 2010-12-02T16:12:50 To be sure it's not just thm 2010-12-02T16:12:51 \ 2010-12-02T16:15:21 bshum: I just asked my colleague who manages our Helpdesk and she recalls a problem that was intermittent that interfered with the way fines are calculated 2010-12-02T16:15:56 she's searching for ESI's response from their helpdesk, which I'll share with you if she finds it 2010-12-02T16:16:06 csharp: We were informed of a fine bug where we had fines incurred into the future 2010-12-02T16:16:09 Due to the 1 second issue 2010-12-02T16:16:41 I don't *think* that's the same thing I'm thinking about 2010-12-02T16:17:01 Heh 2010-12-02T16:17:04 So many fine bugs! 2010-12-02T16:17:05 :) 2010-12-02T16:17:20 yes, and in PINES it's hard not to find them! 2010-12-02T16:17:28 I'll bet. 2010-12-02T16:21:44 But let me try to make sure I'm getting this right 2010-12-02T16:21:50 An item that's due on 11/30 2010-12-02T16:21:58 Should have one day of fine when checked in on 12/1 2010-12-02T16:22:08 Two days of fines if checked in on 12/2 2010-12-02T16:22:22 And if we "backdate" to 12/1, we should still get 1 day of fine 2010-12-02T16:22:27 Rather than both being voided 2010-12-02T16:22:34 * Dyrcona is seriously considering giving up on loading update marc records for an online service in his legacy ILS. the records are crap and there's nothing other than the 856, possibly, to use a match point for overlay. 2010-12-02T16:22:46 that's right from my perspective 2010-12-02T16:22:50 But then, the billing_ts (timestamp) in the money.billing entries for the transaction 2010-12-02T16:23:00 Should be for 12/1, 12/2? 2010-12-02T16:23:04 Or 11/30, 12/1 2010-12-02T16:23:22 bshum: I am moving the discussion of creating org_units to the dev list, so please follow up there when you get the time. 2010-12-02T16:23:24 The bill should generate on 12/1 for 11/30 being overdue 2010-12-02T16:23:38 Dyrcona: Sorry man, will do 2010-12-02T16:23:50 * bshum slowly going insane looking at these billings, sigh :( 2010-12-02T16:24:09 Maybe the backdate is voiding one too many days? 2010-12-02T16:25:25 the billing_ts would be the backdated date, whatever it is 2010-12-02T16:26:25 (which results in hair pulling when you're trying to track down when the backdating occurred!) 2010-12-02T16:26:37 Hmm 2010-12-02T16:27:02 Yeah, I consistently result in 2 days of fines voided every time I use the backdate to yesterday... 2010-12-02T16:27:19 No matter how long the item has been overdue 2010-12-02T16:27:23 So either that's... normal? 2010-12-02T16:27:31 Or there's something wrong with the backdate 2010-12-02T16:28:17 csharp: PS, thanks for talking me through my crazy. I'll file some coherent thoughts on this soon... 2010-12-02T16:28:49 bshum: sure :-) 2010-12-02T16:29:24 bshum: http://paste.lisp.org/display/117270 2010-12-02T16:29:56 this was related to our grace period, but it may be relevant to your problem 2010-12-02T16:30:20 csharp: Yikes, since we're not using grace periods and we're on 1.6.1.3 (almost 1.6.1.4) 2010-12-02T16:30:55 bshum: right - it may not be relevant to 1.6.1X 2010-12-02T16:31:05 okay - I'm gonna jet 2010-12-02T16:31:09 bshum: good luck 2010-12-02T16:31:17 csharp: Thanks, take it easy! :) 2010-12-02T16:32:15 *** kmlussier has quit IRC 2010-12-02T16:33:22 00:00:00 is the start of the day, so if you generate fines for items with due times of 00:00:00 during that day without a grace period, DING, you get fined for an overdue on the day that the item is due. 23:59:59 better reflects what people expect from due dates. 2010-12-02T16:34:39 dbs: That makes sense to me. 2010-12-02T16:34:59 dbs: But.... still confused :) 2010-12-02T16:35:10 Or maybe it's working but I'm just not getting it. 2010-12-02T16:36:32 We were probably one of the first sites to be running the fine-generator multiple times per day (due to hourly loans) and therefore to run into this 2010-12-02T16:37:15 which is why there is a trigger on action.circulation (IIRC) that pushes the due time for circs with a loan duration exactly divisible by 24 hours to 23:59:59 2010-12-02T16:37:53 * dbs hasn't read all of the backscroll so might be missing some relevant info 2010-12-02T16:39:12 dbs: Heh, if you get a chance to take a look at it, let me know if my logic is really flawed 2010-12-02T16:39:31 dbs: Else I'd be happy to retype out our situation 2010-12-02T16:40:24 It's quite possible that I'm just not interpreting things correctly. 2010-12-02T16:47:48 bshum: It would be great if you could reproduce the problem on, say, the 1.6.1.4 virtual image and open a bug with the details 2010-12-02T16:48:01 dbs: I will attempt to do so now. 2010-12-02T16:48:40 * dbs also wonders when the time change occurred and if the due time was for GMT-5 and is being calculated with the backdate as GMT-4. Or something like that. 2010-12-02T16:51:31 Dyrcona: there's no "bringing back" the bootstrap UI, it was so far out of date it would be a rewrite. 2010-12-02T16:52:04 Also, so far I haven't seen anyone volunteering to create that. 2010-12-02T16:52:07 *** Melissa1 has left #evergreen 2010-12-02T16:52:51 Also, perhaps it would be wiser to delete all org units not in (1,2,4) so that there's a viable branch left to attach a user to 2010-12-02T16:53:31 Also, I suspect Repke is using the virtual image which comes with (I believe) one bib + volume + copy attached to BR1 2010-12-02T17:02:34 dbs: that last is his problem, then. 2010-12-02T17:03:36 deleting org_units from SQL doesn't work if there is anything "attached" to them. 2010-12-02T17:03:46 You can add "CASCADE", no? 2010-12-02T17:04:09 you can try. I haven't bothered, 'cause i haven't need to. 2010-12-02T17:04:24 i thought some of the triggers would get in the way, though. 2010-12-02T17:04:53 Hrm, possibly 2010-12-02T17:05:45 Which would mean, as part of the clean-out script, modifying the table definitions, issuing the "delete", and then reinstating the definitions 2010-12-02T17:06:19 Still seems like it would be easier to just make it an eg_db_config.pl option, like --no-sample-data 2010-12-02T17:07:03 yep. 2010-12-02T17:07:25 (and then we can have an uber amount of sample data to load for the --sample-data case :) 2010-12-02T17:07:28 you'd still need to create org_units somehow. 2010-12-02T17:07:34 :) 2010-12-02T17:07:41 but just the root 2010-12-02T17:07:55 i would kill for a clean MARC dataset. Vendors send us such junk. 2010-12-02T17:08:11 Dyrcona: have you taken a look at the UMich dataset? 2010-12-02T17:08:18 *** moodaepo has quit IRC 2010-12-02T17:08:32 FBI: if you're reading this, please not "kill" was meant in a metaphorical fashion. 2010-12-02T17:08:42 ^not^note 2010-12-02T17:08:57 gmcharlt: no i haven't. 2010-12-02T17:09:04 Dyrcona: worry not, the FBI is only interested in your patron records, not your MARC records 2010-12-02T17:09:31 *** jenny1 has joined #evergreen 2010-12-02T17:10:02 gmcharlt: i've been trying to load 129 update bib records into my legacy ILS today. I've tried several fields for match points and decided that the input is so bad, I can't match on anything except the 856u. 2010-12-02T17:10:04 but "we" know that the 710 that we are in the process of adding is a publisher, and wouldn't it be better to add the $4 pbl so that the field actually is machine-readable? 2010-12-02T17:10:08 * dbs weeps 2010-12-02T17:10:20 Dyrcona: ouch 2010-12-02T17:10:44 part of the problem is how we've done "copy cataloging" in the past. 2010-12-02T17:11:13 Dyrcona: sounds like, for 129 records, doing each record manually would be a better option at this point 2010-12-02T17:12:58 * Dyrcona is not a cataloger and should pass this job off to one. 2010-12-02T17:15:58 *** sfortin has quit IRC 2010-12-02T17:24:01 *** moodaepo has joined #evergreen 2010-12-02T17:28:48 *** Dyrcona has left #evergreen 2010-12-02T17:31:04 *** gdunbar has quit IRC 2010-12-02T17:35:16 *** dmc186 has left #evergreen 2010-12-02T17:37:26 *** dchristens has quit IRC 2010-12-02T17:40:54 dbs: Let me make sure I have some variables correct... 2010-12-02T17:42:27 I created an item due on 2010-11-12 2010-12-02T17:42:41 Or rather, I updated the action.circulation event so that was the new due-date 2010-12-02T17:42:49 2010-11-12 23:59:59-05 2010-12-02T17:42:55 Then, I ran the fine generator 2010-12-02T17:43:05 And checked money.billing and found entries for the dates in question 2010-12-02T17:43:22 Then, I went to check in the item using a backdate of 2010-11-30 2010-12-02T17:43:39 It voided three fine events, 11-30, 12-1, 12-2 2010-12-02T17:46:17 *** mjg_ has joined #evergreen 2010-12-02T17:47:22 The first fine is dated 11-13, and through 11-29 is not voided 2010-12-02T17:47:34 Adding up to $1.70 (at $0.10 per day) 2010-12-02T17:47:35 So it sounds like it's voiding one extra day's worth of fines. Perhaps the backdate function, because it can't know about grace periods, is hard-coded to allow a grace period of 1? 2010-12-02T17:48:06 Oddly the message indicates a fine of $2.10 2010-12-02T17:48:07 (heh, I'm not sure if that even makes any sense) 2010-12-02T17:48:20 oh, that's fun 2010-12-02T17:48:23 But it voids the $0.30 2010-12-02T17:48:28 In the billing summary 2010-12-02T17:48:51 It shows up as you owe $2.10, but total billed of $1.70 2010-12-02T17:49:14 Quite misleading to the balance information too 2010-12-02T17:49:21 Heh, I could see that being quite confusing 2010-12-02T17:49:39 We probably didn't see that since we were backdating to yesterday's overdue, and it completely nullified the billing event 2010-12-02T17:49:48 So it was a completely voided transaction 2010-12-02T17:49:52 Even though it should have had one day 2010-12-02T17:50:10 * dbs needs to go do dinner things 2010-12-02T17:50:22 dbs: Thanks Dan, I'll file something on LP on this 2010-12-02T17:50:30 Enjoy your dinner! 2010-12-02T17:50:40 bshum++ 2010-12-02T17:56:10 *** b_bonner has joined #evergreen 2010-12-02T18:01:24 *** yboston has quit IRC 2010-12-02T18:14:31 *** mtcarlson has quit IRC 2010-12-02T18:18:22 *** jenny1 has left #evergreen 2010-12-02T18:28:16 How would one check what version of OpenSRF is installed on the server? 2010-12-02T18:34:22 *** b_bonner has quit IRC 2010-12-02T19:05:21 *** mjg_ has left #evergreen 2010-12-02T19:36:37 bshum: in 1.6.0 and later, fines are generated with future dates. on the first day you get a fine, it'll show as dated that day at 23:59, even though 23:59 hasn't come yet. 2010-12-02T19:36:50 bshum: might help explain what you were seeing, might not. 2010-12-02T19:39:10 jeff: That sounds reasonable, but I still think either I'm counting my days wrong during my tests or something else is being quirky 2010-12-02T19:40:06 I don't work the desk, so I'm just trying to understand based on what seems to be happening from examining tables 2010-12-02T19:40:51 * jeff nods 2010-12-02T19:41:03 Supposedly this didn't happen till after we upgraded to 1.6.1 from 1.6.0, but then again it might have always been that way and nobody noticed till after we told them about the upgrade... ;) 2010-12-02T19:41:03 i haven't read the whole description above, just skimmed -- sorry :) 2010-12-02T19:41:38 jeff: heh 2010-12-02T19:41:58 I did notice that there were some changes made recently to the backdate functions 2010-12-02T19:42:16 So I've been trying to pin down what happened and also to learn how the backdate function itself is used. 2010-12-02T19:42:28 It's not my strongest area though 2010-12-02T19:42:51 circs starting before (or maybe just those that came overdue before) 1.6 for us gained an extra day of billings. this was on top of some billing summary issues we had (which i think were eventually determined to be functions/triggers/views (one of or a mix of) that didn't get updated 2010-12-02T19:44:03 jeff: That's part of the reason we made our upgrade to 1.6.1 a high priority. We were using 1.6.0.2 (with some critical fixes applied manually) 2010-12-02T19:44:24 jeff: We knew there was a fine bug that was generating an extra day of fine in the "future" 2010-12-02T19:44:36 That does seem to be resolved, but now the backdate thing has us stumped again. 2010-12-02T19:45:23 Course, this might all just be legacy bad information in our money.billing table from pre-upgrade 2010-12-02T19:45:43 But then dbs asked me to replicate the problem on the fresh 1.6.1.4 VM and it still showed up there... 2010-12-02T19:45:47 So I'm at a loss :S 2010-12-02T19:47:00 I've been contemplating getting a 1.6.0.x system installed to see if the problem shows up there the same way. 2010-12-02T19:48:34 Thanks though. 2010-12-02T20:06:08 leed++ 2010-12-02T20:08:56 jamesrf: hmm? 2010-12-02T20:09:05 Oye 1.6.1.4 doesn't have Lucid option 2010-12-02T20:11:21 moodaepo: Don't the instructions say to use ubuntu-karmic for it? 2010-12-02T20:12:06 bshum: Read instructions? Say what!? : ) 2010-12-02T20:12:27 moodaepo: Pfft, you're absolutely right. Go with the gut! 2010-12-02T20:13:14 I upgraded our dev server which was running hardy/1.6.1.4 to lucid 2010-12-02T20:13:54 *** brian_f has quit IRC 2010-12-02T20:13:55 And turns out have run through parts of the install for OpenSRF and EG again, packages/cpan modules got removed 2010-12-02T20:14:13 Peachy 2010-12-02T20:16:35 Ugh will troubleshoot 'morrow 2010-12-02T20:19:16 *** jamesrf has quit IRC 2010-12-02T20:21:55 @later tell brian_f awesome, thanks! 2010-12-02T20:21:55 eeevil: The operation succeeded. 2010-12-02T20:43:00 *** jamesrf has joined #evergreen 2010-12-02T20:44:51 *** tildeequals has joined #evergreen 2010-12-02T22:17:05 *** tildeequals_ has joined #evergreen 2010-12-02T22:17:26 *** tildeequals has quit IRC 2010-12-02T22:24:27 *** tildeequals_ has quit IRC 2010-12-02T22:25:01 *** tildeequals has joined #evergreen 2010-12-02T22:50:15 *** bshum has quit IRC 2010-12-02T23:01:01 *** rsinger_ has joined #evergreen 2010-12-02T23:01:55 *** rsinger has quit IRC 2010-12-02T23:01:55 *** rsinger_ is now known as rsinger 2010-12-02T23:05:06 *** rsinger_ has joined #evergreen 2010-12-02T23:05:06 *** rsinger has quit IRC 2010-12-02T23:05:10 *** rsinger_ is now known as rsinger 2010-12-02T23:19:36 *** DelphiKnight has joined #evergreen 2010-12-02T23:28:50 *** DelphiKnight has quit IRC