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

[Bug 10060] Allow adding a branch parameter to the web-based self check to indicate library its used at
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10060 --- Comment #37 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I wonder if using separate "OPAC views" and the system preference overwrite would also be an approach as a possible workaround? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10060] Allow adding a branch parameter to the web-based self check to indicate library its used at
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '25

16 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10060 --- Comment #36 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Christopher Brannon from comment #35) > (In reply to Katrin Fischer from comment #33) > > (In reply to Christopher Brannon from comment #30) > > I totally understand the requirement for consortia, but wondering why you > > say this affects your stats. Can you explain how you solved it now or where > > this effect comes from? > That software is no longer an option, so going to Koha's self check, we have > to use the auto login since most library self checks don't have a keyboard > connected. But we only have the option to use one account to login to with > the auto login. So, we can capture stats per branch. As Christopher mentions here, a lot of libraries use AutoSelfCheckID to log into the self-checkout. Since there can only be one AutoSelfCheckID, all checkouts at all the different branches will be checked out from that user. In the stats, this means the branch associated with checkout will always be the same. I've verified this in my own production installs. (Back in 2013, Liz mentioned even worse issues like the circ rules being applied based on the self-checkout user and not the patron. I haven't looked into that, but that's worth looking at too.) -- Locally, we create "Local" system preferences of "AutoSelfCheckID" suffixed with a branchcode, which allows different branches to have different "AutoSelfCheckID". This is a workaround which won't work so well in the Koha community I think. The best place to put it would probably be the "branches" table, but we'll have to consider the security/permissions ramifications of that, since the current permission required is "manage_sysprefs" and it would move to "manage_libraries". Arguably an understandable change but one worth documenting at the very least. Additionally, each branch must startup their self-checkout using a ?branch= parameter. After that initial visit, the branch parameter gets moved into hidden inputs, but a better place to put it would be in the login session of the self-checkout user. It could be nice to require an additional unguessable code as well so that patrons couldn't manipulate the URL to manipulate the branch used. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14670] Add 'cite' option to detail page in OPAC
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '25

16 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14670 Serhij Dubyk <dubyk(a)ukr.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dubyk(a)ukr.net -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39349] New: Ability to fix position of the n first columns of tables
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '25

16 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39349 Bug ID: 39349 Summary: Ability to fix position of the n first columns of tables Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 It would greatly improve usability of large tables if the n first column could be defined as having a fixed position. This could be an option in a admin/columns_settings.pl See as an example (with FixedColumns datatable property) : https://www.irsst.qc.ca/Resources/IrsstModules/DataTables-1.9.4/extensions/… It could be done in combination with https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39127 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 39347] New: Supplementary fields visibility in tables should be manageable by staff
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '25

16 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39347 Bug ID: 39347 Summary: Supplementary fields visibility in tables should be manageable by staff Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 If a supplementary field is created with the "searchable" option (in ERM module for instance), it is displayed in the appropriate table. But staff is currently not able to hide the column in the same way as the standard column (with the "column" gear) It could be useful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 38982] New: OpacLibraryInfo doesn't respect news expiration date
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '25

15 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38982 Bug ID: 38982 Summary: OpacLibraryInfo doesn't respect news expiration date Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If you create an OpacLibraryInfo HTML customisation for a particular library and give it an expiration date in the past, it will continue to display in the OPAC. To reproduce: 1) Go to Tools > HTML customisations 2) Create a new entry, specify a library, and give it an expiration date of yesterday (or earlier) 3) Then go to the OPAC and look at the Libraries page (cgi-bin/koha/opac-library.pl?branchcode=XXXXX). The news item will still be visible. 4) Also, if you do a catalogue search for an item in that library, look at the holdings in the search result, and in the Current and Home Library columns, an (I) information alert will show which when clicked will still show the expired news item. Once the expiry date has been reached, this news item should not display in the OPAC at all. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 39343] New: Calculate a standard cost of ILL request based on patron category and type of request
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '25

15 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39343 Bug ID: 39343 Summary: Calculate a standard cost of ILL request based on patron category and type of request Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com It could be nice to calculate automatically a standard cost of an ILL request according to patron category and type of request. This default cost could be edited if needed. For example the library could define a cost of 10 $ for a book request made by a student, a cost of 5 $ for an article request made by a teacher, a cost of 0 $ for a thesis made by a teacher, etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 39342] New: Apply a default filter by library on the table of ILL requests, based on connexion library
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '25

15 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39342 Bug ID: 39342 Summary: Apply a default filter by library on the table of ILL requests, based on connexion library Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com In multibranch systems where each branch manage its ILL requests, it would be nice to apply a default filter by library on the table of ILL requests, based on connexion library of staff user. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 39341] New: Bibliographic records created for ILL should be hidden in OPAC
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '25

15 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39341 Bug ID: 39341 Summary: Bibliographic records created for ILL should be hidden in OPAC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Bibliographic records created for ILL should be hidden in OPAC. They are created for technical reasons, and showing them in searches can mislead patrons. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 39340] New: Use of $HTMLtags filter should require another prefilter
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '25

15 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39340 Bug ID: 39340 Summary: Use of $HTMLtags filter should require another prefilter Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com t/lib/QA/TemplateFilters.pm thinks that using $HTMLTags is enough to say you've filtered, but $HTMLTags does no escaping so it isn't enough. You should always either use | html | $HTMLTags or if your string is already escaped use $raw | $HTMLTags to say you've thought about it. The fix to find them is obvious, just remove line 149 so we don't return if we see $HTMLTags, but I don't know how to fix the part that fixes missing filters. Since we've already fixed the cases where we were only using $HTMLTags on a TT variable (as security bugs), what's left is a bunch of strings in koha-tmpl/intranet-tmpl/prog/en/modules/about.tt and a mix of values from koha-conf.xml and the string "127.0.0.1" in koha-tmpl/intranet-tmpl/prog/en/modules/installer/step2.tt The fix for the values from koha-conf.xml is easy, they should be | html filtered. And at first the strings seemed easy to me, just give them | $raw to say we looked at them, but is that right? Is "[% "borrowers" | $HtmlTags tag="strong" %]" done that way to keep that table name from being translatable, so we know it will never need to be escaped? -- You are receiving this mail because: You are watching all bug changes.

1 1