| # | Time | Nick | Message |
|---|
| # | 00:50:08 | machlang has joined #evergreen |
| # | 00:52:06 | machlang has left #evergreen |
| # | 02:26:32 | trhodes has quit IRC |
| # | 03:14:38 | dian has joined #evergreen |
| # | 03:16:19 | dian | i need help i'm runnig ubuntu hardy server |
| # | 03:16:33 | dian | after all done apache2 fails to start |
| # | 03:16:40 | brendan_bywater has quit IRC |
| # | 03:30:08 | brendan_bywater has joined #evergreen |
| # | 03:55:25 | dian | [error] Can't locate SRU/Request.pm in @INC (@INC contains: /openils/lib/perl5 |
| # | 03:55:28 | dian | help |
| # | 04:00:34 | dian | [error] Can't locate SRU/Request.pm in @INC (@INC contains: /openils/lib/perl5 /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . /etc/apache2) at /openils/lib/perl5/OpenILS/WWW/SuperCat.pm line 12.\nBEGIN failed--compilation aborted at /openils/lib/perl5/OpenILS/WWW/SuperCat.pm line 12.\nCompilation failed in require at / |
| # | 04:00:41 | dian | [error] Can't locate SRU/Request.pm in @INC (@INC contains: /openils/lib/perl5 /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . /etc/apache2) at /openils/lib/perl5/OpenILS/WWW/SuperCat.pm line 12.\nBEGIN failed--compilation aborted at /openils/lib/perl5/OpenILS/WWW/SuperCat.pm line 12.\nCompilation failed in require at / |
| # | 04:00:44 | dian | . |
| # | 04:54:11 | natschil has joined #evergreen |
| # | 05:38:38 | Luca__ has joined #evergreen |
| # | 05:40:20 | Luca__ | hi, I've installed Evergreen client 1.6.0.3, however on one machine, I get the "TypeError: g.my_libs_tree is null" when it comes to registering the WS Name. Can somebody provide some help on this one ? thank you |
| # | 06:21:24 | natschil has quit IRC |
| # | 06:52:28 | natschil has joined #evergreen |
| # | 07:13:39 | natschil has quit IRC |
| # | 07:32:44 | Guest12938 has joined #evergreen |
| # | 07:33:09 | Guest12938 is now known as Cell |
| # | 07:34:30 | Cell | Just followed the manual for the OpenSRF and Evergreen installation. Everything installed well. But at the last step when trying to run the following command: ./autogen.sh -c /openils/conf/opensrf_core.xml -u |
| # | 07:34:58 | Cell | We receive: Exception: OpenSRF::EX::Session 2010-03-05T13:21:18 OpenSRF::Utils::SettingsClient /usr/local/share/perl/5.10.0/OpenSRF/Utils/SettingsClient.pm:103 Session Error: router@private.localhost/opensrf.settings IS NOT CONNECTED TO THE NETWORK!!! |
| # | 07:35:05 | Cell | Anybody seen this before? |
| # | 07:35:32 | Cell | All services are starting well |
| # | 07:36:02 | Cell | Debian-lenny |
| # | 07:47:00 | dian | followed install page for ubuntu but get a Empty filename at /openils/lib/perl5/OpenILS/Utils/Fieldmapper.pm line 192 error |
| # | 07:47:09 | dian | any sug? |
| # | 07:49:50 | sfortin has joined #evergreen |
| # | 08:00:09 | mck9 has joined #evergreen |
| # | 08:07:46 | dian | this is what line 192 in /openils/lib/perl5/OpenILS/Utils/Fieldmapper.pm looks like [my $fmdoc = $parser->parse_file( $file );] |
| # | 08:11:16 | jeff | dian: make sure you have the opensrf.xml and opensrf_core.xml files from Evergreen, and not left over from your OpenSRF install (they are different) |
| # | 08:12:53 | jeff | Cell: sounds like your opensrf services are having trouble connecting to the jabber server. re-check your usernames/passwords, check ejabberd logs for clues, stop everything and start it back up while watching error logs? |
| # | 08:13:00 | jeff | http://evergreen-ils.org/dokuwiki/doku.php?id=troubleshooting:checking_for_errors is the "check everything" document |
| # | 08:14:21 | jeff | Luca__: you might need to run autogen.sh. see step 15.3 in http://evergreen-ils.org/dokuwiki/doku.php?id=server:1.6.0:install -- cd /openils/bin && ./autogen.sh -c /openils/conf/opensrf_core.xml -u |
| # | 08:17:49 | dian | will have a crack at it |
| # | 08:19:08 | Cell | @jeff, hmmmm! got it working now after removing pid files, rebooting, and running ./autogen.sh -c /openils/conf/opensrf_core.xml -u INSTEAD of ./autogen.sh -c /openils/conf/opensrf.xml -u (notice the difference with opensrf_core.xml and opensrf.xml) |
| # | 08:19:08 | pinesol | Cell: Error: "jeff," is not a valid command. |
| # | 08:20:32 | Cell | jeff: hmmmm! got it working now after removing pid files, rebooting, and running ./autogen.sh -c /openils/conf/opensrf_core.xml -u INSTEAD of ./autogen.sh -c /openils/conf/opensrf.xml -u (notice the difference with opensrf_core.xml and opensrf.xml) |
| # | 08:20:39 | Cell | sorry for double post |
| # | 08:23:41 | dian | how do i get the new opensrf.xml and opensrf_core.xml into the conf dir it seems that accourding to my time stamp they are the old files left from the opensrf installation |
| # | 08:35:46 | dian | rebooted the server now got this OpenSRF::Utils::SettingsClient /usr/local/share/perl/5.8.8/OpenSRF/Utils/SettingsClient.pm:103 Session Error: router@private.localhost/opensrf.settings IS NOT CONNECTED TO THE NETWORK!!! |
| # | 08:36:17 | dian | router and opensrf are registered and their passwords are set in *.xml |
| # | 08:36:23 | Luca__ | hi ... how do I find documentation on how to configure the Evergreen server, the library, branches and all ? thanks |
| # | 08:49:08 | Luca__ | jeff i've run the script successfully, plus on another computer running the same OS (winxp sp3) the client does not generate the error. |
| # | 08:49:35 | Luca__ | it must that particular machine, but I can't figure out what is missing |
| # | 09:02:40 | jeff | possibly your ws_info file is specifying an ou shortname that no longer exists on that server... |
| # | 09:02:49 | jeff | if this works on other workstations, try deleting your local ws_info file. |
| # | 09:09:18 | Meliss has joined #evergreen |
| # | 09:10:33 | Luca__ | where would I find ws_info ? |
| # | 09:10:49 | Luca__ | it's not in the evergreen client installation folder |
| # | 09:16:46 | jeff | you should find it in %appdata%\OpenILS\open_ils_staff_client\RANDOMCHARS.default\chrome\ |
| # | 09:17:06 | jeff | sorry, stick a "Profiles" in there after open_ils_staff_client |
| # | 09:18:49 | jenny has joined #evergreen |
| # | 09:25:39 | dian has quit IRC |
| # | 09:29:01 | Luca__ | jeff: thank you :) i've unistalled Mozilla Firefox and Evergreen and their relative appdata folders and proceded with their re-installation. it seems to be working. many thanks for your help :) |
| # | 09:30:12 | jeff | great! glad to hear it. :) |
| # | 09:30:33 | mariposa has quit IRC |
| # | 09:34:21 | Luca__ | ;) |
| # | 09:34:41 | dbs has joined #evergreen |
| # | 09:35:04 | Luca__ | jeff ... sorry ... you might know where I can find docs for the server configuration ... to set up the library, brances and so on ... thanks :) |
| # | 09:38:05 | dbs | Luca__: http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-admin:policies |
| # | 09:39:01 | Luca__ | cheers :) |
| # | 09:40:16 | dbs | The info is decidedly out-of-date in some areas, but the general concepts are the same. |
| # | 09:48:29 | Luca__ | in case I'll ask ;) |
| # | 09:52:18 | Luca__ has quit IRC |
| # | 09:58:32 | dbs | So, we've been using the rel_1_6 version of z3950.js for a few days now with no incident - can I call the randomized display of target Z39.50 servers in "Import from Z39.50" a "bug" so that I can justify backporting it to rel_1_6_0? |
| # | 09:58:56 | miker_ | dbs: I don't have any objection |
| # | 09:59:30 | dbs dances |
| # | 10:00:39 | dbs | mbxs.balance_owed == mmbxs.balance_owed several days later, btw. yay |
| # | 10:00:42 | dbs dances again |
| # | 10:00:48 | jeff | yay :) |
| # | 10:21:59 | r123 has joined #evergreen |
| # | 10:24:21 | dbs | "Circ: Void lost max interval" means what in library settings? |
| # | 10:25:18 | dbs | Hmm, the entity name gives a better clue: max_accept_return_of_lost |
| # | 10:30:45 | bshum has joined #evergreen |
| # | 10:50:50 | Cell | Anybody recognizes this?: OpenSRF::Transport::SlimJabber::PeerConnection /usr/local/share/perl/5.10.0/OpenSRF/Transport/SlimJabber/PeerConnection.pm:60 Config Exception: JPeer could not load all necessary values from config |
| # | 10:50:50 | dbs | We need to be using in-db circulation, not scripts, if we want to take advantage of stuff like trigger / reactor to mark items lost, yeah? |
| # | 10:51:06 | Cell | It happens when executing: ./autogen.sh -c /openils/conf/opensrf.xml -u |
| # | 10:51:19 | dbs | yeah, you don't want that |
| # | 10:51:29 | dbs | ./autogen.sh -c /openils/conf/opensrf_core.xml -u |
| # | 10:51:36 | dbs | should work better for you. |
| # | 10:52:21 | Cell | yeah, true. But I can't find the difference between opensrf.xml and opensrf_core.xml There is much difference in file content, but what is the difference in meaning? |
| # | 10:52:33 | Cell | Hope you understand me, I can't find it with google |
| # | 10:54:37 | miker_ | dbs: re in-db circ, no ... action/trigger is orthoganal to in-db circ |
| # | 10:55:04 | dbs | miker_: oh, goody! |
| # | 10:55:24 | dbs | Cell: are you following instructions for installing and configuring Evergreen from somewhere? |
| # | 10:56:01 | Cell | Yes, official instructions |
| # | 10:56:32 | Cell | http://evergreen-ils.org/dokuwiki/doku.php?id=server:1.6.0:install and http://evergreen-ils.org/dokuwiki/doku.php?id=opensrf:1.2:install |
| # | 10:56:59 | dbs | Okay, that's good |
| # | 10:57:15 | Cell | Everything works okay, except this last part |
| # | 10:57:25 | dbs | Did you type the correct command this time? |
| # | 10:57:41 | dbs | The instructions point at a particular file for a reason |
| # | 10:57:59 | Cell | ok i'll look up again |
| # | 10:58:28 | dbs | opensrf_core.xml mostly contains the XMPP server communication configuration instructions, along with a link to opensrf.xml that contains the OpenSRF application configuration information. |
| # | 10:58:52 | dbs | So if you point to opensrf.xml, autogen.sh has no idea how to communicate with the XMPP server. |
| # | 11:04:48 | Cell | you are right, point 15.3 in http://evergreen-ils.org/dokuwiki/doku.php?id=server:1.6.0:install mentions the opensrf_core.xml file and NOT opensrf.xml |
| # | 11:06:07 | Cell | but opensrf.xml contains some kinds of templates when I view the contents. Imagine I have to change some of this, would I have to run autogen with the opensrf.xml parameter to apply the changes? Because if that is the case, we are still encountering this JPeer error |
| # | 11:07:27 | dbs | No. You never have to run autogen.sh pointing to opensrf.xml. So I won't imagine that case. |
| # | 11:09:02 | Cell | Thanks dbs! Some other person which has quite some experience with this all said to us to use opensrf.xml as an autogen.sh parameter. But now I know this is not the case :-) |
| # | 11:09:13 | dbs | :) |
| # | 11:12:43 | Cell | Ah.. nice.. customer happy and me as a hired linux expert happy ;-) Going home now, see you (-: |
| # | 11:12:49 | Cell has quit IRC |
| # | 11:15:30 | grantjohnson has joined #evergreen |
| # | 11:30:04 | dbs | Argh, dojo widgets... give me the frickin' org_unit list! I know I'm not ADMIN. |
| # | 11:31:57 | dbs added EVERYTHING perm temporarily to his usr perms to be able to view the consortium event definitions, but in trying to clone the Lost event def it won't give me a drop-down list of OUs |
| # | 11:35:55 | dbs adds ADMIN_TRIGGER_EVENT_DEF to the permission.perm_list + grants that priv and SUCCESS |
| # | 11:48:13 | r123 has left #evergreen |
| # | 11:53:39 | r123 has joined #evergreen |
| # | 11:54:45 | miker_ | yay ... conify is now unbroken for translations |
| # | 11:57:40 | dbs | miker_++ |
| # | 11:58:12 | dbs successfully clones and modifies event definitions to set a 30-day lost event for one of our libraries |
| # | 11:59:02 | dbs | Can I assume that the branch definition will override the consortial definition, so that the user doesn't get dinged for both a 30-day and a 90-day lost event for the same item? |
| # | 12:06:45 | jeff | i think that might (MIGHT) be up to the validator to ensure that the item isn't already marked lost? |
| # | 12:06:59 | jeff | (before marking it lost again) |
| # | 12:07:16 | jeff | but i don't know if there's a general "first event matched is the last event" |
| # | 12:08:32 | dbs | jeff: hmm, that would be a good thing to add as well; currently set to "CircIsOverdue" but I guess it could be "CircIsOverdueAndNotAlreadyLOST" |
| # | 12:09:25 | dbs | Most things in EG seem to work from a "most specific" wins principle, so I'm hoping action trigger follows that approach :) |
| # | 12:09:50 | jeff | interesting quirk, title holds always ignore running circ_hold_permit scripts on copies set (at the copy level) to holdable: no, but volume and copy holds rely on the circ_permit_hold (or in-db) to enforce that copy-level holdable: no |
| # | 12:09:52 | atz | typically lost items are off the user's account, so they *aren't* checked out/overdue anymore |
| # | 12:09:59 | miker_ | dbs: because they're different diffs now, you'd need to check the copy status |
| # | 12:10:30 | jeff | "always ignore running" "do not attempt to run" |
| # | 12:10:30 | dbs | atz - makes sense |
| # | 12:11:16 | miker_ | jeff: the logic there is that, for a title or metarecord hold, which are patron-placable, the flag is a pre-filtering thing |
| # | 12:11:19 | miker_ | but |
| # | 12:11:41 | miker_ | for vol/copy holds, which are staff-only (by default), it should be policy-overridable |
| # | 12:11:45 | dbs | also, in the notice templates, circ.circ_lib is confuzzling when an item is renewed at a library that is not the ac.circ_lib or acn.owning_lib |
| # | 12:11:59 | jamesrf has joined #evergreen |
| # | 12:13:13 | miker_ | dbs: if CircIsOverdue checks for a stop_fines time, then you're good ... I don't recall, though, if it's looking for checkin_time instead |
| # | 12:13:15 | dbs | I guess circ.target_copy.circ_lib.name would be the way to fix that |
| # | 12:13:45 | dbs checks |
| # | 12:13:46 | jeff | miker_: that was what i thought. also, why we're not adding a copy.holdable check in the circ scripts, just having "shouldn't be holdable even by staff" things be identified in scripts more explicitly than setting holdable = false on the copy |
| # | 12:16:29 | jamesrf has quit IRC |
| # | 12:17:00 | jamesrf has joined #evergreen |
| # | 12:19:06 | dbs | miker_: it looks for a checkin_time and short circuits; then it looks for a stop_fines time where the reason is not MAXFINES or LONGOVERDUE and short circuits |
| # | 12:19:51 | dbs finally makes the connection between action_trigger.validator and O:A:Trigger::Validator |
| # | 12:20:20 | dbs | miker_: looks like a heck of a 1.6.0.4 release coming up :) |
| # | 12:20:35 | miker_ | bah |
| # | 12:23:42 | dbs | Hmm. I guess it would be a good idea to disable the generate_circ_notices.pl script if I enable the action_trigger_runner.pl script. And maybe copy action_trigger_runner.json.example into /openils/conf/ |
| # | 12:26:21 | moodaepo | dbs: so does action_trigger_runner.pl work on 1.6.0.x? I don't think I got it working :/ |
| # | 12:26:30 | miker_ | moodaepo: it does |
| # | 12:26:31 | dbs | ooh. and maybe add hold.available to the list of hooks. |
| # | 12:26:58 | dbs | moodaepo: haven't tried yet, but from what I'm reading in the code my guess is that you were missing /openils/conf/action_trigger_runner.json |
| # | 12:26:59 | moodaepo | moodapeo-- # must be something I'm not doing right...again! |
| # | 12:27:01 | miker_ | dbs: and fire that at capture time ... DO IT DO IT |
| # | 12:27:41 | moodaepo | dbs: I did copy over action_trigger_runner.json oh well I'll run through things from the top |
| # | 12:27:45 | miker_ | s/fire/batch-create-events/ |
| # | 12:27:49 | dbs | moodaepo: well, this isn't exactly documented so... |
| # | 12:29:52 | moodaepo thinks he should document a setting up crons-jobs section on the wiki |
| # | 12:30:57 | moodaepo | Having problems even after looking at atz and miker_ ('s) neat crontab example |
| # | 12:39:53 | atz | moodaepo: a/t still has a lot moving parts... |
| # | 12:39:55 | atz | ./action_trigger_runner.pl --run-pending --debug-stdout |
| # | 12:40:42 | moodaepo | atz++ # graci |
| # | 12:41:29 | dbs | miker_: I am ashamed to say that the action_trigger_runner.json example doesn't give me enough to grab onto (looks json_query-ish) to add a hold.available hook (if that's even the right thing to do) |
| # | 12:43:05 | atz | dbs: I just put {} in the .json file |
| # | 12:43:14 | dbs | heh |
| # | 12:44:13 | dbs | when would you --process-hooks, vs not? |
| # | 13:08:41 | miker_ | dbs: when you just want to create events, but not fire them |
| # | 13:09:39 | dbs | So it's like you're pulling back the firing pin, but not the trigger |
| # | 13:10:00 | miker_ | right. a later --run-pending will fire the events |
| # | 13:11:35 | dbs | So a concrete case would be processing the hold.available every hour, but only firing it (to send the emails) every four hours? |
| # | 13:15:06 | miker_ | dbs: well, the delay time will prevent premature firing, but, yeah, that would be a case |
| # | 13:15:28 | dbs | Huh, something funky in the dojo date logic; '2010-05-01 00:00:00-04' displays as '2010-04-30' in My Account; '2010-05-15 23:59:59-04' displays as 'May 15, 2010 11:53:19 PM' in the copy details due date in the staff client OPAC |
| # | 13:15:45 | miker_ | or, queuing up phone notifications during off hours, and firing them during biz hours |
| # | 13:15:58 | dbs | miker_: thanks - that's a perfect use case |
| # | 13:16:36 | dbs | at some point this will all get written up to explainify stuff to people :) |
| # | 13:16:43 | miker_ | dbs: sounds like dojo thinks your computer is in UTC |
| # | 13:17:09 | miker_ | dbs: that some point is ... it's in progress (at least for notifications) :) |
| # | 13:17:23 | dbs | OHREALLY? |
| # | 13:17:24 | dbs | :) |
| # | 13:18:53 | dbs | I was thinking it just might be the result of converting a timestamp to microseconds since the epoch and back to a date shaving a few minutes off, and pushing the 00:00:00-04 time back to the previous day |
| # | 13:20:37 | dbs peeks at http://bugs.dojotoolkit.org/ticket/9028 |
| # | 13:21:42 | dbs | what are the chances we're passing something like -0400 instead of -04:00... /me goes into alert() mode |
| # | 13:23:50 | dbs | duration = parseInt(duration + '000'); |
| # | 13:25:19 | dbs | weird, we're calculating the due date in javascript instead of just taking it directly from the circ? |
| # | 13:27:18 | dbs | oh, non-cat circ. duh |
| # | 13:28:41 | miker_ | for the copy details issue, that's /definitely/ the dojo-strictness issue ... -0400 vs -04:00 |
| # | 13:29:36 | dbs | I bet it's the same for both. |
| # | 13:29:58 | miker_ | could be, yeah |
| # | 13:34:39 | dbs | I'll shove a fix into for _trimTime, at least - check for "T[+-]\d\d\d" and shove in a : at the appropriate point |
| # | 13:35:27 | dbs | Mind you, I'm not even sure we want to _trimTime if the duration is < 1 day... but that can wait |
| # | 13:36:09 | jenny has quit IRC |
| # | 13:36:22 | dbs | err, T\d\d:\d\d:\d\d[+-]\d\d\d |
| # | 13:37:23 | jamesrf has left #evergreen |
| # | 13:38:49 | miker_ | dbs: do you want to try shoving this in somewhere after dojo is loaded, but before dojo.date is used? -> dojo.date.stamp._isoRegExp=/^(?:(\d{4})(?:-(\d{2})(?:-(\d{2}))?)?)?(?:T(\d{2}):(\d{2})(?::(\d{2})(.\d+)?)?((?:[+-](\d{2}):?(\d{2}))|Z)?)?$/;dojo.date.stamp._isoRegExp=/^(?:(\d{4})(?:-(\d{2})(?:-(\d{2}))?)?)?(?:T(\d{2}):(\d{2})(?::(\d{2})(.\d+)?)?((?:[+-](\d{2}):?(\d{2}))|Z)?)?$/; |
| # | 13:39:04 | dbs | miker_: Not really :) |
| # | 13:39:06 | dbs | heh |
| # | 13:39:09 | miker_ | ah |
| # | 13:39:11 | miker_ | er |
| # | 13:39:12 | miker_ | ha |
| # | 13:39:21 | miker_ | well, it just makes the last : optional |
| # | 13:39:26 | dbs | I understand :) |
| # | 13:40:34 | miker_ | if it works, we can stick it in DojoSRF |
| # | 13:45:10 | jenny has joined #evergreen |
| # | 13:45:43 | atz | what a fugly regexp |
| # | 13:47:13 | pmplett has quit IRC |
| # | 13:47:51 | dbs is tempted to go with time.replace(/(T\d\d:\d\d:\d\d)([+-]\d\d)(\d)/, "$1$2:$3") as something understandable :) |
| # | 13:48:14 | dbs | I'll give it a shot, though. |
| # | 13:49:50 | atz | I certainly have written my share of date-parsing RE's, most just about as fugly |
| # | 13:50:33 | dbs | Interesting. Shoving it into js_common.xml doesn't seem to work |
| # | 13:50:56 | dbs | 2006-03-02T00:00:00-0500 still gets converted into 2006-03-01 by _trimTime() |
| # | 13:51:46 | dbs | my simpleton approach works, but it would have to be shoved in at point of use every time |
| # | 13:52:21 | miker_ | WELCOME, CLEANSE_ISO(), TO THE WORLD OF JS! |
| # | 13:52:51 | dbs | hah |
| # | 13:53:19 | miker_ | I suppose we could teach cstore to reformat dates |
| # | 13:53:21 | miker_ | :( |
| # | 13:54:03 | miker_ | too bad I followed the spec when I taught dbd-drivers (pg) how to do that |
| # | 13:55:38 | dbs | specifications-- |
| # | 13:55:42 | dbs | :) |
| # | 13:55:46 | dbs | dojo-- |
| # | 13:56:25 | miker_ | herasy! |
| # | 13:56:28 | miker_ | BURN THE WITCH |
| # | 13:56:38 | dbs feels nice and toasty |
| # | 13:56:45 | phasefx | what do you burn apart from witches? |
| # | 13:56:51 | dbs | MORE WITCHES! |
| # | 13:56:54 | atz | jquery? |
| # | 13:57:17 | atz | BURN! # |
| # | 13:57:25 | phasefx | google go and ncurses for all our UI |
| # | 13:58:14 | atz | you can throw IE6 in there too |
| # | 13:59:16 | dbs | miker_: short-term, how about I shove the simpleton fix into myopac.js and copy_details and take care of those issues in the OPAC, at least |
| # | 13:59:40 | miker_ | dbs: sounds good to me |
| # | 14:04:23 | dbs | phasefx: you added something about batch override of renewals recently, right? |
| # | 14:05:03 | phasefx | sounds familiar, lemme see |
| # | 14:06:54 | phasefx | I see renewal with specific dates |
| # | 14:07:39 | dbs | Something about renew all and not having to override every individual item when max_fines has been reached or whatever |
| # | 14:07:50 | dbs | not a biggie |
| # | 14:08:17 | phasefx | I know it's come up, but I don't recall making a solution |
| # | 14:08:43 | jeff | i haven't seen a patch for that, but better override handling would be great. |
| # | 14:09:07 | jeff | some events are patron-related, like max items on a patron who just brought back all their items but they haven't been checked in yet... |
| # | 14:09:13 | phasefx | one thought I had was a checkbox for the perm dialog that would effect an "operator change".. not quite the same thing |
| # | 14:09:35 | jeff | be nice to override all MAX_ITEMS_OUT for that 'checkout session' |
| # | 14:10:19 | phasefx | it'd be easy enough have an Override checkbox that just tacked .override onto the end of each call, but the problem would be ignorance of the events you're overriding |
| # | 14:10:25 | jeff | right |
| # | 14:10:39 | jeff | you wouldn't want to override copy-level events in most cases. |
| # | 14:10:58 | jeff | so distinction between "this event is because of the user" and "this event is because of the item"... etc. |
| # | 14:11:20 | jeff | common annoyance, not a simple fix, but not the world's most complex problem either. |
| # | 14:11:39 | phasefx | maybe you could teach the override dialog to auto-override selected events.. a checkbox next to each one.. but then for how long? until the next patron is loaded? |
| # | 14:12:30 | jeff | typically, yes. |
| # | 14:13:43 | jeff | the system doesn't currently know patron events from copy events, but if it were taught... then it could offer the "ignore/override this event" for the rest of that "checkout session" |
| # | 14:14:03 | jeff | where "checkout session" ends when you bring up a new patron |
| # | 14:14:41 | phasefx | we could add fields to the overridable event list for a given call, and have opt-out logic look for those |
| # | 14:14:48 | jeff | offering it on copy-related events wouldn't give much gain, and would be more dangerous. |
| # | 14:15:45 | jeff | if the client knew "these events are common patron-related events during checkout", and if it gets one, it offers to ignore all of the same patron-related event until end of checkout session... |
| # | 14:17:45 | phasefx | sounds sane to me |
| # | 14:18:34 | dbs | ah, forgot that the default EG skin doesn't publicly display due dates or times - no changes required there |
| # | 14:28:29 | dbs | Oh, hot damn. SIP 3.0 is on its way |
| # | 14:28:52 | jeff | SIP-3: We Don't Need No Steenkin' NCIP? |
| # | 14:29:01 | atz | dbs: srsly? |
| # | 14:29:01 | dbs | "The version 3.0 protocol is intended to address the needs that are currently being met with extensions, and other needs not currently supported by the SIP 2.0 protocol" |
| # | 14:29:07 | atz | word |
| # | 14:29:48 | atz | maybe they'll at least recommend a *secure transport layer* this time. |
| # | 14:30:18 | jeff | ``We look forward to participation and support from all vested parties in making this a reality.'' aka "come on now guys, don't screw this up!" |
| # | 14:31:32 | dbs | SSH tunneling FTW! They should be able to bundle that into their devices, and then evil greedy ILS vendors can charge for "secure SIP" modules. |
| # | 14:31:57 | dbs | "3M will be inviting the vendor community and libraries to provide input for version 3.0." |
| # | 14:32:25 | atz | link? |
| # | 14:32:52 | phasefx | that is a link |
| # | 14:33:01 | phasefx | you need to use your google link resolver |
| # | 14:33:35 | phasefx | mine redirects to http://www.mickfortune.com/Wordpress/?p=222 |
| # | 14:33:39 | dbs | No link, forwarded to me by a sales rep who likes me |
| # | 14:33:49 | atz | http://www.google.com/search?rlz=1C1GGLS_enUS357US362&sourceid=chrome&ie=UTF-8&q=%223M+will+be+inviting+the+vendor+community+and+libraries+to+provide+input+for+version+3.0.%22 |
| # | 14:45:58 | jeff | http://listsmart.osl.state.or.us/mailman/private/rfid_lib/2010-March/000342.html is the original, but you need to be subscribed and logged in |
| # | 15:00:24 | bshum | Our postgres database is set using UTC-5 as its timezone, but occasionally I'm seeing datestamps in our system that refer to UTC-4 ; right now I'm perusing a sample set of circulations and looking at due-dates. Any reason this timezone difference might be appearing? |
| # | 15:01:01 | bshum | Or is that normal? |
| # | 15:01:37 | dbs | bshum: fwiw, I get that too; hadn't tracked it down yet because I assumed time changes but you're too new for that to be the case |
| # | 15:02:17 | bshum | bshum: Right, we've only got 300 circulations in our live database, but a bunch of them are split between -05 and -04 |
| # | 15:02:26 | bshum | Whoops, meant that to say dbs: |
| # | 15:03:19 | bshum | I know initially we had to restart our database to use a new timezone setting, since we had all our timestamps show up as +00, indicating our database server was set using UTC as its timezone. |
| # | 15:03:35 | bshum | But a lot of recent transactions are -04 |
| # | 15:03:38 | bshum | Instead of -05 |
| # | 15:04:49 | grantjohnson has quit IRC |
| # | 15:06:48 | bshum | There's something in the checkout process that sets the time stamp to 00:00:00 or 23:59:59 right? |
| # | 15:06:54 | bshum | But how does it know the difference |
| # | 15:07:16 | dbs | There's a trigger that pushes the time to 23:59:59 |
| # | 15:08:05 | bshum | Ah |
| # | 15:08:26 | bshum | But apparently not for everything |
| # | 15:08:34 | bshum | If I'm still seeing 00:00:00 in a lot of places |
| # | 15:09:55 | dbs | If the interval is exactly divisible by 1 day, then it should get pushed |
| # | 15:10:14 | bshum | Ah |
| # | 15:10:16 | dbs | see the function action.push_circ_due_time() |
| # | 15:10:38 | bshum | So maybe those 00:00:00 are set somehow by other means |
| # | 15:10:42 | bshum | Like hard-coded date entries? |
| # | 15:10:57 | bshum | Erm, where the staff edited the due date |
| # | 15:11:03 | bshum | Putting a new one in |
| # | 15:11:23 | dbs | Makes sense. The trigger is a BEFORE INSERT trigger, so it wouldn't touch those. |
| # | 15:12:31 | bshum | That would explain why we have such a varied mix then. |
| # | 15:12:37 | miker_ | bshum: that's backdating |
| # | 15:12:46 | miker_ | the 00:00:00 is, I mean |
| # | 15:12:54 | bshum | miker_: Oh, okay |
| # | 15:13:05 | miker_ | well, or editing, you're right |
| # | 15:13:06 | miker_ | sorry |
| # | 15:13:23 | bshum | Still makes some sense though, there were situations where our library staff were editing due dates by hand because they thought the items weren't following the right circ rules. |
| # | 15:13:38 | miker_ | I've been squashing xact_start and checkin_time issues this week |
| # | 15:14:36 | miker_ | anyway, yeah, 00:00:00 is from human intervention |
| # | 15:14:48 | bshum | That's good to confirm. Makes us feel alot easier about it. |
| # | 15:14:53 | bshum | Though the timezone thing is still quite weird. |
| # | 15:15:34 | miker_ | as for timezone, if your locale uses DST, you should set it via the most generic name |
| # | 15:15:53 | miker_ | for US Eastern, use "America/New_York" (IIRC) |
| # | 15:17:02 | dbs | miker_: that's what our servers are set to |
| # | 15:17:13 | miker_ | if the time on your db server, or app server is separate, has been updated (or the ZIC db, or the TZ) then you could see what you're seeing |
| # | 15:18:54 | bshum | Our server is configured using "America/New_York" in the /etc/timezone and I reconfigured our tzdata package to do that. |
| # | 15:19:06 | bshum | Then restarted the postgres database to make use of that variable. |
| # | 15:19:18 | bshum | Since it's all on the same server. |
| # | 15:20:34 | bshum | What I'm seeing is two sets of time stamps actually |
| # | 15:20:41 | bshum | One for 18:59:59-05 |
| # | 15:20:48 | bshum | And one for 19:59:59-04 |
| # | 15:21:15 | jeff | oh happy day. checkin_handle_backdate is here to answer all my questions! |
| # | 15:21:22 | r123 has quit IRC |
| # | 15:21:26 | bshum | And of course, 19:00:00-05 and 20:00:00-04 |
| # | 15:22:32 | bshum | And 00:00:00-05 |
| # | 15:22:57 | dbs | SHOW timezone; says "localtime" |
| # | 15:23:41 | bshum | Mine says "TimeZone" |
| # | 15:24:37 | dbs | Uh, "TimeZone" would be the column header |
| # | 15:24:52 | bshum | Oh whoops |
| # | 15:24:57 | jeff grins |
| # | 15:25:04 | phasefx | TwilightZone |
| # | 15:25:15 | bshum | Yes, mine also says "localtime" |
| # | 15:25:19 | phasefx | column beheaders |
| # | 15:25:27 | bshum | dbs: Clearly I need to spend more time in psql land :( |
| # | 15:30:07 | rjackson-isl has quit IRC |
| # | 15:31:29 | _bott_ has joined #evergreen |
| # | 15:32:09 | bshum | Well, at least this only seems to occur in the due date timestamps so far |
| # | 15:45:00 | BobW has joined #evergreen |
| # | 15:48:19 | dbwells | bshum: about differing time zones offsets, I thought I had seen this whenever the due date falls beyond the DST switch date. That is, something checked out while the date is in standard time but the due date is in daylight time (or vice versa) will have this anomaly. Could be remembering wrong, though. |
| # | 15:49:53 | dbs | I guess the question is, if that is the case, is it even an anomaly? |
| # | 15:51:17 | dbwells | right, it is an anomaly in that case only as much as our changing time system itself |
| # | 15:54:45 | dbwells | We have a sync script which brings in our patron data, including birthdates. Since I didn't have the birth times, I let it default to midnight. Suddenly those born during DST were having their birthdate set to 11:00pm the day before :) |
| # | 15:54:58 | dbs | heh |
| # | 15:57:08 | dbwells | And why do suddenly have a Chicago song in my head? |
| # | 15:57:32 | dbwells | On another topic... |
| # | 15:58:31 | dbwells | I am trying to pick my poison for working up some serials interfaces. It seems that later additions to EG are using Dojo-based interfaces rather than XUL. Is that recommended? |
| # | 15:58:35 | bshum | dbwells: Oh neat, we'll just keep an eye on it just in case, but not worry about it incessantly now. Thanks, hopefully it's that simple. |
| # | 15:59:20 | dbs | dbwells: if you feel comfortable with Dojo, yes |
| # | 16:00:51 | Meliss has quit IRC |
| # | 16:01:08 | dbwells | Well, I am not exactly comfortable with either yet. I like Dojo /in theory/, but with my experience in the client, the XUL interfaces are rock solid while the newer Dojo stuff is fragile and slow. I bet some of that is simple maturity, but how much? |
| # | 16:03:50 | dbs | dbwells: I can't argue with that |
| # | 16:04:11 | dbs | (although "rock solid" might be giving too much credit to XUL... heh) |
| # | 16:04:58 | dbs | phasefx: "document.getElementById("csp_" + csp_id) is null" when removing a standing penalty from a patron account - known problem? |
| # | 16:07:51 | dbwells | I suppose by "rock solid" I simply mean "predictable" |
| # | 16:08:48 | dbs | var csp_id = typeof penalty.standing_penalty() == 'object' ? penalty.standing_penalty().id() : penalty.standing_penalty(); |
| # | 16:09:02 | dbs | NEWLINES COST YOU NOTHING! |
| # | 16:09:53 | dbwells | For instance, the 'Circulation Modifier' screen sometimes works, sometimes doesn't (loads part way, says [object Object], etc.). Haven't had time to try an figure out why, but it worries me. |
| # | 16:13:38 | dbs | I think that's part of the area that miker_ has been focusing on recently |
| # | 16:16:48 | dbwells | Will no one here come to the defense of Dojo? :) |
| # | 16:18:12 | jeff | i can't come to the defense of dojo until i've signed and faxed back my Individual CLA ;-) |
| # | 16:20:09 | dbwells | Well, I'll be heading out soon but will keep the channel open if anyone wants to weigh in. At this point I am leaning toward taking a swing with XUL, but that is based more on my end-user experience than anything else. |
| # | 16:20:54 | dbwells | Obviously I don't want to go that direction if it will be frowned upon by the masters. |
| # | 16:22:23 | dbs | Ahh... I think the problem may be that the target node with ID=csp_id only gets created if csp_id > 100 - and all of our standing penalties are system types, so < 100 |
| # | 16:22:39 | dbs | If I read line 61 of standing_penalties.js correctly |
| # | 16:23:35 | dbs swings and misses |
| # | 16:23:37 | dbs | meh |
| # | 16:24:53 | dbs | nope, that was it |
| # | 16:32:50 | _bott_ | I can't defend Dojo outright, but have been spending some quality time with it for an unrelated project and it does have a lot of tricks up its sleeve |
| # | 16:33:49 | dbs | I quite like the dojo API and features. The flakiness of the Grid is probably the biggest strike against it. |
| # | 16:34:07 | dbs | Apparently that's much better in 1.4. Promises promises, Dojo! |
| # | 16:38:31 | dbs | wow. standing_penalties.js is entirely different in trunk |
| # | 16:39:12 | jeff | dbs: yeah, there was a bunch of standing penalty work after 1.6 -- i remember marking it to look-more-later |
| # | 16:40:21 | dbs | From the brief look I just had, it appears to be much cleaner code |
| # | 16:40:59 | dbs | woohoo! down to 99 open tickets (not open with Equinox, just internal things). I can live with that |
| # | 16:48:24 | gdunbar has quit IRC |
| # | 16:50:19 | dbs | later folks |
| # | 16:50:24 | dbs has quit IRC |
| # | 16:53:13 | StephenGWills has left #evergreen |
| # | 16:57:35 | jenny has left #evergreen |
| # | 17:09:18 | bshum has quit IRC |
| # | 17:10:09 | BobW has quit IRC |
| # | 17:12:30 | phasefx | :q |
| # | 17:12:52 | phasefx | now, is that an emoticon or a vim command in the wrong window.. hrmmm |
| # | 17:16:02 | dbwells | I'm guessing the second. :) Now my problem is constantly hitting escape when I am done typing, regardless of the program I am in. |
| # | 17:16:27 | pmplett has joined #evergreen |
| # | 17:18:46 | lisppaste3 has quit IRC |
| # | 17:27:24 | lisppaste3 has joined #evergreen |
| # | 17:29:58 | sfortin has quit IRC |
| # | 17:39:01 | leed has quit IRC |
| # | 17:40:51 | jamesrf has joined #evergreen |
| # | 18:16:39 | Dmagick-mac has quit IRC |
| # | 18:57:05 | phase_bb has quit IRC |
| # | 19:33:03 | moodaepo has quit IRC |
| # | 20:49:44 | pmplett has quit IRC |
| # | 21:00:15 | mck9 has left #evergreen |
| # | 23:19:17 | rsinger has quit IRC |
April 10-13