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

[Bug 37308] New: Add user-agent to SUSHI outgoing requests
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '24

04 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37308 Bug ID: 37308 Summary: Add user-agent to SUSHI outgoing requests Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Some SUSHI endpoints are returning Forbidden 403 by Cloudflare. Adding the same pattern utilized in Overdrive.pm has fixed the issue: $ua->agent( 'Koha/'.Koha::version() ); -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 36805] New: Separate OPACSearchForTitleIn content from markup
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '24

01 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 Bug ID: 36805 Summary: Separate OPACSearchForTitleIn content from markup Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The OPACSearchForTitleIn system preference expects the user to be able to enter their list of links using the correct markup for them to be displayed in the "More searches" Bootstrap dropdown. As Bug 35844 shows, this content can get out of date with Bootstrap upgrades. I think we might want to separate the link content from the markup. My suggestion is that we ask the user to enter each link on one line, with URL pipe-separated from link text, e.g.: https://worldcat.org/search?q={TITLE}|Other Libraries (WorldCat) We can parse that in the template: [% FOREACH line IN OPACSearchForTitleIn.split('\n') %] [% part = line.split('\|') %] <a class="dropdown-item" href="[% part.first | html %]" target="_blank">[% part.last | html %]</a> [% END %] Does that sound reasonable? -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 28082] New: Add acquisitions toolbar to vendors on vendor search page
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '24

01 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28082 Bug ID: 28082 Summary: Add acquisitions toolbar to vendors on vendor search page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org We can improve consistency and expand functionality be adding inclusion of the acquisitions toolbar include on the vendor search results page. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 37970] New: Show the description of borrowers.primary_contact_method instead of code
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '24

01 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37970 Bug ID: 37970 Summary: Show the description of borrowers.primary_contact_method instead of code Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org If I have <<borrowers.primary_contact_method>> in my HOLD_SLIP, the primary contact method in my patron's record will be shown by its code instead of the description, wich is a problem for a non-english Koha. Right now, for exemple, the slip will say "Phone" instead of "Téléphone principal" even tho the rest of the slip is in french. Thanks -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 31208] New: "Check for embedded item record data" should default to "No"
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '24

01 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31208 Bug ID: 31208 Summary: "Check for embedded item record data" should default to "No" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, "Check for embedded item record data" in stage-marc-import.pl defaults to "Yes", but I doubt that the majority of libraries would want to check for embedded item record data. (By extension, I think it would be good to default "How to process items:" to "Ignore items" instead of "Always add items" - just to be on the safe side.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 31755] New: Store biblio OPAC visibility in biblio table
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '24

01 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31755 Bug ID: 31755 Summary: Store biblio OPAC visibility in biblio table 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 At the moment, you have to interrogate the MARCXML to determine if a record is suppressed using OpacSuppression, and you have to iterate through all of a bib's items to see if it's hidden/suppressed using OpacHiddenItems and OpacHiddenItemsHidesRecord. As Tomas said at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31161#c21, it would make sense to have a "suppressed" field in the biblio table so that we can determine a biblio record's OPAC visibility using a simple SQL query. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 37519] New: Display MARC 340 information on the OPAC
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '24

01 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37519 Bug ID: 37519 Summary: Display MARC 340 information on the OPAC Change sponsored?: --- Product: Koha Version: Main 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 libraries that want to show the MARC 340 "Physical medium" information on the OPAC. At the moment, I'm not quite sure of the best way to render this information in a way that will make sense to end users, and not overly crowd the UI. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 26168] New: Create admin Linux user "koha" which is member of all *-koha instance groups
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '24

01 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26168 Bug ID: 26168 Summary: Create admin Linux user "koha" which is member of all *-koha instance groups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 It would be useful to have an administrative Linux user "koha" which is a member of all *-koha instance groups. The high level use case is a non-root (daemon) service that can run "koha-shell kohadev -c 'command'". At the moment, you could just run that (daemon) service as root, but ideally it would be better to run it as a less privileged user. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 25635] New: overdue_notices.pl dies if no overdue rules are defined
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '24

01 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25635 Bug ID: 25635 Summary: overdue_notices.pl dies if no overdue rules are defined Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal 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 overdue_notices.pl dies if no overdue rules are defined, but there are many cases where you might not want any overdue rules to be defined. (If you're running overdue_notices.pl within koha-foreach, koha-foreach will now die on the first instance it encounters that has no overdue rules defined.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 28232] New: koha-plack dies even when there is work to for multiple instances
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '24

01 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28232 Bug ID: 28232 Summary: koha-plack dies even when there is work to for multiple instances Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 run "koha-plack --stop $(koha-list --enabled --plack)", it won't stop any instances if the first instance in the list is already stopped. This doesn't really make sense. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1