July 2022 - Koha-bugs - lists.koha-community.org

[Bug 20344] New: Transferring an item while on hold results in a transfer were the destination is the same as the source
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '24

24 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Bug ID: 20344 Summary: Transferring an item while on hold results in a transfer were the destination is the same as the source Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1. Check out an item 2. Place a hold on the specific item with a pickup at a different branch 3. Check in: Confirm hold and transfert 4. Check the branchtransfers table to ensure that the transfert is here SELECT * FROM branchtransfers order by datesent DESC LIMIT 10; 5. Home › Circulation › Transfers 6. Create a transfer identical as the existing one 7. You should see «Item is already at destination library.» 8. Check the branchtransfers table 1. First one should have been canceled «Canceled, new transfer from A to A created» 2. Another one should have been created from A to A 3. These 2 things are the issue. Because doing the same without a hold - doesn't create a new transfer - doesn't cancel the first one -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 19375] New: Show message when transfer is finished by checking in
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '24

24 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19375 Bug ID: 19375 Summary: Show message when transfer is finished by checking in Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When book is in transfer and is in transfer and is checked in in target library, the transfer is finished by this operation. It would be nice to have some message about that. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 31184] New: Add default permissions by patron category
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '24

24 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31184 Bug ID: 31184 Summary: Add default permissions by patron category Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It could be useful to assign default permissions by patron category. (This was pointed out to me by a librarian who had similar functionality in a previous system.) Alternatively, I suppose we could create "permission profiles" and assign those at patron creation time I suppose. The idea being that you set up permissions for certain staff categories (like cataloguing or circulation) and then the staff automatically have their permissions set up and don't require you to manually check all the right checkboxes on a per-user basis. (I suppose role/group-based authorization would cut down even further on having to manually manage so many permissions...although this probably more of a problem for large libraries than small libraries...) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 29348] New: GetOtherReserves fails to mark holds as waiting or in-transit
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '24

22 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29348 Bug ID: 29348 Summary: GetOtherReserves fails to mark holds as waiting or in-transit Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com ModReserveCancelAll is called when a hold is cancelled from the waiting holds list This in turn calls GetOtherReserves GetOtherReserves then calls ModReserveMinusPriority which sets the priority to 0 and then calls _FixPriority The problem is that 'found' is still null for the holds - so it is processed by _FixPriority and has its' priority increased by 1 - this prevents it from being marked waiting or in transit by subsequent code This leaves holds in an odd state where they have an itemnumber, but no status - okay for an item level hold - but bad for bib level To recreate: 1 - Place a bib level hold for 3 different patrons on the same bib The first two should be picked up at logged in branch, the third elsewhere 2 - Check-in and confirm the hold 3 - Go to Circulation->Holds awaiting pickup 4 - Cancel the hold - you get a popup asking you to check in the item to process the hold 5 - View the biblio - see that hold has an itemnumber, but no status 6 - Check in the item, confirm the hold, cancel from waiting reserves 7 - View the biblio - third hold has the itemnumber, but no status While we do say in the message "Check this in to process the hold" the code indicates it will start the transfer or set the hold waiting. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21059] New: callback function in OPAC
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '24

22 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21059 Bug ID: 21059 Summary: callback function in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: kyle(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Work to be done: Add the ability to define a callback function when adding an item to an order Define a callback function in intranetuserjs/OPACuserjs to remove items from the cart upon placing an order -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 25653] New: Authorities search does not retain selection
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '24

22 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25653 Bug ID: 25653 Summary: Authorities search does not retain selection Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Browse to Authorities 2 - Search in each tab 3 - Note all search results revert to 'Search main heading a only' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 29863] New: Show requested transfers in the holdings table
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '24

20 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29863 Bug ID: 29863 Summary: Show requested transfers in the holdings table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When there is a requested transfer on an item, we should show that in the item's status in the holdings table on /catalogue/detail.pl. Right now, the requested transfer can only be seen in the Transfers to Send report in circulation. Maybe instead of "Available" they could say "Transfer requested to [branch]"? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 28224] New: Make date range for order search configurable
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '24

19 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28224 Bug ID: 28224 Summary: Make date range for order search configurable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When searching orders in the acquisitions module the search is automatically limited to orders created in the last year. In some circumstances, like when testng migration data, this can get quite annoying very fast adding a lots of extra clicks and typing. It would be great if the date range or at least the start date was configurable here. /cgi-bin/koha/acqui/histsearch.pl When changed using jQuery this will only work once you have reached the form. But using the search options on top also limit on the date range already. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 30930] New: Ability to change authority type while editing record
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '24

19 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30930 Bug ID: 30930 Summary: Ability to change authority type while editing record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When editing a biblio record, the editor has a 'Settings' menu which allows you to change the record's framework within the editor. The authority editor should have this feature too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 25655] New: Additionally store actual cost in foreign currency, currency and currency rate used
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '24

19 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25655 Bug ID: 25655 Summary: Additionally store actual cost in foreign currency, currency and currency rate used Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Bug 24158 allows to calculate the actual cost on time of receive from a foreign currency. If I understand our current database structure correctly, we store in aqorders.currency the currency used at the time of ordering, but we don't store the conversion rate used or the original price. I think it would make sense to store them as well. It will also allow to display the orginal prices and rates used on invoices and possibly other pages, which will help staff when checking that everythign was handled correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 68