January 2009 - Koha-bugs - lists.koha-community.org

[Bug 2930] New: Put other name on CKO screen
by bugzilla-daemon＠pippin.metavore.com 27 Jan '09

27 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2930 Summary: Put other name on CKO screen Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: dschust1(a)gmail.com QAContact: koha-bugs(a)lists.koha.org CC: dschust1(a)gmail.com Currently this information only displays on the Detail screen - Since several borrowers don't use their legal name, but we load them that way schools are putting in the "Other name" information. It would be helpful if that would display right under the name or behind it on the CKO screen. We are having to put it in the "notes" field to show on the CKO screen. example - Charolett Elam actually goes by Mary - but you don't know that on the CKO screen. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2929] new fine type
by bugzilla-daemon＠pippin.metavore.com 27 Jan '09

27 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2929 ------- Comment #1 from nahuel.angelinetti(a)biblibre.com 2009-01-27 06:46 ------- Created an attachment (id=598) --> (http://bugs.koha.org/cgi-bin/bugzilla/attachment.cgi?id=598&action=view) bugfix for 3.0.x ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2929] New: new fine type
by bugzilla-daemon＠pippin.metavore.com 27 Jan '09

27 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2929 Summary: new fine type Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Circulation AssignedTo: nahuel.angelinetti(a)biblibre.com ReportedBy: nahuel.angelinetti(a)biblibre.com QAContact: koha-bugs(a)lists.koha.org Some new fine type should be added to koha in issuing rules. Fines in days, not in money. So a user who have 1 day of overdue return, can be punished X days and be denied to loan any other item. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2703] Clicking Spent on Budget Shows Nothing
by bugzilla-daemon＠pippin.metavore.com 27 Jan '09

27 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2703 ------- Comment #4 from winterj(a)arcadia.edu 2009-01-27 05:58 ------- The initial query in spent.pl: Select quantity,datereceived,freight,unitprice,listprice,ecost,quantityreceived # as qrev,subscription,title,itemtype,aqorders.biblionumber,aqorders.booksellerinvoicenumber, # quantity-quantityreceived as tleft, # aqorders.ordernumber # as ordnum,entrydate,budgetdate,booksellerid,aqbasket.basketno # from aqorders,aqorderbreakdown,aqbasket # left join biblioitems on biblioitems.biblioitemnumber=aqorders.biblioitemnumber # where bookfundid=? and # aqorders.ordernumber=aqorderbreakdown.ordernumber and # aqorders.basketno=aqbasket.basketno # and ( # (datereceived >= ? and datereceived < ?)) # and (datecancellationprinted is NULL or # datecancellationprinted='0000-00-00') and what it should be: Select distinct quantity,datereceived,freight,unitprice,listprice,ecost,quantityreceived as qrev,subscription,title,itype as itemtype,aqorders.biblionumber,aqorders.booksellerinvoicenumber, quantity-quantityreceived as tleft, aqorders.ordernumber as ordnum,entrydate,budgetdate,aqbasket.booksellerid,aqbasket.basketno from aqorders inner join aqorderbreakdown on aqorderbreakdown.ordernumber = aqorders.ordernumber inner join aqbasket on aqbasket.basketno = aqorders.basketno left join items on items.biblionumber=aqorders.biblionumber where bookfundid=? and aqorders.ordernumber=aqorderbreakdown.ordernumber and aqorders.basketno=aqbasket.basketno and ( (datereceived >= ? and datereceived < ?)) and (datecancellationprinted is NULL or datecancellationprinted='0000-00-00') ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2928] New: Authority search on specific authtype may not work
by bugzilla-daemon＠pippin.metavore.com 27 Jan '09

27 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2928 Summary: Authority search on specific authtype may not work Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P3 Component: MARC Authority data support AssignedTo: galen.charlton(a)liblime.com ReportedBy: frederic(a)tamil.fr QAContact: koha-bugs(a)lists.koha.org If I have those two authority types: - SUB - SUB_REGIONAL If I do a seach on 'SUB', as a result, I get authorities from SUB _and_ SUBS_REGIONAL. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2769] Holding a document show the user as expired
by bugzilla-daemon＠pippin.metavore.com 27 Jan '09

27 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2769 ------- Comment #2 from mason.loves.sushi(a)gmail.com 2009-01-26 17:32 ------- has this been accepted yet? i just fixed the same bug... ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2703] Clicking Spent on Budget Shows Nothing
by bugzilla-daemon＠pippin.metavore.com 27 Jan '09

27 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2703 ------- Comment #3 from jransom(a)library.org.nz 2009-01-26 16:56 ------- We are dead keen to get this fixed too please; can't go live without it. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2927] New: Saving on enter
by bugzilla-daemon＠pippin.metavore.com 27 Jan '09

27 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2927 Summary: Saving on enter Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P3 Component: Architecture, internals, and plumbing AssignedTo: galen.charlton(a)liblime.com ReportedBy: jransom(a)library.org.nz QAContact: koha-bugs(a)lists.koha.org I would like to be able to save changes to a screen by hitting the enter button instead of having to scroll or tab right through the page to save my work. Discussion carried out on koha list: Q: " I'm not sure this would be a universally accepted change. Would anyone else care to give their opinion?" *A1. I'm not sure - isn't submit-on-enter usual for web apps? *A1b. 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, or3. 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. *A2. 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. *A2b. Same for me. *A3. 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. *A4 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. *A4a Why not in those instances just make adding the barcode the last thing you do on the form? *A4b 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? *A4c 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? *A4d 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. * A4e 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. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2553] alphabetize dropdown menus
by bugzilla-daemon＠pippin.metavore.com 26 Jan '09

26 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2553 jransom(a)library.org.nz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jransom(a)library.org.nz ------- Comment #1 from jransom(a)library.org.nz 2009-01-26 14:46 ------- It appears that some alphabetized sorting is being done. In add order in acqusitions the item type box appears random. EG: 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. But if I look at the item type codes for those then they are in perfect order: 1. BF 2. BH 3. BJC 4. BJF 5. BJK 6. BLF 7. BLN 8. BM 9. BN The confusion comes in, in this instance, because they are sorted by code but display by description. 2 options therefore: 1. sort by description and display by description (as at present) or 2. Sort by code (as at present) and display the code (optionally and preferably followed by the plain english description.) eg: 1. BF - Adult Fiction 2. BH - Adult Nonfiction - Horowhenua 3. BJC - Junior Fiction - Castle 4. BJF - Junior Fiction 5. BJK - Junior Fiction - Kermit My personal preference would be to sort by description, but equally it could be setup preference as to whether to sort by code or description. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2926] Stage for Import never returns
by bugzilla-daemon＠pippin.metavore.com 26 Jan '09

26 Jan '09

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2926 ------- Comment #3 from mattgheen(a)yahoo.com 2009-01-26 05:01 ------- Created an attachment (id=597) --> (http://bugs.koha.org/cgi-bin/bugzilla/attachment.cgi?id=597&action=view) The Marc Record ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0