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

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 --- Comment #455 from Jake Deery (kwenoch) <jake.deery(a)openfifth.co.uk> --- Created attachment 207453 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207453&action=e… Bug 14962: On Display config changes for tables This patch adds the Display column to a number of tables, ready for the On Display module. Please see the test files commit for instructions on how to test this bundle of patches. Sponsored-by: ByWater Solutions Signed-of-by: Martin Renvoize <martin.renvoize(a)openfifth.co.uk> Signed-off-by: Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 --- Comment #454 from Jake Deery (kwenoch) <jake.deery(a)openfifth.co.uk> --- Created attachment 207452 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207452&action=e… Bug 14962: On Display changes to build suite This patch contains the essential changes required to get Koha to build the correct JavaScript and Vue modules for the new On Display module. Please see the test files commit for instructions on how to test this bundle of patches. Sponsored-by: ByWater Solutions Signed-of-by: Martin Renvoize <martin.renvoize(a)openfifth.co.uk> Signed-off-by: Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 --- Comment #453 from Jake Deery (kwenoch) <jake.deery(a)openfifth.co.uk> --- Created attachment 207451 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207451&action=e… Bug 14962: Add breakAfter as option on Vue FormElement This patch adds the ability to add a linebreak after form elements in Vue, to facilitate form element grouping. == TO TEST == a) apply the rest of Bug 14962 b) confirm that on cgi-bin/koha/display/displays/add there is spacing after groups of form fields within a group of form elements == SIGN OFF == Sponsored-by: ByWater Solutions Signed-off-by: Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 --- Comment #452 from Jake Deery (kwenoch) <jake.deery(a)openfifth.co.uk> --- Created attachment 207450 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207450&action=e… Bug 14962: Add show action as KohaTable option This patch adds a show action option which can be used in Vue KohaTables. This has future implications for Vue as a more granularly controlled facet of Koha. == TO TEST == a) apply all of Bug 14962 b) enable UseDisplayModule syspref c) create a user with only access to the staff client and view_displays d) create a display at /cgi-bin/koha/display/displays/add e) login as the user you just created f) go to /cgi-bin/koha/display/displays g) notice how the list table only shows a Show action on the right-hand side of the table row == SIGN OFF == Sponsored-by: ByWater Solutions Signed-off-by: Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 --- Comment #451 from Jake Deery (kwenoch) <jake.deery(a)openfifth.co.uk> --- Created attachment 207449 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207449&action=e… Bug 14962: Factor missing permissions into http-client This patch ensures when required_permissions comes back in an API response, a proper message is displayed to the user, listing out what permissions are missing. == TO TEST == a) create a user with only permission to access the staff client, and manage_budgets under acquisitions b) login as this user c) go to /cgi-bin/koha/acquisition/vendors?supplier= d) notice the unhelpful 'Error: Authorization failure. Missing required permission(s).' == APPLY PATCH == e) repeat steps c-d f) notice there is now a dump of the json returned by the api == SIGN OFF == Possible follow-up work: we should sort the API's required_permissions response out so it returns a predictable and sensible output that can have translatable strin gs attached to it, so we can stop dumping the raw JSON out and start providing a human-readable permission description. Sponsored-by: ByWater Solutions Signed-off-by: Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

1 0

