| Time |
S |
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 |
|
kados |
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 |
|
kados |
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 |
|
paul |
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 |
|
kados |
so the beta will be released hopefully on Feb 1 |
| 13:44 |
|
kados |
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 |
|
paul |
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 |
|
paul |
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 |
|
kados |
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 |
|
paul |
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 |
|
hdl |
if i donot mind. |
| 14:02 |
|
hdl |
ftp://209.172.63.197/pub/mirrors/kernel.org/software/scm/git/docs/v1.5.1.5/git-diff.html |
| 14:03 |
|
hdl |
http://www.kernel.org/pub/soft[…]format-patch.html |
| 14:03 |
|
hdl |
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 |
|
paul |
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 |
|
paul |
(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 |
|
paul |
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 |
|
gmcharlt |
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 |
|
gmcharlt |
(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 |
|
paul |
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 |
|
gmcharlt |
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 |
|
hdl |
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 |
|
hdl |
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 |
|
kados |
AutomaticItemReturn is a confusing syspref unfortunately |
| 16:08 |
|
kados |
it could mean two things: |
| 16:08 |
|
kados |
1. items seek to return to their home branch |
| 16:09 |
|
kados |
scratch that ... |
| 16:09 |
|
kados |
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 |
|
kados |
the transfer will be initiated when the staff clicks OK |
| 16:10 |
|
kados |
otherwise the item is just returned |
| 16:10 |
|
kados |
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 |
|
kados |
if it's OFF it means that the library group doesn't care where the item is :-) |
| 16:13 |
|
kados |
difficul to imagie when that would be |
| 16:13 |
|
kados |
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 |
|
paul |
but I think AutomaticItemReturn=OFF was the previous behaviour. |
| 16:15 |
|
paul |
and sanop added =ON |
| 16:16 |
|
paul |
(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 |
|
kados |
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 |
|
kados |
so the item was returned to Athens, but where is it now? |
| 16:18 |
|
kados |
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 |
|
kados |
the transfers table makes that explicit |
| 16:18 |
|
kados |
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 |
|
kados |
actually, it could |
| 16:19 |
|
kados |
in fact, I'm sure that's the intent of it in the first place |
| 16:20 |
|
kados |
rather than 'returning' the item, you'd set up a transfer |
| 16:20 |
|
kados |
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 |
|
kados |
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 |
|
owen |
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 |
|
kados |
yea, what does available mean exactly :-) |
| 19:02 |
|
kados |
reference materials should be listed as available, if they're not lost, right? |
| 19:02 |
|
kados |
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 |
|
chris |
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 |
|
kados |
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 |
|
kados |
interesting |
| 19:06 |
|
kados |
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 |
|
kados |
2. avaialble (means not checked out, and not not avaialble) |
| 19:07 |
|
kados |
3. checked out (someone has it on loan + it can have any of the not avaialble statuses) |
| 19:07 |
|
kados |
sounds like we need a 4th |
| 19:07 |
|
kados |
4. Not supposed to be loaned ... but available on the shelf |
| 19:08 |
|
kados |
owen: can you file a bug for that and assign it to me ? |
| 19:08 |
|
kados |
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 |
|
kados |
<!-- 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 |
|
kados |
so maybe we need a status called 'On Shelf' |
| 19:13 |
|
kados |
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 |
|
chris |
combined with not for loan |
| 19:14 |
|
kados |
owen: so just s/Available/On shelf/ |
| 19:15 |
|
kados |
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 |
|
kados |
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 |
|
kados |
owen: also, did you notice, there are two ways to display item details on the results page |
| 19:17 |
|
kados |
owen: one is illustrated in the OPAC and one in the staff side |
| 19:17 |
|
kados |
owen: we need a new syspref to determine which one to display where |
| 19:18 |
|
kados |
owen: some people will just want the summary display (like the current NPL opac) |
| 19:18 |
|
kados |
and others will want the full-on detailed view (like wha the staff client has now) |
| 19:18 |
|
kados |
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 |
|
kados |
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 |
|
owen |
http://staff.oleonard.dev.koha[…]&sort_by=title_az |
| 19:34 |
|
owen |
http://staff.oleonard.dev.koha[…]?biblionumber=195 |
| 19:37 |
|
owen |
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 |
|
kados |
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 |
|
kados |
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 |
|
owen |
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 |
|
kados |
yes, the problem is that they are currently being put into the wrong group |
| 19:46 |
|
kados |
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 |
|
kados |
owen: I can do both of those, just file abug and assign it to me |
| 19:48 |
|
kados |
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 |
|
chris |
and you dont get a box saying |
| 19:50 |
|
chris |
This item needs to be transfered to ML |
| 19:50 |
|
chris |
(or whatever branch it needs to go to) |
| 19:50 |
|
chris |
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 |
|
chris |
so no confirm button |
| 19:52 |
|
owen |
Sometimes I just get "Please return <title> to <branch> |
| 19:52 |
|
chris |
hmm really? |
| 19:53 |
|
chris |
can you check the ones you get that for |
| 19:53 |
|
chris |
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 |
|
owen |
kados: Do you have an opinion on that question? |
| 20:04 |
|
chris |
yes = click confirm and transfer |
| 20:04 |
|
chris |
no = return another item |
| 20:04 |
|
chris |
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 |
|
chris |
we cant rely on only js |
| 20:09 |
|
chris |
someone will turn it off :-) |
| 20:09 |
|
chris |
ok will do |
| 20:10 |
|
masonj |
morning #koha |
| 20:12 |
|
owen |
hi masonj |
| 20:15 |
|
chris |
sending a patch now |
| 20:21 |
|
chris |
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 |
|
chris |
to <!-- TMPL_VAR Name="TransferWaitingAt" --> |
| 20:30 |
|
chris |
ill just check that is being populated right |
| 20:32 |
|
masonj |
hiya owen |
