| # | Time | Nick | Message |
|---|
| # | 00:32:59 | dbs has quit IRC |
| # | 06:02:05 | gmcharlt has quit IRC |
| # | 07:03:04 | sfortin has joined #evergreen |
| # | 07:58:01 | mck9 has joined #evergreen |
| # | 08:36:34 | gdunbar has joined #evergreen |
| # | 08:54:52 | sfortin has quit IRC |
| # | 09:11:31 | jenny has joined #evergreen |
| # | 09:36:38 | sfortin has joined #evergreen |
| # | 09:45:00 | rsinger has joined #evergreen |
| # | 10:14:36 | StephenGWills has joined #evergreen |
| # | 10:16:23 | StephenGWills | in a consortium made up of single branch systems, is there any reason to create a sys ou_type? any problem with the branch's parent being the consortium? |
| # | 10:17:30 | brendan_bywater has quit IRC |
| # | 10:32:24 | atz has quit IRC |
| # | 10:35:46 | atz has joined #evergreen |
| # | 10:47:10 | brendan_bywater has joined #evergreen |
| # | 10:51:23 | miker_ | StephenGWills: none at all. just make sure you adjust the ou type depth |
| # | 10:52:36 | jeff | Hrm. Are there known issues with simple record extracts not being updated after record merge? Or, does anyone remember any from the past? |
| # | 10:53:52 | miker_ | jeff: record merges don't change the marc, so there's nothing to update ... if I understand what you mean |
| # | 11:05:14 | jeff | miker_: symptom is that i have a record id that shows one thing in the reporter's simple record extract for Title (Normalized), while viewing that same record ID in the staff client shows something else. It's likely that a merge happened at one point, or perhaps an overlay. |
| # | 11:05:35 | jeff | Just trying to see if I should dig further, or if it's a symptom of an old bug long fixed. |
| # | 11:06:07 | jeff | (i phrased my original inquiry poorly) |
| # | 11:13:34 | miker_ | the one think I can think of is that the summary-generating trigger was turned off (for an import, say) and then turned back on, but the summary table was not regenerated. there are stored procs to manage all that, but for manual imports they have to be called manually (or, not at all, in which case the import will be slower but the trigger will be there and do it's thing) |
| # | 11:13:39 | miker_ | its |
| # | 11:26:13 | mck9 has quit IRC |
| # | 11:47:12 | dbs has joined #evergreen |
| # | 11:48:40 | jeff | dbs++ |
| # | 11:48:43 | jeff | instrumentation++ |
| # | 11:49:44 | dbs | jeff: Oh, I can talk. Do, that's another matter. |
| # | 12:04:42 | gmcharlt has joined #evergreen |
| # | 12:25:22 | dbs | augh, damnit |
| # | 12:26:06 | dbs | somehow ENTITY staff.auth.about_btn.accesskey in lang.dtd got turned into the PO-file metadata in all of the translated lang.dtds ARGH |
| # | 12:27:55 | jamesrf has joined #evergreen |
| # | 12:28:21 | dbs | and that crashes the client in any language other than en-US immediately on startup |
| # | 12:28:53 | jeff | well, ouch. |
| # | 12:28:56 | mck9 has joined #evergreen |
| # | 12:31:32 | dbs | meh. it's in the PO as generated by launchpad, I think |
| # | 12:32:25 | dbs | simple enough to fix, but it will require a repackaging of the 1.6.0.1 staff client |
| # | 12:32:30 | dbs | phasefx? |
| # | 12:34:22 | phasefx is happy to package a new client as needed |
| # | 12:34:41 | phasefx | just hand me a build.tar |
| # | 12:34:46 | dbs | phasefx: will do, sir |
| # | 12:35:07 | phasefx | dbs++ |
| # | 12:35:16 | dbs | it's just one string that needs changing in all locales (for now, I'll have to figure out how to fix it for reals later) |
| # | 12:35:27 | dbs | and... we should advertise for a translation manager :) |
| # | 12:38:44 | dbs | amusingly, I think pt-BR would work (for all 10 of the strings they've translated) |
| # | 12:45:10 | dbs | phasefx: http://open-ils.org/~denials/rel_1_6_0_1_locale.tar in about 1 minutes |
| # | 12:47:54 | dbs | phasefx: okay, it's there |
| # | 12:48:40 | dbs | on top of a translation manager, QA would be nice. I'm obviously not an exemplar. |
| # | 12:51:00 | phasefx | want me to put some text change in the installer at least to let folks know this isn't the originally packaged 1.6.0.1? |
| # | 12:51:32 | dbs | Probably a good idea |
| # | 12:51:54 | dbs | at some point I'm sure people are going to want to select which locales they're installing, too. we can worry about that in FutureWorld though :) |
| # | 12:58:16 | phasefx | dbs: should be up now. any virus checking appreciated :) |
| # | 12:59:42 | dbs | phasefx__ |
| # | 12:59:48 | dbs | phasefx++ #rather |
| # | 13:04:29 | dbs | yay, 2nd cut is working here |
| # | 13:36:46 | dbwells | Is anybody here using grace periods for overdue fine generation? They are not working for us, and I think I have spotted a fundamental bug, but would like to know if our setup is unique in this case. |
| # | 13:38:12 | miker_ | dbwells: most people are using grace periods, yes. may want to record your analysis on -dev |
| # | 13:42:38 | dbwells | miker_: thanks. That is so peculiar, though, because from what I see this, bug should affect anyone using grace periods. In your experience, are grace periods usually short (like one day) or long (like one week)? |
| # | 13:50:24 | dbwells | I guess I should say 'like one fine interval' or 'like 7 fine intervals'. I'll send something to the list for others to check out. Thanks again. |
| # | 14:02:58 | dbwells | miker_: nevermind, it looks like the bug got fixed here http://svn.open-ils.org/trac/ILS/changeset/15367/branches/rel_1_6/Open-ILS/src/perlmods/OpenILS/Application/Storage/Publisher/action.pm |
| # | 14:04:26 | dbwells | The old line 737 effectively caused a new grace period after every fine, but the new code makes sure this is only for the first fine. |
| # | 14:06:35 | miker_ | dbwells: that's in 1.6.0.1 |
| # | 14:07:05 | miker_ | well, that and some followup fixes |
| # | 14:07:55 | phasefx is going to alphabetize those entries in the admin menus.. been driving him nuts :) |
| # | 14:08:37 | phasefx | assuming en-US ;) |
| # | 14:08:45 | dbwells | miker_: Unfortunately I am very hesitant to upgrade being so new to the system :S This might push me over! |
| # | 14:09:07 | miker_ | dbwells: if you're on 1.6.0.0, please PLEASE upgrade to 1.6.0.1 |
| # | 14:09:15 | miker_ | there are lots of bug fixes |
| # | 14:10:56 | dbwells | miker_: even so, it still works great 99.9% of the time, and a buggy system sure beats a broken one. Then again, I guess that is what test machines are for. |
| # | 14:14:18 | jamesrf has quit IRC |
| # | 14:15:39 | miker_ | dbwells: you can keep your old /openils around, and the db updates are immaterial to the code, so rolling back would be as simple as restoring the previous /openils |
| # | 14:16:56 | miker_ | and the changeset you referenced is not the only one you'll need (and the one from the 1.6 branch, as opposed to the 1.6.0 branch, won't even work in 1.6.0.x), so you may want to drop in action.pm from 1.6.0.1 if you don't upgrade completely |
| # | 14:19:21 | dbs | heh, our 1.5.9 grace periods were making our circ staff very angry because they don't want to give a one-day grace period on multi-day loans - anyways, time to do some house work (insulation installation FTW!) |
| # | 14:36:37 | dbwells | miker_: this is great info to know, thanks! |
| # | 14:40:46 | dbwells | while I'm at it, for clarification on the way these branches are setup, 1.6.0 is the branch that all 1.6.0.x releases are derived from, while 1.6 will eventually be branched into 1.6.1.x, 1.6.2.x, etc? |
| # | 14:40:59 | dbwells | basic question :) |
| # | 14:51:33 | miker_ | dbwells: exactly right |
| # | 14:52:46 | miker_ | and, more generally, it's {version}.{major-revision}.{minor-revision}.{bug-fix-patch-release} (more or less) |
| # | 14:54:49 | miker_ | complete rewrites allowed at the {version} level, major schema changes of existing db elements allowed at {major-revision}, minor db changes and most db additions allowed at {minor-revision} and bug-fix-only db changes allowed at {bug-fix-patch-release} ... again, more or less. and you can extrapolate user-level features from those db-level rules |
| # | 14:56:14 | miker_ | or, that's the idea ... there are those **cough**dbs**cough** who would like to move to a 3-level release numbering scheme ... there are plusses and minuses to each approach |
| # | 15:50:49 | jeff | argh. 1.4 staff client on linux with xulrunner 1.9.0.17 seems to have some kind of focus bug. Don't know where to blame yet. |
| # | 15:51:22 | jeff | triggering fancy_prompt.xul (say, scan an invalid barcode into item status) can't be dismissed. You just can't say OK via mouse or keyboard. |
| # | 15:58:23 | dbs hands miker_ a hankie |
| # | 16:11:08 | sfortin has quit IRC |
| # | 16:18:39 | jamesrf has joined #evergreen |
| # | 16:41:21 | phasefx | random exception on startup from nsICacheService.evitcEntries |
| # | 17:14:43 | jenny has left #evergreen |
| # | 17:20:05 | bshum has joined #evergreen |
| # | 17:23:26 | bshum has quit IRC |
| # | 17:38:43 | brendan_bywater has quit IRC |
| # | 17:43:21 | bshum has joined #evergreen |
| # | 18:07:26 | brendan_bywater has joined #evergreen |
| # | 18:55:32 | gmcharlt has quit IRC |
| # | 20:56:32 | jamesrf has quit IRC |
| # | 21:21:12 | pmplett has joined #evergreen |
| # | 21:24:18 | jamesrf has joined #evergreen |
| # | 21:36:30 | gmcharlt has joined #evergreen |
| # | 22:53:35 | moberley has quit IRC |
| # | 22:55:19 | moberley has joined #evergreen |
April 10-13