[Bug 42548] New: Add possibility to list multiple barcodes or one biblionumber on attach item action
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42548 Bug ID: 42548 Summary: Add possibility to list multiple barcodes or one biblionumber on attach item action 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: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hello When you want to attach items on biblio record it will be useful to add a list of barcodes or a biblionumber (if you want to attacn all items in one shot). So this patch will introduce this feature, I will add bug 6532 and 42451 dependants cause I added a method to move all items in a batch and this patch adds refactoring of this to prevent duplicate code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 43407] New: Database permissions, different users and "schemas"
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43407 Bug ID: 43407 Summary: Database permissions, different users and "schemas" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: mark(a)hofstetter.at QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- A standard Koha instance defines one database account in koha-conf.xml. Koha::Database uses this account for normal DBI and DBIx::Class connections. The Debian installation creates this account with ALL PRIVILEGES on the complete instance database. Consequently, the same database identity is used by the OPAC, staff interface, background workers, command-line tools, database updates, reports, and plugins. It can read and modify operational data, but can also create, alter, and drop database objects. The same logical database/schema contains data with very different ownership and lifecycle requirements: * primary transactional and catalogue data; * configuration and mapping data; * denormalised or generated data; * transient state such as sessions, saved report results, tmp_holdsqueue, and zebraqueue; * plugin-owned tables and indexes. The problem is not merely that Koha uses one database. The problem is the assumption that one highly privileged service account and one schema should be used for every workload. Separate database identities could materially improve security by applying the principle of least privilege. For example: * An OPAC database account could have SELECT access to catalogue, availability, and public configuration data, no access to unrelated tables such as acquisitions or administrative plugin data, and narrowly scoped INSERT or UPDATE permissions only for supported patron operations such as holds, renewals, suggestions, tags, and account changes. It would have no DDL privileges. * A reports account could be strictly read-only. Preferably it would query an allowlisted of tables/views instead of receiving SELECT access to every table. This would also permit sensitive patron, authentication, or financial columns to be excluded or masked. * A staff runtime account could receive the DML permissions required for normal staff operations but no CREATE, ALTER, or DROP privileges. * A dedicated migration account could hold DDL privileges and only be made available while installing or upgrading Koha. Web applications and background workers would not have access to these credentials. * Background workers, search components, and plugins could use separate accounts with permissions limited to their queues, indexes, caches, or plugin-owned schemas. This would reduce the impact of a compromised component. For example, an OPAC vulnerability would not automatically provide access to every Koha table or permit schema changes. A reporting error or malicious report could not modify production records. Separate identities would also improve auditing, credential rotation, and attribution of database activity. Database permissions would not replace Koha's application-level authorization. Some OPAC features require writes, and permissions would need to reflect enabled features. The initial implementation could therefore be optional and use documented privilege profiles rather than attempting an immediate mandatory split. A possible incremental improvement would be support for named database connections in koha-conf.xml. Individual interfaces and components could select an appropriate connection, while the current single-account configuration remains the compatibility default. Such support would need defined behaviour for installation, upgrades, transactions, connection selection, backups/restores, testing, reporting, and deployments where cross-schema foreign keys are unavailable or undesirable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 39291] New: Edifact should record an error and move on if there's a problem with transport filename change
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39291 Bug ID: 39291 Summary: Edifact should record an error and move on if there's a problem with transport filename change Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Edifact renames files to signify that they have been processed.. this is part of the specification. However, if somehow there's already a file with the name you are attempting to change to, currently the process just aborts. We should really record the error somewhere and move on to the next file otherwise we stop processing files until the erroneous file is cleaned up on the vendors site. This is rare though.. so perhaps a low priority.. leaving it here just in case someone else hits this and it gives some good clues ;) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43758] New: Accessibility: Add missing legend to login form fieldset in OPAC
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43758 Bug ID: 43758 Summary: Accessibility: Add missing legend to login form fieldset in OPAC Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org Target Milestone: --- The login form contains a <fieldset> without a corresponding <legend> element. Accessibility testing reports: Fieldset missing legend A fieldset does not have a legend. The affected markup is: <fieldset class="action"> <input type="hidden" name="login_op" value="cud-login"> <input type="submit" value="Log in" class="btn btn-primary"> </fieldset> A <fieldset> should have a <legend> that describes the group of form controls it contains. Without a legend, assistive technologies may not have an accessible description for the grouped controls. Since this fieldset appears to contain only a hidden input and the "Log in" submit button, we should also determine whether a <fieldset> is semantically necessary here. If it is needed, an appropriate <legend> should be added. Otherwise, the fieldset could potentially be replaced with a non-semantic container. Steps to reproduce Navigate to the login page. Run an accessibility check using WAVE or another accessibility testing tool. Inspect the login form. Observe that the <fieldset class="action"> element does not contain a <legend>. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0