← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
08:17 | kados | hey owen-away |
08:18 | owen | Hi kados |
08:18 | I've been wrestling IE this morning | |
08:18 | kados | owen: I just happened to have a question for you :-) |
08:18 | sweet | |
08:18 | owen | You first |
08:18 | kados | on 101, it doesn't look like the patron expiry stuff is working |
08:18 | http://66.213.78.101:8082/cgi-[…]rc/circulation.pl | |
08:19 | expiry date for that guy is 03/09/2005 | |
08:19 | but I don't see the warning or the override button we developed | |
08:20 | owen | What's the card number? |
08:21 | kados | Charles W. Smith Jr (0022478) |
08:21 | huh ... my account seems to be working ok | |
08:22 | owen | Yeah, mine too--even if I set the expiration to the very same date |
08:22 | kados | weird that Charles account isn't working ... |
08:25 | ok ... well nevermind | |
08:25 | how's the IE battle going? | |
08:26 | owen | Well first: it doesn't look like the renewal process is happening correctly |
08:27 | kados | yea, I know |
08:27 | owen | Oh, okay |
08:27 | kados | I'm re-hauling the whole thing |
08:27 | in the middle of re-hauling that is | |
08:27 | owen | Do do love to re-haul ;) |
08:27 | kados | :-) |
08:27 | owen | Okay, anyway: IE |
08:27 | IE kicked my ass | |
08:28 | kados | my preference is already well-written code, but we seem to be short on that |
08:28 | wow | |
08:28 | owen | IE is really obstinate about tables |
08:28 | kados | did you try using the all forgiving !important ? |
08:28 | owen | I think it's a combination of factors on that particular site, including lots of title with really big words |
08:29 | ...which is why the same problem doesn't happen when I test with NPL's data :D | |
08:29 | kados | ahh, right |
08:31 | (what did you notice about renewals, and was it on dev-week or rel_2_2? | |
08:32 | owen | On rel_2_2: I set my expiration back a long time and then renewed. It just incremented the old expiration date by however many years, rather than making it renew to however many years from this year |
08:32 | kados | ahh, ok |
08:32 | I thought you mean renewal of items | |
08:32 | ok, that's easy to fix | |
08:32 | I"ll add it to the list | |
08:33 | other than that, we're OK with how expiring patrons are handled now? | |
08:33 | owen | Yeah, I think so. |
08:33 | kados | sweet |
08:34 | owen | I had the idea to add a button to the member edit screen that would auto-renew the value in the expiry field using javascript, but I never had time to work on it |
08:35 | The page says "leave blank for auto calc" but I don't think it works for editing, just when adding | |
08:35 | kados | ahh ... |
08:35 | that could be handled it he script too | |
08:35 | in the script even | |
08:36 | well, we can prolly wait on that one | |
08:37 | owen | Yeah, that's not a big deal |
08:38 | One idea I had for IE... We could just drop the nav for that page, either once and for all in the template, or using a conditional comment that would target IE | |
08:38 | kados | for the results page you mean? |
08:38 | owen | yeah |
08:38 | kados | hmmm ... |
08:38 | not sure current clients would approve | |
08:39 | owen | It's gotta be the contents of the table that causes the problem, because not all searches produce the problem |
08:39 | kados | right |
08:39 | very strange | |
08:39 | IE-- | |
08:40 | what about doing a fixed-width? | |
08:40 | like in dev-week ... would that fix it? | |
08:43 | owen | I think the horizontal layout of the search results would probably be a solution |
08:43 | We could also alleviate the problem by dropping the copies column or consolidating some other column | |
08:44 | kados | hmmm |
08:44 | I guess I'll need to discuss this with Ryan | |
08:44 | I'll have to get back to you | |
08:45 | owen | Okay. Sorry I don't have a better answer. |
08:45 | kados | not sure if any of our clients would object to a non-tabular results page or not ... |
08:45 | I suspect not, but better make sure | |
08:45 | that's fine, thanks for checking | |
08:45 | owen | The option of consolidating the current columns would be an incremental step that would probably take care of the problem in most cases |
08:50 | kados | so would this mean the display would look pretty much like dev_week's results? |
09:08 | owen | The more incremental option would be to just drop one or two columns in the table-style display. Move or drop the copy count, for instance |
09:09 | kados | ahh, ok |
09:10 | callnumber is replicated in availability too | |
09:10 | owen | If we moved to the dev_week layout we'd have to reformat the availability/locations data again |
09:10 | kados | right |
09:10 | ok, we'll go ahead and test just removing the count column | |
09:10 | owen | ...or leave that in its own column still... |
09:11 | kados | is there anything that our AV count does that Koha's restrictions based on itemtype can't do? |
09:11 | (I realize we had this discussion before, I just can't remember the outcome) | |
09:12 | I am thinking of moving the itemtypes in NPL's data to a different location and creating 'collection codes' in the itemtype field | |
09:12 | based on the mapping you put together | |
09:12 | then assigning circ rules based on those | |
09:16 | owen | Our AV count groups itemtypes together to arrive at its count |
09:16 | So if Koha can do that, then great | |
09:17 | kados | yea, that's what I'm planning |
09:17 | owen | As long as we retain the ability to get very specific searches based on format... DVD only, CD book only, etc. |
09:18 | kados | yea, I won't actually touch the existing itemtypes |
09:18 | just create a new place to store the group | |
09:18 | so we have: | |
09:18 | AV-VID | |
09:18 | AV-MUS | |
09:18 | AV-BKT | |
09:19 | CIRC | |
09:19 | NOCIRC | |
09:19 | those codes make sense to you? | |
09:19 | owen | Yes |
10:01 | osmoze | bye all |
← Previous day | Today | Next day → | Search | Index