Glitches, thoughts and potential bugs when adding orders in Koha 3.0
Hi there, I have been carrying out a pretty thorough test exercise on adding orders to vendors who have a variety of different settings in the Vendor Profile (ie discounts, list price includes GST or not, etc). I have found and bug reported some errors with calculating budgeted and replacement costs (bug 2865) but have a few other things which I would welcome comment on. It may be they are not bugs at all or I just have not understood what is happening. So, in no particular order: _1. Alphabeticised Item Type List_ I would like the Item Type drop down box to display the item types in alphabetical order. How do I make this so? As an illustrative example the current drop down lists in this order: 1.Adult Fiction, 2.Adult Nonfiction - Horowhenua, 3.Junior Fiction - Castle, 4. Junior Fiction, 5.Junior Fiction - Kermit, 6. Largeprint Fiction, 7.Largeprint Nonfiction, 8. Adult Nonfiction - Maori, 9. Adult Nonfiction. I would have expected them to appear in this order: 1,9,2,8,4,3,5,6,7 instead, if being organised alphabetically which would make it heaps easier to browse and tab through. _2. Saving with the Enter._ I think I would like to be able to save an order by hitting enter, rather than having to tab or scroll all the way down to the bottom of the page - which is annoying. I have tested this in Firefox. _3. Need a quicklink from 'No Results'_ It is a sound principle to always check the catalogue for a title before placing an order. {Starting point: home\acquisitions\vendor X\new basket for Vendor X\ } So having selected a vendor, I do a search in the "Add to Order from an existing record" search box. When I get "No Result Found' I can click on "Perform a New Search" link. But, I really would like another choice here; I want to be able to click on "Add a new (empty) record" without having to click first on "Perform a New Search". 4. I see I can enter isbn numbers in both 10 and 13 digit formats. Can I enter an issn instead for irregular publications which are not actually subscriptions / periodicals? 5. When I entered one of the orders, I made a spelling mistake in the authors name. However, I could not fix the typo. I had to instead delete the order and add it again. I need to be able to fix the typo in the home\cataloguing\editing screen, and save it. What currently happens is that when I hit save I get a pop up box telling me about all the fields I havn't filled in... which I can't fill in because I don't have the book yet! 6. My last problem is that while I know I have created biblios for the items I have ordered (but not received yet) I cannot search for them. I get "No Results Found". Does this mean that items do not display in the catalogue until they have been received into stock? Look forward to feedback before I proceed! Cheers Jo.
_1. Alphabeticised Item Type List_
This is a fairly pervasive problem. See Bug 2553: http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2553
_2. Saving with the Enter._
I'm not sure this would be a universally accepted change. Would anyone else care to give their opinion?
_3. Need a quicklink from 'No Results'_
I've submitted a patch to address this. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
"Owen Leonard" <oleonard@myacpl.org> wrote:
_2. Saving with the Enter._
I'm not sure this would be a universally accepted change. Would anyone else care to give their opinion?
I'm not sure - isn't submit-on-enter usual for web apps? Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
On Fri, Jan 2, 2009 at 7:29 AM, MJ Ray <mjr@phonecoop.coop> wrote:
"Owen Leonard" <oleonard@myacpl.org> wrote:
_2. Saving with the Enter._
I'm not sure this would be a universally accepted change. Would anyone else care to give their opinion?
I'm not sure - isn't submit-on-enter usual for web apps?
Sorta. It is common for web forms except where: 1. textarea input might include line breaks as valid (for example this gmail interface I'm using right now), or 2. multiple submit buttons allow different options, or 3. premature submission is particularly undesirable (large edits, generation of content, credit card transactions, etc). Some browsers implement "submit on enter" behavior when focus is in a given form where others do not. I assume the way around this is via YUI and explicitly defined behavior where desired. --Joe
We were using submit on enter with Acq and the processors do miss it now that it is gone. We had the barcode scanners programmed to add the enter and we would put the barcode of new items in last. Saved moving to the bottom of the page and clicking- Doesn't sound like much of a savings but when you are entering hundreds of books a day the time adds up. Susan Bennett ILS System Administrator Geauga County Public Library 440 286-6811 x 125 440 286-7419 FAX On Fri, Jan 2, 2009 at 9:58 AM, Joe Atzberger <ohiocore@gmail.com> wrote:
On Fri, Jan 2, 2009 at 7:29 AM, MJ Ray <mjr@phonecoop.coop> wrote:
"Owen Leonard" <oleonard@myacpl.org> wrote:
_2. Saving with the Enter._
I'm not sure this would be a universally accepted change. Would anyone else care to give their opinion?
I'm not sure - isn't submit-on-enter usual for web apps?
Sorta. It is common for web forms except where:
1. textarea input might include line breaks as valid (for example this gmail interface I'm using right now), or 2. multiple submit buttons allow different options, or 3. premature submission is particularly undesirable (large edits, generation of content, credit card transactions, etc).
Some browsers implement "submit on enter" behavior when focus is in a given form where others do not. I assume the way around this is via YUI and explicitly defined behavior where desired.
--Joe _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
We were using submit on enter with Acq and the processors do miss it now that it is gone. We had the barcode scanners programmed to add the enter and we would put the barcode of new items in last.
This is an issue I've wrestled with elsewhere in Koha's interface: places where scanning a barcode should *not* submit the form. In particular, member entry and item entry, where it's likely that a librarian will be using a barcode scannner to enter data. That's part of the reason why I'm hesitating on whether or not enter should submit by default. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Owen Leonard wrote:
We were using submit on enter with Acq and the processors do miss it now that it is gone. We had the barcode scanners programmed to add the enter and we would put the barcode of new items in last.
This is an issue I've wrestled with elsewhere in Koha's interface: places where scanning a barcode should *not* submit the form. In particular, member entry and item entry, where it's likely that a librarian will be using a barcode scannner to enter data. That's part of the reason why I'm hesitating on whether or not enter should submit by default.
Why not in those instances just make adding the barcode the last thing you do on the form? Cheers R
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Why not in those instances just make adding the barcode the last thing you do on the form?
Unfortunately this solution only works if you've only got one barcode entry field. I know some libraries are scanning the library card both under card number and something else--opac login maybe? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Owen Leonard wrote:
Why not in those instances just make adding the barcode the last thing you do on the form?
Unfortunately this solution only works if you've only got one barcode entry field. I know some libraries are scanning the library card both under card number and something else--opac login maybe?
Doesn't the library need to programme each barcode reader to send an "enter" command? That should mean that they can control the behaviour? IE so that if they don't want the barcode reader to send an enter & submit the form, then they don't set them to do it? Cheers R
-- Owen
Why not in those instances just make adding the barcode the last thing you do on the form?
Unfortunately this solution only works if you've only got one barcode entry field. I know some libraries are scanning the library card both under card number and something else--opac login maybe?
Doesn't the library need to programme each barcode reader to send an "enter" command? That should mean that they can control the behaviour?
That's true, but since the most often-used function of a barcode scanner will be for checkouts and check-ins it's not practical to eliminate the "enter" from the scanner. Even our catalogers spend a fair amount of time checking in items since they help fulfill reserves on newly-arrived items. I hope I'm not coming off as being argumentative here, I'm just trying lay out the pros and cons. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Rachel Hamilton-Williams <rachel@katipo.co.nz> wrote:
Doesn't the library need to programme each barcode reader to send an "enter" command? That should mean that they can control the behaviour? IE so that if they don't want the barcode reader to send an enter & submit the form, then they don't set them to do it?
My oldest barcode reader here (PS/2 type) sends enter after a barcode and it's not programmable. It would be very good to have barcode as the last field whenever possible and things like submitting a form with too few barcodes to simply redisplay the form, but I think/hope these old barcode readers are dying out in favour of USB HID ones, so maybe it's a niche requirement. Hope that helps, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
Owen Leonard a écrit :
_1. Alphabeticised Item Type List_
This is a fairly pervasive problem. See Bug 2553: http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2553
_2. Saving with the Enter._
I'm not sure this would be a universally accepted change. Would anyone else care to give their opinion?
I can give mine :-) I always found annoying to have <enter> working sometimes, and sometimes (most ?) not. I would be very happy to have a single behaviour. My preferred being <enter> working -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Same for me. Cab Vinton, Director Sanbornton Public Library Sanbornton, NH
_2. Saving with the Enter._ I'm not sure this would be a universally accepted change. Would anyone else care to give their opinion?
I can give mine :-)
I always found annoying to have <enter> working sometimes, and sometimes (most ?) not.
I would be very happy to have a single behaviour. My preferred being <enter> working
participants (8)
-
Cab Vinton -
Joann Ransom -
Joe Atzberger -
MJ Ray -
Owen Leonard -
paul POULAIN -
Rachel Hamilton-Williams -
Susan Bennett