← 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