Time |
S |
Nick |
Message |
13:14 |
|
kados |
hey owen |
13:14 |
|
owen |
Hi |
13:14 |
|
owen |
Did you get my message? |
13:14 |
|
kados |
yep |
13:14 |
|
kados |
just replied |
13:15 |
|
owen |
I think the Perl conversion of that PHP script is a must |
13:15 |
|
owen |
Have you looked at the reserves script that paul added recently? |
13:16 |
|
kados |
no |
13:16 |
|
kados |
do you happen to know where it is? |
13:17 |
|
owen |
I think it's under circ... |
13:17 |
|
owen |
http://kohatest.wlpl.org/cgi-b[…]a/circ/reserve.pl, for instance |
13:17 |
|
kados |
no docs for it |
13:18 |
|
kados |
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 |
|
owen |
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 |
|
kados |
would that do it? |
13:20 |
|
kados |
really, we need to re-write reserves |
13:20 |
|
kados |
to allow item-level reserves to be placed |
13:20 |
|
kados |
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 |
|
kados |
shouldn't more than one person show up? |
13:21 |
|
kados |
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 |
|
owen |
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 |
|
kados |
well are there any shortcomings with NPL's current list? |
13:23 |
|
kados |
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 |
|
owen |
I had a patron call The Plains yesterday because she was waiting for something for a long time |
13:24 |
|
owen |
It was available in Athens, but they'd never pulled it |
13:24 |
|
owen |
It might have been because it never showed up on their pull list |
13:24 |
|
kados |
could be |
13:25 |
|
kados |
I'll have to take a look at stephen's script |
13:25 |
|
kados |
so all yours does is display what's in the table right? |
13:25 |
|
kados |
no calculation per se |
13:25 |
|
owen |
Right. |
13:25 |
|
owen |
The calculations could be done as part of the page, I suppose |
13:25 |
|
owen |
Without creating a new table. |
13:26 |
|
owen |
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 |
|
kados |
I suspect those kinds of reports aren't that useful for a smaller collection |
13:27 |
|
kados |
I think NBBC only has like three overdues :-) |
13:27 |
|
owen |
:D |
13:28 |
|
owen |
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 |
|
owen |
It shows the patron, which can be relevant if you see you're pulling for a staff member |
13:28 |
|
kados |
right |
13:28 |
|
kados |
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 |
|
kados |
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 |
|
kados |
is there a reason for that? |
13:30 |
|
owen |
No good reason. Just that our design didn't require it. |
13:30 |
|
owen |
We should definitely add it |
13:30 |
|
kados |
ok ... I"ll do that right now |
13:31 |
|
kados |
I also added a new system pref for 'opaccredits' |
13:31 |
|
kados |
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 |
|
kados |
well ... opaccredits would be for site-specific stuff ... you could put footer navigation in the template |
13:32 |
|
kados |
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 |
|
kados |
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 |
|
owen |
inpu -> input |
13:33 |
|
kados |
well, I had it as textarea at first |
13:33 |
|
kados |
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 |
|
kados |
even ISBD is type 'free' |
13:40 |
|
kados |
some of the scripts have a $Log section near the bottom |
13:40 |
|
kados |
and when they are updated by CVS, the changes are saved there automatically |
13:40 |
|
kados |
I wonder why the others don't have that |
14:04 |
|
owen |
It's the separate display for serials details |
14:05 |
|
owen |
http://templatelabsopac.liblim[…]iblionumber=39907 |
14:05 |
|
kados |
right |
14:21 |
|
kados |
owen: for some reason, on the till reconciliation report, everything's showing up twice |
14:21 |
|
kados |
and it's not distinguishing between 'yesterday' and 'today' |
14:21 |
|
kados |
I'm gonna try with default |
14:22 |
|
kados |
same deal with default |
14:22 |
|
kados |
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 |
|
owen |
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 |
|
kados |
I think the new liblime demo will be just that |
14:32 |
|
kados |
that's the goal anyway |
19:09 |
|
kados |
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 |
|
kados |
so many scripts to add that variable to |
19:10 |
|
kados |
and not always obvious where it should go :-) |
19:10 |
|
kados |
http://kohatest.liblime.com is running stock cvs now |
19:10 |
|
kados |
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 |
|
kados |
any ideas? |
19:11 |
|
owen |
Don't look at me, I'm just an interface designer :) |
19:12 |
|
kados |
:-) |