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

[Bug 33878] New: SIP does not warn for patron expiry (as NotifyBorrowerDeparture does)
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '23

01 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33878 Bug ID: 33878 Summary: SIP does not warn for patron expiry (as NotifyBorrowerDeparture does) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See bug 33522 and 28688 too. Pref NotifyBorrowerDeparture brings a warning on OPAC and staff. But SIP does not show it if I am not mistaken. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '23

01 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 --- Comment #155 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- A quick note, it seems that we are using #jobpanel for the progress bar, which is the old way. Now we should prefer job_progress.inc. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20568] New: Add API key management interface for patrons
by bugzilla-daemon＠bugs.koha-community.org 31 May '23

31 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20568 Bug ID: 20568 Summary: Add API key management interface for patrons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Bug 20402 implements an Oauth2 server for the client credentials grant. It should be awesome if the patron management interface in Koha provided a way for staff members (and maybe for patron users later) to create and revoke API keys. The work is actually done already, by Julian in the first commit for bug 13920. So we need to recover that patch, adapt it to our coding guidelines and make it work on top of bug 20402! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 75

[Bug 8331] Hidden field does not hide from plain MARC and normal views in staff
by bugzilla-daemon＠bugs.koha-community.org 31 May '23

31 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8331 Laura Escamilla <Laura.escamilla(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Laura.escamilla@bywatersolu | |tions.com --- Comment #10 from Laura Escamilla <Laura.escamilla(a)bywatersolutions.com> --- Commenting to put this back on everyone's radar. We are still running into this issue. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33874] New: ILL Table - Pressing a column header to sort causes left-side filter values to be applied
by bugzilla-daemon＠bugs.koha-community.org 31 May '23

31 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33874 Bug ID: 33874 Summary: ILL Table - Pressing a column header to sort causes left-side filter values to be applied Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 22440 To reproduce: * Run sh start-ill-dev.sh (copy from https://github.com/ammopt/koha-ill-dev/blob/master/start-ill-dev.sh) * Create 1 request in some library * Go back to the table, pick a different library from the left-side filters but dont press the 'Search' button * Click on any column header to sort, notice the requests disappears (because the library filter value is being applied) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22440 [Bug 22440] Improve ILL page performance by moving to server side filtering -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 21548] New: ILLLIBS patron category / partner_code seems extraneous
by bugzilla-daemon＠bugs.koha-community.org 31 May '23

31 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21548 Bug ID: 21548 Summary: ILLLIBS patron category / partner_code seems extraneous Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com The original installation notes created by Alex for ILL (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317#c20) describe a requirement to create a new patron category with a code ILLLIBS, organisational patrons are then attached to this category and their email address is used for the "Place request with partners" function. However, Koha ships with a patron category called "Inter-Library Loans" (code: IL) which would appear to remove the requirement for an ILLLIBS category to be created. This bug proposes moving away from using ILLLIBS and using the pre-existing IL category instead. Grepping the code for ILLLIBS reveals that it's assumed to exist and will be used as a default code if one is not specified in the <partner_code> element in koha-conf.xml, so modifications will be required. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 27462] New: Number of suggestions includes archived suggestions
by bugzilla-daemon＠bugs.koha-community.org 31 May '23

31 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27462 Bug ID: 27462 Summary: Number of suggestions includes archived suggestions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 25033, 22784 On the main page the number of suggestions includes archived suggestions. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22784 [Bug 22784] Add the ability to archive purchase suggestions https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25033 [Bug 25033] Counts of suggestions are confusing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 33846] New: 'Save' and 'close' buttons confusing on multi-receive
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33846 Bug ID: 33846 Summary: 'Save' and 'close' buttons confusing on multi-receive 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I'm opening this so we don't forget. Talking with Kyle and Nick, we agreed the 'Save' button is weird, in the sense that it is not saving but updating the underlying table which can then be used to receive. And there's the 'Close' button, that seems to be doing the same thing i.e. closing the modal. Plus, there's no real way of 'resetting' your changes which is the usual thing we have: a confirm button and a cancel. I'm not sure what is the best solution here, but we could have: - Close (which updates the underlying table) - Cancel link (which resets any changes you've made) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 6903] Quantity for odering from suggestion should not default to 0
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6903 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=33867 -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 32372] New: Calculate hold waiting expiration based on days closed
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32372 Bug ID: 32372 Summary: Calculate hold waiting expiration based on days closed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently the ExcludeHolidaysFromMaxPickUpDelay is an on or off function. This is problematic with libraries that are closed several days in a week. It would be helpful if there were a threshold that could be set for this setting. The question would be, what kind of a threshold? For example, if ReservesMaxPickUpDelay is set to 7, and a pickup library is closed for 4 days in a week, if ExcludeHolidaysFromMaxPickUpDelay does not use the calendar, the expiration on the waiting hold will likely fall on a closed day, and also reduce the number of opportunities to be picked up. However, if ExcludeHolidaysFromMaxPickUpDelay is set to use the calendar, that same library will end up holding the item for more than two weeks to fulfill the 7 days. If ExcludeHolidaysFromMaxPickUpDelay uses the calendar, it would be helpful if there were an option to extend the ReservesMaxPickUpDelay to the closest open day past the closed dates. Perhaps something like MaxReservePickupExtentension, in which if it is blank or set to 0, it does nothing, like Koha does currently, but if it is set to a number of days, it would extend the expiration past the close date to the next open day that falls within the number of days defined. For example, ReservesMaxPickUpDelay is set to 7, and our proposed MaxReservePickupExtentension setting is set to 7 as well, and the pickup library is closed Sunday, Monday, Wednesday, and Friday. The pickup library receives the item on Tuesday, and instead of expiring on the following Monday when they are closed, Koha would look to the next open day (within 7 days past ReservesMaxPickUpDelay), which would be the following Tuesday. If there is no open days within the extra days defined in MaxReservePickupExtentension, it would keep the original expiration date, or more accurately, expire on the last open day before the closed expiration date. I hope that makes sense. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1