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

[Bug 21135] New: Upon log in, user is redirected to account page instead of the page where they logged in from
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '23

28 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21135 Bug ID: 21135 Summary: Upon log in, user is redirected to account page instead of the page where they logged in from Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When a user clicks on a link "log in to ..." they are redirected to their account page instead of staying on the page they were on to do whatever they needed to log in to do. To reproduce : 1- In Administration > System preferences, enable TagsEnabled 2- Make sure TagsInputOnDetail is set to Allow 3- Go to OPAC, and do a search 4- Click on title to go to the details page 5- Click on the "Log in to add tags" link 6- Enter your login credentials in the popup window Result : user is redirected to "My account" Desired result : user is now logged in but stays on the record detail page Second case : 1- In OPAC, click on Lists > View All 2- Click on "Log in to create new lists" 3- Enter your login credentials Result : user is redirected to "My account" Desired result : user is now logged in but stays on the lists page -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 25972] New: SIP2 server doesn't have a TLS/SSL-enabled listener
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '23

28 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25972 Bug ID: 25972 Summary: SIP2 server doesn't have a TLS/SSL-enabled listener Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com I'm not super familiar with SIP2, but I don't see why we couldn't have a TLS/SSL-enabled listener for the SIP2 server. Most people use stunnel to secure their SIP2 server, but why not build in TLS/SSL support directly? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 19464] New: emailLibrarianWhenHoldIsPlaced email enhancement
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '23

24 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19464 Bug ID: 19464 Summary: emailLibrarianWhenHoldIsPlaced email enhancement Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: karen(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com A school library that I'm working with would like the email sent by the preference emailLibrarianWhenHoldIsPlaced to go the library where the hold is placed rather than the admin email address. Sending an email directly to the branch email address would be a really nice option for multibranch systems that want to use this system preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 24231] New: Create classes to the message that was created with sys pref UpdateItemLocationOnCheckin
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24231 Bug ID: 24231 Summary: Create classes to the message that was created with sys pref UpdateItemLocationOnCheckin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the introduction of this new system preference UpdateItemLocationOnCheckin, the cart to shelf system preference was removed and rolled into this one. However, the alert that comes along with this new system preference is not a welcome addition to the libraries that are using Cart to Shelf functionality. Prior to this, cart to shelf functionality was a backend process that would (without staff interaction) take an item that was checked in, move it to the cart. Now, when an item is checked in (at the system preference UpdateItemLocationOnCheckin has the value _ALL: CART - each time an item is checked in, the staff get a large yellow message box and an alert. If we add a class to this message or even 2 classes this would allow these alert/audio to be turned off for those libraries that don't wish to receive this yellow alert box with every checkin. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 27211] New: Shelving locations for holds
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27211 Bug ID: 27211 Summary: Shelving locations for holds 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 Every library handles holds differently, but one thing remains the same through most, if not all...when a hold is triggered, it waits somewhere in the building. Some libraries might have more than one shelving location. One issue that has always been a problem for libraries that have automatically expired holds, or any library that has a cancelled hold. Unless someone is going through each of the holds on the hold shelf daily, how do you find the item? If you look up an held item that has automatically expired (guessing on this, as we don't do this), or an item that is cancelled, the item shows the regular shelving location and that it is AVAILABLE. This is of no help to staff or the patron. One solution might be to use the CART feature, and update the temporary location to reflect a given shelving location for holds. There are a few issues for using this feature: 1) the CART location reverts back to the permanent shelving location after X amount of days. This would have to be overridden to stick until the item is actually not being held and is checked in, and then go through the regular CART routine, if any. 2) When triggering a hold, the hold would have to know which shelving location is being used. We could either define a default location that could be changed to a select few locations (maybe a HOLDLOC table?), so the default could be used without extra steps, OR even further, a default shelving location defined for each desk (I know the desk feature is part of an upcoming Koha upgrade). If staff don't want the public to know that the item is on a public hold pickup shelf, the OPAC description could simply read "See staff for assistance". Thoughts? Is this doable? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 17480] New: UpdateNotForLoanStatusOnCheckin preference requires space after colon
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17480 Bug ID: 17480 Summary: UpdateNotForLoanStatusOnCheckin preference requires space after colon Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 11629 YAML requires that there be a space after a colon, so the UpdateNotForLoanStatusOnCheckin preference does too: -1:0 will not work -1:<space>0 will work We should either handle this gracefully for the user (preferable, since this preference will only use numeric values), or update the preference's description to highlight the requirement. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11629 [Bug 11629] Add ability to update not for loan status on checkin -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 21700] New: Additional Patron information on purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '23

21 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21700 Bug ID: 21700 Summary: Additional Patron information on purchase suggestions Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org A library has suggested that it would be helpful to view the card type of the patron when managing purchase suggestions. For instance, if an item is not going to be purchased, the library would attempt to ILL the item, but since not all patron categories are eligible for ILLs, knowing the patron category from the beginning of the review process would be helpful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 26413] New: Reading history management from staff client.
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26413 Bug ID: 26413 Summary: Reading history management from staff client. Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently reading/circulation history tracking is controlled by settings in the Patron Categories with the Default Privacy options. Setting the Default Privacy setting to 'Default' means that keeping a reading history becomes an opt-out where a patron has to turn it off in their patron account from the OPAC. Setting the Default Privacy setting to 'Never' means that keeping a reading history becomes an opt-in where a patron has to turn it on through their patron account. This becomes a problem either way when working with patrons who are unable or unwilling to login to their patron account to select their preferred option. It would be nice to have an option in the patron account details that allows a staff member to flip the switch for the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 25856] New: Suspended holds should be styled differently on request.pl
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '23

17 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25856 Bug ID: 25856 Summary: Suspended holds should be styled differently on request.pl 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 looking at the list of holds on request.pl, it's not terribly obvious when a hold is suspended. It'd be great to make that line appear in a different color or something else immediately obvious. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 23923] New: OpacHiddenItems displays incorrect 'No results found' when all results on first page are hidden
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '23

16 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23923 Bug ID: 23923 Summary: OpacHiddenItems displays incorrect 'No results found' when all results on first page are hidden Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate you will need to hide a large portion of the catalog - essentially you need to perform a search where the first 20 or more records are hidden, you get a 'No results found' - then add offset=20 (or more) and see that the second page has results. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7