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

[Bug 22718] New: Authorized value for not for loan not showed in cataloging search results
by bugzilla-daemon＠bugs.koha-community.org 02 May '23

02 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22718 Bug ID: 22718 Summary: Authorized value for not for loan not showed in cataloging search results 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: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- In the search results in cataloging module (staff client interface), the reason why an item is "not for loan" isn't showed (in the Location column) and can create some confusing situation. For example, some schools put the authorized values for online items and they can't be available for a physical loan but are always available. Are we able to add in the authorized value for the "not for loan" status, something like "not for loan (authorized value)" ? In the same manner as it appears in a normal search in the catalog. In the cataloging module, the info only appears in the detailed view of the item. Thanks, Alexandre -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 33614] New: Templates contain problematic references to local login
by bugzilla-daemon＠bugs.koha-community.org 02 May '23

02 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33614 Bug ID: 33614 Summary: Templates contain problematic references to local login Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Bug 31064 wrapped the local login fields with a "local-login" class. However, if you hide the local login fields using this class, there are still references to local login in the SSO implementations where they say things like the following: -- Sorry, the CAS login also failed. If you have a local login you may use that below. If you have a local account, you may use that below. If you do not have a Shibboleth account, but you do have a local login, then you may login below. If you do not have a Google account, but do have a local account, you can still log in: -- These references should either include the "local-login" class so they can be hidden, or these references should be removed. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 31863] New: Advanced cataloging editor no longer auto-resizes
by bugzilla-daemon＠bugs.koha-community.org 02 May '23

02 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31863 Bug ID: 31863 Summary: Advanced cataloging editor no longer auto-resizes 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The advanced cataloging editor no longer automatically resizes the height of the CodeMirror editor, prior to 22.05 it did. To recreate: 1. Turn on 'EnableAdvancedCatalogingEditor' 2. Go to a record with enough MARC data that it should take up the entire width of your screen, 3. The CodeMirror editor will only be 300px. 4. Prior to 22.05 it would dynamically adjust to the height of your screen. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 33536] New: If staff member only has catalogue permission, search bar is hidden
by bugzilla-daemon＠bugs.koha-community.org 01 May '23

01 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33536 Bug ID: 33536 Summary: If staff member only has catalogue permission, search bar is hidden Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a staff member with only the catalogue permission (permission to access the staff interface), the search bar at the top of the page is hidden. You have to click "Search catalog" and then it appears. I guess they wouldn't know that it's not usually like this, but normally, the search bar is visible at the top of the page. To reproduce: 1. Create a staff patron and give them only the catalogue permission 2. Log into the staff interface with that account --> No search bar at the top of the page 3. Click "Search catalog" in the green bar at the top of the page --> Search bar appears Since it's their only option, I think the search bar should be displayed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 28093] New: Additional configuration option(s) for Shibboleth-only mode
by bugzilla-daemon＠bugs.koha-community.org 01 May '23

01 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28093 Bug ID: 28093 Summary: Additional configuration option(s) for Shibboleth-only mode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: Boze.1(a)nd.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Regarding bug 18506 , in the staff client with Shibboleth Only Mode enabled, when one logs out, the user is immediately logged back in to the staff client. I understand that this is the intended behavior and could be solved by using Single LogOut (SLO). SLO, however, would log the user out of all current Shibboleth sessions, which would not be desirable (for us). In addition, if the user is already logged in to Shibboleth, when visiting the staff client for the first time, the user is automatically logged in without seeing a login page. We would find it preferable if there were an option for Shibboleth-only mode (in the staff client) to have a landing page that would prompt the user to log in (whether or not the user had already authenticated). If the user was already authenticated, the user would simply be passed on to the staff client without needing to provide credentials. On logout, the user would return to the landing page but not be logged out of Shibboleth. Another alternative could be to have a new option that would disable local logins (except for self checkout) if some other authentication method (CAS, Shibboleth) has been activated. Basically this would look the same as the current login page, but with no option for local login. On logout, the user would be returned to the login page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 33628] New: Show item info in self check-in module
by bugzilla-daemon＠bugs.koha-community.org 01 May '23

01 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33628 Bug ID: 33628 Summary: Show item info in self check-in module 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: mirjam.vantieghem(a)etf.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently (we are running on Koha 21.11) when returning items with the self check-in module, only the barcodes are displayed after initial input and after confirmation of the check-in. It would be more user-friendly if also the title/author and call number would be displayed, as is the case for the self check-out module. Anyone who knows what code is needed for this? Thank you! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33240] New: After the latest update koha is not calculating the fine. Previously it was calculating.
by bugzilla-daemon＠bugs.koha-community.org 01 May '23

01 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33240 Bug ID: 33240 Summary: After the latest update koha is not calculating the fine. Previously it was calculating. Change sponsored?: --- Product: Koha Version: 22.11 Hardware: PC OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: dhanestraj(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 01 May '23

01 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 --- Comment #13 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #12) > You are right that different subdomains will create separate sessions, but I > think the 99% is wrong. Koha used ports for a long time in its default setup > and there are still reasons why you would want to do so. We do, with > packages, use ports, for the installations we support. > > And it doesn't solve the problem here... different sessions, one timeout. > How could you attach a different timeout to each? For your case, I think you'd need different cookie names for OPAC and Staff. Mostly would involve refactoring... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 01 May '23

01 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #240 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- (In reply to Katrin Fischer from comment #236) > (In reply to Nick Clemens from comment #235) > > (In reply to Aleisha Amohia from comment #234) > > > There are lots of signoffs on these patches, can this be marked Passed QA? > > > > Hi Aleisha, > > > > It appears I was wrong in comment 187, see comment 222 > > > > It is a question of how the fallback should work, so we either need a DB > > update, or to change the expectation for when a rule is not set > > It sounds like this needs a little bit more work? Attached an atomic update patch, not sure how it affects the bug status. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 01 May '23

01 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #239 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- Created attachment 150439 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150439&action=e… Bug 8367: Add holds_pickup_period fallback circulation rule -- You are receiving this mail because: You are watching all bug changes.

1 0