IRC log for #koha, 2008-01-03

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

All times shown according to UTC.

Time Nick Message
13:26 owen Happy New Year, #koha
13:26 paul happy new year owen !
13:39 kados g'morning all
13:39 owen Hi kados
13:39 kados happy new year too ! -)
13:40 paul: I've committed myself to a date for 3.0 Alpha
13:40 paul happy new year to you & your beloved ppl kados.
13:40 kados paul: as I'm sure you noticed :-)
13:40 paul yes, i've seen the mail.
13:40 kados paul: thx, you too!
13:41 paul kados : why do you plan to call it "alpha" ? for me, an alpha software is unusuable & unstable. which is not the case atm
13:41 kados paul: also, you should know that the patches you send with the zip wouldn't apply ... because of the order in which they were applied
13:41 paul: because it is unusable and unstable :-)
13:42 paul strange, I just rebase a few minuts ago, without any problem. will send them again.
13:42 we definetly disagree here kados, as we are deploying it (and liblime too if I don't mind)
13:42 kados paul: I know we disagree on this topic, but the curent state of 3.0 is not up to a high enough quality to be considered stable ... and it's not at all been tested by libraries
13:43 paul for me it's not ready for a officially stable release, but there is a diff between an alpha and what we have atm.
13:43 kados yep, but I give us a month to work on a beta ...
13:44 so the beta will be released hopefully on Feb 1
13:44 and then hopefully the stable will be ready by Mar 1
13:44 paul you won't change my mind. And i'm afraid I won't change your...
13:45 do you plan to do changes in DB and/or in API ?
13:45 kados one minor change that I know of in the DB, just change the default value on some item status fields
13:47 paul if you can promise you won't do any changes to API or database structure (unless a really blocking problem occurs, of course), then I think we could be happy with the "alpha" release.
13:47 as we won't consider it as alpha, and deploy it to more customers in the next weeks (something like 4 or 5 libraries in the immediate queue)
13:48 kados the list of things I expect to change between alpha->beta are listed in the email
13:49 paul yes, and i have questions about 2 or 3 of the topics, i'll ask on koha-devel, as I think everybody will be interested by the answer
13:49 kados *nod*
13:49 hdl happy new year too all.
13:49 kados welcome back hdl!
13:50 hdl kados: you had a problem with a commit on NZsearch.
13:50 kados hdl: currently NZsearch doesn't work in the advsearch template ...
13:50 hdl Can you detail ?
13:51 kados hdl: and there was a patch but it touched buildQuery, which should not be done as it builds 100% correct CCL
13:51 sure ... just a sec
13:55 paul kados : do you want that I send you the patches immediatly ? (which mailbox ?)
13:56 kados paul: the patches one is OK
13:57 paul done
13:59 kados : could you avoid reindenting & fixing something in the same commit ?  It's very hard to review when both things are mixed.
14:00 kados paul: yes, sorry, I will do reindent first, then fix :-)
14:00 paul thx
14:00 hdl you can avoid having diffs on indentation with git config.
14:01 if i donot mind.
14:02 ftp://209.172.63.197/pub/mirrors/kernel.org/​software/scm/git/docs/v1.5.1.5/git-diff.html
14:03 http://www.kernel.org/pub/soft[…]format-patch.html
14:03 look for ignore space
14:03 paul does it manage tab => space changes ? (as usually it's that kind of changes)
14:04 hdl -b -w
14:05 paul I know, and I do the same, but I used to use tabs, so there are zillions of tabs remaining.
14:05 maybe we should do a big replace of all tabs by 4 spaces & 1 huge commit, and that's done...
14:20 gmcharlt good morning #koha
14:20 paul happy new year gmcharlt !
14:21 gmcharlt happy new year paul :)
14:23 paul gmcharlt: about your answer on koha-devel and just to be sure...
14:23 gmcharlt paul: ok
14:23 paul you won't use hardcoded things to map items.* fields and marcxml tags/subfields
14:24 (as we have different mappings for unimarc)
14:24 gmcharlt paul: no, everything's going through the MARC frameworks
14:24 paul (and at least 2 possible mappings in UNIMARc : recommandation 995, which is the most widely used, and SUDOC, which is used in univerities)
14:24 ok, thanks
15:45 gmcharlt paul: about?
15:45 paul yes ?
15:45 gmcharlt paul: do any of the French libraries use the bulkedit from catalogue search results feature?
15:46 it currently has two issues -- first, I'm not sure it it actually gets activated at all ATM
15:46 paul (more boring because I won that RFP 2 months ago, but another vendor said he would sue the library if she didn't cancel the decision & re-write an RFP)
15:46 gmcharlt secondly, it allows editing of item info with the MARC without updating the items table
15:47 (sorry about the RFP woes; RFP--)
15:47 paul (of course, the library noticed she made something wrong in the previous RFP, but don't intend to change it's choice...)
15:47 gmcharlt: and you don't know what it means in france !!!
15:47 gmcharlt (but the forms must be obeyed, alas)
15:47 paul gmcharlt: you should ask hdl about the bulkedit feature, as he wrote it
15:48 gmcharlt paul: what do you mean?  we have RFPs (requests for proposal) in the US too :)
15:48 hdl: about?
15:48 paul yes, but you never answered a french rfp (note that I only answered NPL rfp 5 years ago, so maybe my experience is not enough to compare us & france)
15:49 hdl yes
15:49 gmcharlt paul: yeah, true, I've never seen a French one -- how bad are they?
15:49 hdl gmcharlt: I am there.
15:49 gmcharlt hdl: did you see my question about the bulkedit feature?
15:49 hdl yes.
15:49 bulkedit is still not stable enough for production.
15:50 gmcharlt hdl: that's what I thought
15:50 hdl I think that it doesnot use ModItem.
15:50 as far as holding information is modified.
15:50 gmcharlt hdl: mind if I modify it a bit so that it isn't allowed to touch the item tag (i.e., 995/952/whatever is in the framework?)
15:50 paul (this one is 5 documents, for a total of 40 pages, and they request an answer on 3 of them, + 3 legal papers (called DC4, DC5 and DC7), that have to be provided for every RFP)
15:51 gmcharlt (paul: icky.  although I've seen a few 100+-page RFPs, mostly from very large library systems in US)
15:51 hdl Can't you modify it to use ModItem if change occur in holding tag ?
15:52 paul (gm : this is a very small library 10 branches, 20 000 items total)
15:52 gmcharlt hdl: could, but I think a separate bulkitem feature would be better at some point, since it requires care to not allow batch editing of circ-related fields such as loan statuses and the like
15:53 hdl you can do what you said then
15:54 gmcharlt hdl: OK, thanks
16:05 owen kados, can I ask about Bug 1704?
16:07 kados sure
16:08 AutomaticItemReturn is a confusing syspref unfortunately
16:08 it could mean two things:
16:08 1. items seek to return to their home branch
16:09 scratch that ...
16:09 I think what we decided, is that if it's ON, the system will prompt the staff to return the item to the homebranch, and will 'check in' the item, and initiate a transfer (something NPL hasn't ever used)
16:10 the transfer will be initiated when the staff clicks OK
16:10 otherwise the item is just returned
16:10 owen: does that make sense?
16:11 owen And if AutomaticItemReturn is off, it should display a message but not ask for confirmation?
16:12 kados yea, IIRC
16:13 if it's OFF it means that the library group doesn't care where the item is :-)
16:13 difficul to imagie when that would be
16:13 maybe paul or hdl can clarify
16:14 hdl paul : it is SANWP feature?.
16:14 owen Well, NPL wouldn't necessarily want to initiate a transfer for every return, and they certainly don't want to click 'confirm' for every return from a different branch
16:15 paul yes, it's a san-op feature iirc.
16:15 but I think AutomaticItemReturn=OFF was the previous behaviour.
16:15 and sanop added =ON
16:16 (maybe i'm wrong & miss something)
16:16 kados we really need to have two sysprefs, one to determine whether to initiate a transfer, and one to say whether to have a dialog about it
16:16 paul: yes, but sanop's code for ON didn't work :-)
16:16 paul nobody from sanop on #koha-fr atm, should still be on vacation
16:16 kados owen: I think NPL wants transfers
16:17 owen Can you define "transfer" ?
16:17 kados yea, a transfer is basically a way to keep track of items that are in transit from Library A to Library B
16:17 so the item was returned to Athens, but where is it now?
16:18 without the transfers table, we hasically have to compare the homebranch to the holdingbranch and guess that if they are different, the item is in transit
16:18 the transfers table makes that explicit
16:18 and you can run reports on it, etc.
16:18 owen Does the transfers table now handle hold transfers too?
16:19 kados I don't think so, but please file that as a request on bugzilla
16:19 actually, it could
16:19 in fact, I'm sure that's the intent of it in the first place
16:20 rather than 'returning' the item, you'd set up a transfer
16:20 it'd be worth testing that
16:21 owen So if I check in something at my branch that belongs at another branch, I'm really creating two transactions: first a return, then a transfer?
16:23 kados if you click OK, yes
16:23 otherwise it's just a checkin
17:30 nicomo who #koha
18:53 owen Should an item show as "available" if it's not for loan?
18:53 I guess there's some ambiguity as to whether "available" means "can check out" or "is on the shelf"
19:02 kados owen: I originally had it as yes, but paul changed it
19:02 yea, what does available mean exactly :-)
19:02 reference materials should be listed as available, if they're not lost, right?
19:02 paul: any thoughts on that?
19:03 owen kados: the reference example is what I was thinking of too.
19:03 chris available here has always meant not for loan
19:03 sorry not - not for loan
19:04 kados ahh, realy?
19:04 chris a reference would show up as not for loan
19:04 kados yea, but would it show up as available?
19:04 on the search results page?
19:05 chris hmm for 2.2 we dont say available .. we only say if its not
19:06 kados so you'd say 'Not for loan' as a status
19:06 interesting
19:06 well we have three groups currently:
19:06 chris http://www.library.org.nz/cgi-[…]tail.pl?bib=58708
19:06 kados 1. not available (for some reason described, lost, damaged, wthdrawn)
19:07 2. avaialble (means not checked out, and not not avaialble)
19:07 3. checked out (someone has it on loan + it can have any of the not avaialble statuses)
19:07 sounds like we need a 4th
19:07 4. Not supposed to be loaned ... but available on the shelf
19:08 owen: can you file a bug for that and assign it to me ?
19:08 I can add it lickity split
19:08 owen What will you call it?
19:08 kados Not for Loan
19:09 owen So an item marked as not for loan will no longer also show as available
19:09 kados it will show up as both available and not for loan
19:09 owen Actually, the search results page does show not for loans as unavailable.
19:09 kados ie, those aren't mutually exclusive as I'm understanding it
19:10 owen But the detail page says not for loan /and/ available.
19:10 kados yea, I think paul only altered the detail page IIRC
19:10 owen I'm not sure I understand the solution you're proposing
19:11 chris i think having something say not for loan, and available will be confusing at least in NZ .. will there be a way to switch it off?
19:12 owen Maybe we can come up with a solution that's clear for everyone?
19:13 kados available is currently defined as:
19:13 <!-- TMPL_UNLESS NAME="onloan" --><!-- TMPL_UNLESS NAME="itemlost" --><!-- TMPL_UNLESS NAME="wthdrawn" --><!-- TMPL_UNLESS NAME="damaged" --><!-- TMPL_UNLESS NAME="transfertwhen" --><!-- TMPL_UNLESS NAME="reservedate" -->
19:13 so maybe we need a status called 'On Shelf'
19:13 and just don't bother with the word Available
19:14 chris yeah available has always meant available to be borrowed here
19:14 kados chris: would that be clear?
19:14 chris so if that was changed to on shelf
19:14 combined with not for loan
19:14 kados owen: so just s/Available/On shelf/
19:15 and I can add a new loop for items that are notforloan
19:15 chris but i dont like the reservedate thing
19:15 kados it's already there actually
19:15 chris just cos its reserved
19:15 owen And search results would say "5 on shelf, no items available" ?
19:15 chris doesnt mean i shouldnt be able to take it off the shelf
19:15 kados owen: I don't think we should use available at all
19:16 chris should only be if its marked waiting ... me hopes reservedate is only filled if its a waiting reserve
19:16 kados chris: yea, that's gonna need to be configuratble
19:16 configurable I mean
19:16 chris yep
19:16 owen So search results  would say "5 on shelf" (it already says "not for loan" in the item display)
19:17 kados owen: yea
19:17 owen: also, did you notice, there are two ways to display item details on the results page
19:17 owen: one is illustrated in the OPAC and one in the staff side
19:17 owen: we need a new syspref to determine which one to display where
19:18 owen: some people will just want the summary display (like the current NPL opac)
19:18 and others will want the full-on detailed view (like wha the staff client has now)
19:18 I suspect we need two sysprefs, one for the OPAC and one for the Staff client display
19:29 owen kados: And you think detail.pl should say "Not for loan" and "On shelf" ?
19:32 kados owen: the display in detail should be identical to that in results
19:32 IMO
19:34 owen It's not as easy as that, because search results show a summary plus items, and detail.pl just shows items
19:34 http://staff.oleonard.dev.koha[…]&sort_by=title_az
19:34 http://staff.oleonard.dev.koha[…]?biblionumber=195
19:37 Also, we'll need to fix the way results.tmpl judges whether something is available, because as you can see it says "5 unavailable" for "The black pearl"
19:38 kados oh, right
19:39 owen: all you need to do is change Available to On shelf
19:40 chris owen: good call with 1551, i can work on something for that, it might have to wait until i get some of the nastier bugs out of the way, but yep a little renewed indicator would be easy
19:40 kados notforloan should show up in the Avaialble loop (renamed to On shelf loop)
19:40 does that make sense?
19:40 chris owen: it could even tell you how many times its been renewed if that was useful
19:41 owen chris: Something like "Renewed. 1 of 2 renewals left" ?
19:42 kados we have that in the OPAC opac-user.pl, don't we?
19:42 chris yeah can do
19:42 owen kados: yes, but that display is for a "Renew" link, which is different
19:43 We're talking about the renew checkboxes in circ and moremember.
19:43 kados gotcha
19:44 owen kados: I can't just change available to on shelf, because I'm talking about where it says "No items available" and "<count> unavailable"
19:45 kados can't we just say 'no items on shelf and '<count> not on shelf' ?
19:45 owen But the items in question are on the shelf, they're just not for loan
19:45 kados ahh
19:46 yes, the problem is that they are currently being put into the wrong group
19:46 the notforloan ones should be put into the 'on shelf' loop (called avaialble)
19:46 owen Yes
19:46 kados so we need to revert paul's change, and then change the nomenclature
19:47 owen: I can do both of those, just file abug and assign it to me
19:48 Searching works
19:49 chris owen: got a sec to talk about 1704 ?
19:49 owen Yes
19:49 chris so you have automaticitemreturns off .. and you return an item to the wrong branch eh?
19:49 and you dont get a box saying
19:50 This item needs to be transfered to ML
19:50 (or whatever branch it needs to go to)
19:50 and a confirm and transfer button?
19:50 hdl chris : we already have a counter in items table for that don't we ?
19:50 chris hdl: for renewal yep, its just a matter of displaying it :)
19:51 owen chris: strange, just now it did. I wonder what was different about that item.
19:52 chris if you turn automaticitemreturns on .. you still get the dialogue .. it just automatically does the transfer for you
19:52 so no confirm button
19:52 owen Sometimes I just get "Please return <title> to <branch>
19:52 chris hmm really?
19:53 can you check the ones you get that for
19:53 do they have a reserve on them?
20:03 owen Should there be a yes/no choice if something needs to be transferred?
20:04 kados: Do you have an opinion on that question?
20:04 chris yes = click confirm and transfer
20:04 no = return another item
20:04 thats how it works now
20:04 owen So chris, if I don't click 'confirm and transfer,' it's checked in, but not transfered.
20:05 chris exactly
20:05 owen Okay, to take away the ambiguity, I think there should be a yes/no choice, and librarians can ignore it if they're savvy
20:05 chris what should the no do?
20:09 owen Hmm... Really all it has to do is make it look like the user made a choice. If we could rely on javascript, it could just hide the dialog. Otherwise you'd have to reload the page while retaining the history of previous checkins.
20:09 chris yeah it will have to reload the page
20:09 we cant rely on only js
20:09 someone will turn it off :-)
20:09 ok will do
20:10 masonj morning #koha
20:12 owen hi masonj
20:15 chris sending a patch now
20:21 ive changed the dialogue you get when you return an item that is already on transfer too, sending a patch for that now
20:27 owen chris: so now it asks you to transfer it to the branch specified in the original transfer rather than to the home branch?
20:27 chris yeah it should
20:27 to <!-- TMPL_VAR Name="TransferWaitingAt" -->
20:30 ill just check that is being populated right
20:32 masonj hiya owen

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

koha1