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

[Bug 37637] New: Use the REST API to display items on the staff edit items view
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37637 Bug ID: 37637 Summary: Use the REST API to display items on the staff edit items view Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: samalau(a)gmail.com Reporter: samalau(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 33568 Currently, the additems table is rendered using the DB, which can cause performance issues for large amounts of items. It makes sense to switch to using the REST API (/api/v1/biblios/{biblionumber}/items) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568 [Bug 33568] Use the REST API to display items on the staff biblio detail view -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 36663] New: Biblio detail page - StaffDetailItemSelection hides table elements inconsistently
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36663 Bug ID: 36663 Summary: Biblio detail page - StaffDetailItemSelection hides table elements inconsistently Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, jonathan.druart(a)gmail.com Depends on: 33568 To reproduce: 1- Enable StaffDetailItemSelection 2- Visit a biblio page: http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=76 3- Notice there are no table configuration options on the top right (Columns, Export, Configure). 4- Click the "Show filters" link, notice the table configuration options now show, as well as top and bottom pagers, column filter inputs and search input. 5- Disable StaffDetailItemSelection 6- Visit a biblio page: http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=76 7- Notice that the table configurations options are visible, as well as top and bottom pagers, and search input. 8- Click the "Show filters" link, notice it now only governs the column filter inputs, the other elements mentioned in step 7 are always visible. This does not seem consistent, "Show filters" should behave the same regardless of the value of StaffDetailItemSelection, i.e. it should only hide or show the column filter inputs. Additionally, before bug 33568, I believe the configuration options showed by default (with StaffDetailItemSelection enabled) on k-t-d, and they don't anymore. Patch adding this behavior: https://github.com/Koha-Community/Koha/commit/0db4098 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568 [Bug 33568] Use the REST API to display items on the biblio detail view -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 33746] New: [omnibus] speed improvement
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33746 Bug ID: 33746 Summary: [omnibus] speed improvement 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 35191] New: Make entries per page configurable for items table on staff detail page
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35191 Bug ID: 35191 Summary: Make entries per page configurable for items table on staff detail page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 33568 The new API driven items view defaults to 20 per page. This is a bit low, it would be great if it could be configurable to a higher value per the table configuration. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568 [Bug 33568] Use the REST API to display items on the biblio detail view -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 32802] New: Bundle handling JS should be moved to an asset
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32802 Bug ID: 32802 Summary: Bundle handling JS should be moved to an asset 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29560, 31080, 31615, 32121 The item bundling Javascript has come quiet extensive.. it should be tidied up somewhat and moved into it's own asset file. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29560 [Bug 29560] Add option to create MARC links when adding items to bundles https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31080 [Bug 31080] Block adding the bundle item to its own bundle https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31615 [Bug 31615] Allow checkin of items bundles without verifying their contents https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32121 [Bug 32121] Show an alert when adding a checked out item to an item bundle -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 16122] New: Item record needs to keep Local Use count
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16122 Bug ID: 16122 Summary: Item record needs to keep Local Use count Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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 Like the "issues" field in the items table, there should be a field for "local_use" to keep the count of local uses. While this information is kept in the statistics table, it is a task to acquire, and if a library wants to keep bloat down on their tables, the statistics are pruned on a regular schedule, which means loss of valuable data. This counter would keep that valuable information in one field in each item record, rather than having a separate field for each instance in the statistics table. Unless it is vital to someone to know the exact moment a local use occurred, I am suggesting that this piece of information not be recorded in the statistics table any longer. This would significantly reduce the growth of the statistics table in general. Christopher -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 163

[Bug 15461] Add shelving location to holdings table as a separate column
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 Bug 15461 depends on bug 33568, which changed state. Bug 33568 Summary: Use the REST API to display items on the staff biblio detail view https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27769] New: Advanced editor shouldn't break copying selected text with Ctrl+C
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27769 Bug ID: 27769 Summary: Advanced editor shouldn't break copying selected text with Ctrl+C Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, nick(a)bywatersolutions.com Depends on: 17179 Bug 17179 added a shortcut for Ctrl+C to copy the line where the cursor is into the advanced editor's clipboard div. That only works if you don't have text selected. If you have text selected, the shortcut silently does nothing, but Ctrl+C, which I've used for decades to copy selected text, doesn't copy the text. Dozens of times a day, I copy the OCLC control number from a record, or the contents of an 024, do an advanced search for that number (where I can no longer actually see what record I'm replacing), and replace the record. Despite having now spent months trying to train myself that Ctrl+C has been broken (difficult training since I catalog both on a Mac, where Cmd+C has not been broken, and on Windows where it has), every couple of weeks I catch myself having just replaced a record with some record I had previously successfully right-click copied data from. How often do I *not* catch myself, and replace a record with a record for a completely different bib? Dunno, I'd really rather not think about that. The keyhandler looks like it'a a CodeMirror command, and the very scanty documentation says that a CodeMirror key handling command can return CodeMirror.Pass to let other handlers or the default behavior handle the key. Currently the handler does "return true" when it sees selected text and decides not to handle Ctrl+C. If instead returning cm.Pass would make the system clipboard work when text is selected, and the advanced editor clipboard work when no text is selected, that would be the best outcome. Second best would be deciding that silently causing the system clipboard to fail was a bad idea, and switching the default shortcut to something else. Yes, there is a system-wide option to change keys. For me, that means getting 14 people to agree on a different key, then starting the process of persuading an admin to make the change. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17179 [Bug 17179] Advanced editor: Add keyboard shortcuts to repeat (duplicate) a field, and cut text -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 40408] New: Typo in Manual - Pinter profiles
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40408 Bug ID: 40408 Summary: Typo in Manual - Pinter profiles Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de In the Cataloguing > Printer profiles section, there is typo in the heading: it says "Pinter" instead of "Printer". See https://koha-community.org/manual/latest/en/html/cataloging.html#pinter-pro… There also seems to be a formatting / alignment issue in the "Get there" line underneath as well: the string "Printer profiles" is on its own line when it shouldn't be. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 35115] New: ERM - Potential MARC data loss when importing titles from list
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35115 Bug ID: 35115 Summary: ERM - Potential MARC data loss when importing titles from list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: pedro.amorim(a)ptfs-europe.com CC: caroline.cyr-la-rose(a)inlibro.com, jonathan.druart+koha(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 To reproduce: 1) Enable ERMModule sys pref 2) Create a new public list, visit: /cgi-bin/koha/virtualshelves/shelves.pl 3) Click "New list" enter name, set public -> public 4) Click "Add items", enter 112\n113\n114 (new line for each), in "Biblio numbers" 5) Notice that all added biblios have quite a few MARC fields 6) Go to packages, visit: /cgi-bin/koha/erm/eholdings/local/packages 7) Create a new package, add a name and hit 'Submit' 8) Go to titles, visit: /cgi-bin/koha/erm/eholdings/local/titles 9) Click "import from list" 10) Pick the package created in 7) 11) On the row of the list created in 2), click "Import" 12) Go back to the list, visit: /cgi-bin/koha/virtualshelves/shelves.pl?op=view&shelfnumber=1 13) Notice all the biblios have been stripped of their MARC data, and only title remains. Setting this as 'major' for now as I don't think this is intended or desired behavour. -- You are receiving this mail because: You are watching all bug changes.

1 32