← 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