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

[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 27765] New: Unable to set a custom order to library branches on opac-library.pl
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27765 Bug ID: 27765 Summary: Unable to set a custom order to library branches on opac-library.pl 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: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org Per this comment on #13388 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13388#c28 it's not possible to rearrange the order of library branches on the "Libraries" opac-library.pl page, they must be sorted alphabetically ascending. Alphabetical ordering isn't ideal for all library systems. For instance, we have three branches: Oakland, San Francisco, and a small Materials Library that's based in SF. Alphabetically, Materials comes first but it's the least generically useful. We generally list it last when we have the option e.g. when presenting branch hours. While this bug is related to the OPAC, I suspect that Koha Administration > Branches is ultimately what needs a change, adding an ordering component to the information stored about library branches which controls the opac-library.pl display. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 29607] New: addorderiso2709: The stored discount when importing an order from a file is invalid
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29607 Bug ID: 29607 Summary: addorderiso2709: The stored discount when importing an order from a file is invalid Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: christophe.torin(a)univ-rennes2.fr QA Contact: testopia(a)bugs.koha-community.org In the Acquisitions module : - Create a new vendor with a discount (Or select one that has a discount). Here the discount will be 25% - Create a new basket or select an existing one - Select "Add to basket" => From a staged file - Add an order from one of the file ==> Here, you can use a specific discount for the order, to override the vendor discount. The result should be quite the same if you do, but with this discount - The order is created ==> Modify the order - The discount is 0.25% instead of 25% Note that the prices are initially correctly calculated, but the discount value will appear as false. Plus, if you modify the order and change a price, the wrong discount will be used. In database, the discount is indeed stored as a value between 0 and 1, but only in that case (for the vendor, it is the actual percentage, and when you create an order from anoher source, it is stored correctly) This was reported on Koha 20.11, but is still relevant on master. In the code, this happens because the discount value is first divided by 100 to calculate the price, but it is that divided value that is stored in database, instead of the whole percentage value. On the master branch, in the file Koha/acqui/addorderiso2709.pl, the line where it's done are lines 166, 279 and 340 What I would suggest is : - Remove the division per 100 on those lines (166, 279 and 340) - Divide per 100 only when calculating the price (lines 283, 285, 344, 346) ==> ( 1 - $c/100 ) instead of ( 1 - $c ) - In the template (for importing from file), add a "%" just to be clear that the discount is a percentage, and not a value between 0 and 1 I know there was a kind of security (divide by 100 if the input is > 1), but it could be the other way around (multiply by 100 if the input is < 1). But as it is based on the field that is in the form, with a simple "%" indication it should not be needed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 24310] New: Use Text::Lorem instead of String::Random in Test::Builder
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24310 Bug ID: 24310 Summary: Use Text::Lorem instead of String::Random in Test::Builder Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org That would help to get something more readable. Currently we generate a string of one word that is the size of the column. It produces a lot of overflow when displayed on the screen. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 31209] New: Add span with class info to enumchron data in circulation.tt, for better styling
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31209 Bug ID: 31209 Summary: Add span with class info to enumchron data in circulation.tt, for better styling 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the table issues-table of circulation.tt, enumchron data in added to the title between parentheses. There is no way to style this information differently from the title. We could add a span with a class to isolate this information. Alternatively, enumchron data could be moved in a new column -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 22693] New: ILL "Price paid" column does not appear in column configuration
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22693 Bug ID: 22693 Summary: ILL "Price paid" column does not appear in column configuration 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 Target Milestone: --- "Price paid" was added in bug 22121, it seems I forgot to add it to the column configuration list. Doh. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 30993] New: Translation: Unbreak sentence in upload.tt
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30993 Bug ID: 30993 Summary: Translation: Unbreak sentence in upload.tt Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr In translation, the sentence below is broken into 2 parts by the link. This makes it hard to translate as you can't move around words easily before and after the link for good grammar and are missing context: <span>Add values to the <a href="/cgi-bin/koha/admin/authorised_values.pl?searchfield=UPLOAD">UPLOAD authorized value category</a> otherwise all uploads will be marked as temporary.</span> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 31064] New: Local login is difficult to style using CSS
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '23

26 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31064 Bug ID: 31064 Summary: Local login is difficult to style using CSS 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org There are times where it would be nice to style the local login inputs. For my purposes, that's usually to hide them in favour of button/link provided by OpacUserJS, but I'm sure people could use it for other things too. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 29792] New: Transfers created from Wrong Transfer checkin are not sent if modal is dismissed
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '23

26 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Bug ID: 29792 Summary: Transfers created from Wrong Transfer checkin are not sent if modal is dismissed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 Depends on: 23092 To recreate: 1 - have an item in transit from Branch A to Branch B 2 - check the item in at Branch A 3 - get a Wrong Transfer message, click Print Slip or OK 4 - query the branchtransfers table, see that your original transfer was cancelled and a new one was made, confirm that new transfer has a datesent value 5 - repeat steps 1-3, but instead of clicking one of the buttons click outside of the modal to make it go away 6 - query the branchtransfers table, see that your original transfer was cancelled and a new one was made, confirm that new transfer DOES NOT HAVE a datesent value So that transfer is just hanging out as requested and the item needs to get checked in again to get it sent. This is a change in behavior, as before bug 23092 the second transfer would be sent immediately even if one clicked away from the modal without selecting anything. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23092 [Bug 23092] Add 'daterequested' to the transfers table -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 27074] New: When a subscription is closed, it still shows as current in OPAC
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '23

25 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27074 Bug ID: 27074 Summary: When a subscription is closed, it still shows as current in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com When a subscription is closed in the staff interface, it will still show as current (running) in the OPAC: Subscription from: 12/29/2019 to: now (current) This is due to the subscription history end date being empty. In order to fix this, you need to activate manual history and set it manually, lots of clicks. I suggest that we either automatically fill the subscription end date on closing the subscription (I think the predicted or receive date of the last issue would be good) or offer an option to do so. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2