IRC log for #koha, 2006-02-06

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
13:14 kados hey owen
13:14 owen Hi
13:14 Did you get my message?
13:14 kados yep
13:14 just replied
13:15 owen I think the Perl conversion of that PHP script is a must
13:15 Have you looked at the reserves script that paul added recently?
13:16 kados no
13:16 do you happen to know where it is?
13:17 owen I think it's under circ...
13:17 http://kohatest.wlpl.org/cgi-b[…]a/circ/reserve.pl, for instance
13:17 kados no docs for it
13:18 wow, that's not bad
13:18 owen It's pretty minimal...no date specifications, as far as I know
13:18 kados meaning you can't specify _when_ you want to search?
13:18 owen The big blank for me is how Stephen's script picks what goes into the list as we use it
13:19 I don't think a reserves script is doing you any good if you can't pick the branch, for instance
13:19 kados you mean the hourly list generator?
13:19 owen yeah
13:19 kados my guess is we could modify paul's script to allow sorting by branch
13:20 would that do it?
13:20 really, we need to re-write reserves
13:20 to allow item-level reserves to be placed
13:20 so this whole discussion might be moot
13:20 owen No... because I see that if there's more than one person on the reserve list, they both show up
13:20 kados :(
13:20 owen "No" to would that do it
13:21 kados hmmm
13:21 shouldn't more than one person show up?
13:21 not sure I understand
13:21 owen No, because what you want is basically a "pull list."  What items do you need to pull off the shelf that day.
13:22 So stuff has to be available, and at your branch
13:22 kados I see
13:22 owen There's no reason to show the *next* person on the list, because you're pulling it for the person first in line
13:22 kados right, this is the classic multi-vs-single branch problem
13:22 owen Not that there isn't a place for such a reserve list display, it's just not the practical list that we need at NPL
13:23 kados right
13:23 well are there any shortcomings with NPL's current list?
13:23 anything that needs changing?
13:24 owen I would talk to Stephen about the question of whether things sometimes don't show up on the list when they should
13:24 I had a patron call The Plains yesterday because she was waiting for something for a long time
13:24 It was available in Athens, but they'd never pulled it
13:24 It might have been because it never showed up on their pull list
13:24 kados could be
13:25 I'll have to take a look at stephen's script
13:25 so all yours does is display what's in the table right?
13:25 no calculation per se
13:25 owen Right.
13:25 The calculations  could be done as part of the page, I suppose
13:25 Without creating a new table.
13:26 I don't know which is more efficient
13:26 kados its hard to say without looking at the queries
13:26 owen Stephen also runs a report that shows him long-unfulfilled reserves. But that's more relating to items which are long-overdue
13:26 kados right
13:26 I suspect those kinds of reports aren't that useful for a smaller collection
13:27 I think NBBC only has like three overdues :-)
13:27 owen :D
13:28 I like our reserve list a lot, because it's tailored exactly to what we need: it shows the title along with the barcode ( so you can confirm you've got the right copy)
13:28 kados yep
13:28 owen It's got the call number, and orders by call number
13:28 It shows the patron, which can be relevant if you see you're pulling for a staff member
13:28 kados right
13:28 yea, it seems to work well for NPL
13:29 owen And the date give you an idea of whether it's been sitting on the list for a long time
13:29 kados I'll take a look at what would be involved in doing it in perl
13:29 then we can just commit it and not deal with customizing every client
13:29 owen The phone number I don't think gets used much, because people usually scan the found item to get the relevant contact information
13:30 kados btw: I noticed that CVS npl doesn't use opac-bottom.inc
13:30 is there a reason for that?
13:30 owen No good reason.  Just that our design didn't require it.
13:30 We should definitely add it
13:30 kados ok ... I"ll do that right now
13:31 I also added a new system pref for 'opaccredits'
13:31 which is what I'm putting in opac-bottom.inc
13:31 owen I suppose you could add other stuff to opaccredits too... like footer navigation?
13:32 kados the more we move stuff to the database, the less complicated upgrades are
13:32 well ... opaccredits would be for site-specific stuff ... you could put footer navigation in the template
13:32 cause it won't change from client to client
13:33 owen It might if you wanted custom stuff like in the left-hand nav
13:33 kados true
13:33 yea, it's flexible enough to put anything in there
13:33 owen By the way, I'd change the opacnav system pref to use a textarea inpu instead of the 'free' option
13:33 inpu -> input
13:33 kados well, I had it as textarea at first
13:33 but for some reason, textareas are kinda displaying weirdly in my browser
13:34 owen Hm.
13:34 kados also, in the updatedatabase script, I can't find any instances of textarea
13:36 even ISBD is type 'free'
13:40 some of the scripts have a $Log section near the bottom
13:40 and when they are updated by CVS, the changes are saved there automatically
13:40 I wonder why the others don't have that
14:04 owen It's the separate display for serials details
14:05 http://templatelabsopac.liblim[…]iblionumber=39907
14:05 kados right
14:21 owen: for some reason, on the till reconciliation report, everything's showing up twice
14:21 and it's not distinguishing between 'yesterday' and 'today'
14:21 I'm gonna try with default
14:22 same deal with default
14:22 on templatelabs
14:26 owen That's another one I never mess with... I don't even know if I've ever tested it with relevant data
14:26 We need to create some kind of amalgam dataset that can be used for testing...something that includes *everything*
14:32 kados yep
14:32 I think the new liblime demo will be just that
14:32 that's the goal anyway
19:09 owen: intranetcolorstylesheet should be finished for rel_2_2
19:09 owen Great!
19:09 kados owen: it was more work than I thought!
19:10 so many scripts to add that variable to
19:10 and not always obvious where it should go :-)
19:10 http://kohatest.liblime.com is running stock cvs now
19:10 circ / liblime
19:11 owen Does there need to be a better way to set global variables in Koha scripts?
19:11 kados that'd be great
19:11 any ideas?
19:11 owen Don't look at me, I'm just an interface designer :)
19:12 kados :-)

← Previous day | Today | Next day → | Search | Index

koha1