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

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '24

06 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Pedro Amorim <pedro.amorim(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36241 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36241 [Bug 36241] ILL Batches are broken -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36240] New: Add links to "System information" warnings
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '24

06 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36240 Bug ID: 36240 Summary: Add links to "System information" warnings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org The example that made me think of this is: Warning The patron used for the self checkout module at the OPAC does not have the self_check => self_checkout_module permission. That tells me there is a problem with some patron, but then I have to either search for that patron by name (did I call it "self check" or "sco"?), or remember to look up the borrowernumber in the AutoSelfCheckID syspref, and then find the patron with that borrowernumber. It would be much more user friendly if there was a link directly to the patron in question, from the warning. The way this works today is that about.pl checks for the problem and if there is a problem it sets a variable that is passed along to the template, which renders the warning. So we need to find a way to also pass the borrowernumber (or other relevant information for other warnings.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 36238] New: C4::Context->preference doesn't cache values for non-existent sysprefs
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '24

06 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36238 Bug ID: 36238 Summary: C4::Context->preference doesn't cache values for non-existent sysprefs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you try to look up a system preference that doesn't exist, C4::Context won't cache a value for it. Overall, it is logical not to cache a system preference that doesn't exist in the systempreferences database table. However, maybe you distribute a plugin or template which uses a local system preference, and it only exists in some systems. On the systems missing the preference, you'll be doing a database call every time instead of using the cached value of nothing. This is suboptimal from a performance perspective. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 36225] New: Koha should warn if item group has holds group is being deleted
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '24

06 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36225 Bug ID: 36225 Summary: Koha should warn if item group has holds group is being deleted 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: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Have item hold groups enabled. 2. Have a hold on an item group on a record. 3. Delete the item group - no warning of existing holds. 4. Hold is now a bib-level hold. In some cases, this may be desirable behavior (like a library using one record for multiple year editions), but in others, like volumes of a work, this now-bib-level hold is not what the patron needs. Best solution would be a warning with option for the librarian to either cancel hold or transform into bib-level hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 29824] New: Allow for quick spine labels to be editable for printing
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '24

06 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29824 Bug ID: 29824 Summary: Allow for quick spine labels to be editable for printing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be handy if you could edit quick spine labels after you generate them. In some case you may want to remove to character or add a line break. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '24

05 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Lucas Gass <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36237 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36237 [Bug 36237] Improve set-library UI after 34478 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25917] New: Table settings for OPAC are all under biblio-detail
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '24

05 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25917 Bug ID: 25917 Summary: Table settings for OPAC are all under biblio-detail Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 When you go to Administration > Table settings > OPAC, currently there are 4 tables that can be configured: course-items-table, course_reserves_table, holdingst, subscriptionst. They are all four under the 'Page: biblio-detail' heading. However that is not true. course-items-table and course_reserves_table and not on the biblio-detail page, but rather on opac-course-details and opac-course-reserves respectively. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 34856] New: Move strings in messages.po back into their original file (or move everything into messages.po)
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '24

05 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34856 Bug ID: 34856 Summary: Move strings in messages.po back into their original file (or move everything into messages.po) 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr With all the developments that have been done on translatability, a lot of strings have been moved from staff-prog.po and opac-bootsrap.po to a new file called messages.po. I personally don't understand the purpose of this file. For example, why are some OPAC strings in opac-bootstrap.po and others in messages.po? Why are they not all in messages.po or all in opac-bootstrap.po? We could move opac strings back from messages.po back into opac-bootstrap.po and staff interface strings back into staff-prog.po. Or we could move everything into a single .po file. There are good arguments on both sides, and I am open to discussing the various options. I just want it to be less confusing for people who are translators and don't necessarily know the technical stuff behind the creation of these files. P.S. Note that I'm not talking about messages-js.po which is an entirely different thing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 21302] New: Link in 780/785 should search for $t in title and $a in author
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '24

05 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 Bug ID: 21302 Summary: Link in 780/785 should search for $t in title and $a in author Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When a record has a 780 and/or 785 field with both $a and $t, the link should search for the value in $a in the author index and the value in $t in the title index, combined with AND. Right now, it searches for both in the title index. Steps to reproduce: 1- If its not already in your cataloguing framework, add 780 $a and $t and 785 $a and $t (check the "Editor" box) 2- Search for a record and edit it 3- Add an author name in 780 $a and 785 $a 4- Add a title in 780 $t and 785 $t 5- Make sure both indicators for both fields are 0, so it should look like 780 00 $aAuthor1 $tTitle1 785 00 $aAuthor2 $tTitle2 6- Save the record and view it in "normal" view 7- Click the link created for Author1 Title 1 -> the search is ti,phr:Author1 Title1, but it should be au,phr:Author1 and ti,phr:Title1 8- Repeat step 7 with Author2 Title2, same result If possible, it would be great if all values were searched in their rightful index with "and" in between to narrow the search. 76X - 78X $a = author (same as 1XX or 7XX) $d = publisher, publication date or place (same as 260 $a, $b, $c or 264 $a, $b, $c) $e = language (same as 008/35-37) $f = publication place (same as 008/15-17) $k = series (same as 4XX or 8XX) $o = identifier number (same as 0XX) $p = title (same as 210) $s = uniform title (same as 240 or 243) $t = title (same as 245 or 130) $u = report number (same as 027) $x = issn (same as 022) $y = coden (same as 030) $z = isbn (same as 020) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 34991] New: Collapsed 245 subfields still show by default in Fast Add Framework
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '24

05 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34991 Bug ID: 34991 Summary: Collapsed 245 subfields still show by default in Fast Add Framework Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I was trying to further simplify the Fast Add bibliographic framework for a client and collapsing 245$h, 245$n, and 245$p doesn't work. I've only had the problem with field 245. I think it may be related to the fact that in the FA framework, it's in tab 0, but I'm not sure. To recreate: 1. Go to Administration > MARC bibliographic framework 2. Click Actions > MARC structure next to the Fast Add Framework 3. Click Actions > Edit subfields next to the 245 field 4. Change visibility of subfields as follows: - 6: uncheck Editor - 8: uncheck editor - a: (leave as is) - b: (leave as is) - c: (leave as is) - d: uncheck Editor - e: uncheck Editor - f: uncheck Editor - g: uncheck Editor - h: check Collapsed - k: uncheck Editor - n: check Collapsed - p: check Collapsed - s: uncheck Editor 5. Click Save changes 6. Go to Cataloging 7. Click the arrow next to New record and choose Fast Add Framework 8. Scroll down to 245 --> h, n, and p are visible but should be collapsed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3