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

[Bug 43030] New: Add generic own-resource (self-access) authorization to the REST API
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43030 Bug ID: 43030 Summary: Add generic own-resource (self-access) authorization to the REST API Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- This patch adds a generic mechanism for REST API endpoints to allow access to a caller's own resources without requiring the broader module permission (for example, a staff member managing their own lists, or viewing/editing their own patron record, without list_borrowers/edit_borrowers). Today, authorization is all-or-nothing: an endpoint's x-koha-authorization block requires a specific module permission, with no way to grant reduced access based on ownership of the record. Several controllers (Lists, AdvancedEditorMacro, Patrons/Password, Patrons/SelfRenewal) work around this today with inconsistent, ad hoc ownership checks that do not share a common implementation. This patch introduces: - Koha::Object->is_owned_by($patron) and Koha::Objects->owned_by($patron), a shared ownership interface implemented per class (identity based for Koha::Patron, owner field based for Koha::Virtualshelf) - An allow-owner flag on x-koha-authorization, checked in Koha::REST::V1::Auth, that admits an authenticated caller lacking the module permission when the resource is their own - Koha::REST::Plugin::Objects integration so objects.find and objects.search enforce/scope by ownership automatically, without each controller reimplementing the check, and while continuing to support paging, embeds, and existing query parameters - Write path guards so a caller admitted only via ownership cannot create a resource owned by someone else or reassign ownership away from themselves Permission continues to take priority: a caller who holds the module permission is unaffected and retains full, unrestricted access exactly as today. Ownership is only consulted for callers who lack the permission. Initial scope covers the Lists (virtualshelves) and Patrons endpoints, chosen to exercise both ownership shapes (owner field and identity match). Other existing ad hoc self checks are left as follow up work. Test plan: 1. Apply the patches and run the test suite for the affected modules: prove t/Koha/Object.t t/Koha/Objects.t t/db_dependent/Koha/Virtualshelves.t t/db_dependent/Koha/Patrons.t t/db_dependent/api/v1/patrons.t t/db_dependent/api/v1/lists.t 2. As a staff user without any list/shelf permission, confirm GET /api/v1/lists returns only your own lists, and GET /api/v1/lists/{id} succeeds for your own list and returns 403 for someone else's 3. As a staff user without borrowers permissions, confirm GET and PUT /api/v1/patrons/{patron_id} succeed for your own patron_id and return 403 for another patron_id 4. As a staff user with the relevant module permission, confirm both endpoints behave exactly as before (full, unrestricted access) 5. Confirm creating/updating a list while lacking the module permission cannot set the owner field to another patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 43031] New: Construct more complete 773 content when creating a child record using EasyAnalytics
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43031 Bug ID: 43031 Summary: Construct more complete 773 content when creating a child record using EasyAnalytics Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Bug 39545 expanded the subfields created when linking records, however, EasyAnalyitics does not use the same method, and does not get the same subfields - we should use a single method here -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 27507] New: Search host record using control number identifier / organization code
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27507 Bug ID: 27507 Summary: Search host record using control number identifier / organization code 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 11175 In /cgi-bin/koha/catalogue/detail.pl currently if you are viewing a record with 773w field the page shows "In: XXXX" with a search link to the host record. Currently when the 773w field format is in the LOC format of (OrgCode)ControlNumber we only search using the ControlNumber part. When importing records to Koha from different databases it is necessary to search also using the organization's code that is in the parentheses – otherwise we get in the results also unrelated records from other organizations. We need the 003 / Control-number-identifier search addition from bug 11175 to implement this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 [Bug 11175] Show the parent record's component parts in the detailed views -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 21820] New: Zebraqueue should not be added to
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21820 Bug ID: 21820 Summary: Zebraqueue should not be added to Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com In bug 20244 we identified that the zebraqueue is still being appended to when the searchengine preference is set to ElasticSearch.. unfortunately zebra may still be in use in parallel to Elastic to provide a public SRU/z3950 gateway.. as such we can't bind on just the syspref to know whether we should stop adding to the zebraqueue or not. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[Bug 41268] New: Circulation rules script has many conditionals
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41268 Bug ID: 41268 Summary: Circulation rules script has many conditionals Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Focusing on delete-branch-item-rule operation we have four code paths: 1 - if the branch is '*' and itemtype is '*' 2 - if branch is '*' and itemtype is specific 3 - If branch is specific and itemtype is '*' 4 - if branch is specific and itemtype is specified The only difference in these being that we pass 'undef' instead of '*' when star is set. I don't undertstand why we can't set a variable to 'undef' if necessary? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 41564] New: Tidy kohaTable block - admin
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41564 Bug ID: 41564 Summary: Tidy kohaTable block - admin Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 85

[Bug 41561] New: "tab" variable in admin/aqbudgetperiods.pl, tt is not used and should be removed
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41561 Bug ID: 41561 Summary: "tab" variable in admin/aqbudgetperiods.pl,tt is not used and should be removed Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 8117 admin/aqbudgetperiods.pl my $tab = $input->param('tab') ? $input->param('tab') - 1 : 0; This is never used. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8117 [Bug 8117] Divide budget periods into two tabs -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 38436] New: Unable to hide a column in the holdings table in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38436 Bug ID: 38436 Summary: Unable to hide a column in the holdings table in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major 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 In the holdings table in the staff interface, if a column has a value, it is show regardless of the table settings. I think this is a regression from previous behaviour. I tested it on 23.05 and 24.05 and the table settings are taken into account and hide the undesired column. A use case example is for single-library system who want to simplify/shorten the holdings table, they might choose to hide the holding library column as it's always going to be the same as the home library. Having those two columns only doubles the information uselessly for them. To recreate : 1. View a record in the staff interface 2. In another tab, go to Administration > Table settings > Catalog > holdings_table and check 'is hidden by default' for holdings_holdingbranch 3. Go back to the tab with the record and refresh the page --> The 'Current library' column is still there -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 136

[Bug 33462] New: Force password change for new patrons
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33462 Bug ID: 33462 Summary: Force password change for new patrons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Patrons that register via OPAC create whatever password they want. But when staff create a patron account, patrons are given a password. It would be preferred if patrons were forced to change their password after first logging in when a staff member creates the account. Unfortunately, the password expiration field is not available when creating the account. It is only editable after. It would be ideal if the password field were shown, even when adding a new patron, and the patron category setup page had an option next to expiration settings to force patron to change password at login when entered by staff. Then, when a staff member is adding the new patron, the date could be defaulted to today. The OPAC self registration would not need to do this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 121

[Bug 42692] New: Typo: regarless
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42692 Bug ID: 42692 Summary: Typo: regarless Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Found while translating main: on notices regarless of message transport type. (This should be a complete URL, starting with <code>http:// </code>.) Should be in system preference description of AllNoticeStylesheet, -- You are receiving this mail because: You are watching all bug changes.

1 15