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

[Bug 17593] New: Extend circulation rules to include shelving location
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17593 Bug ID: 17593 Summary: Extend circulation rules to include shelving location 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: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We are in the process of moving over to Koha, and are still trying to manage all the details around this. Circulation rules are a big thing we have to tackle here. At the moment, we have multiple libraries, and within each library we have both open and closed stacks as well as multiple other segmentations, all specified as shelving locations (authorized value LOC). These locations are not always governed by the same set of rules, so it would be very helpful if the system could support LOC as a circulation rule condition alongside library, patron category and item type. >From doing a fairly brief look at the code, it seems GetIssuingRule and GetLoanLength in C4/Circulation.pm are the main points where the ruleset is retreived. There will of course be all the places calling these two functions, as well as database management parts to consider. If we were to develop some sort of extension to these rules, what would be an appropriate approach? It should certainly be an option to turn on to be used, but should we consider LOC as a starting point, or should LOC just be one many possible choices in the configuration? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 20813] New: Revamp user permissions system
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20813 Bug ID: 20813 Summary: Revamp user permissions system Change sponsored?: --- Product: Koha Version: master 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Koha's current user permissions system is a bit convoluted and limited due to it's legacy where the permissions system was a simple set of flags. A second layer of sub-permissions were later added complication and obfuscation to the system. We should revamp the permissions system to be a more modern system and open the path to having unlimited nesting of sub-permissions instead of shoe-horning sub-permissions into the limited system we have. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[Bug 19642] New: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19642 Bug ID: 19642 Summary: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 19225 proposes a warning for users that the config is wrong. I propose instead, we should just ignore that field if automembernum is enabled (since it autocalculates and becomes mandatory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 21266] New: Missing doc-head-close and cssinclude in sco-main.tt
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21266 Bug ID: 21266 Summary: Missing doc-head-close and cssinclude in sco-main.tt 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Custom stylesheet themes set in the OpacAdditionalStylesheet are not applied to the sco-main.tt page because this page is missing the following lines of code in the header: doc-head-close cssinclude -- You are receiving this mail because: You are watching all bug changes.

1 48

[Bug 21482] New: Create a "landing page" for ILL
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21482 Bug ID: 21482 Summary: Create a "landing page" for ILL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Currently, when you go to the ILL module, the first iew is of all ILL requests. This can be a lot of data, and take several seconds to load, and I doubt a lot of people will want the full list. So maybe we could have some sort of intermediate page with links to selections of request, based on their status, type etc. At it's simplest this could just be a page that displays the contents of a syspref, and that syspref could then be filled with HTML and links to filtered views of ILL requests. If the syspref is empty, the intermediate page could redirect to the full view, as it is today. A more advanced version would have a GUI to configure the links, order them, give them names etc. Thougts? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 20344] New: Transferring an item while on hold results in a transfer were the destination is the same as the source
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Bug ID: 20344 Summary: Transferring an item while on hold results in a transfer were the destination is the same as the source 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: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1. Check out an item 2. Place a hold on the specific item with a pickup at a different branch 3. Check in: Confirm hold and transfert 4. Check the branchtransfers table to ensure that the transfert is here SELECT * FROM branchtransfers order by datesent DESC LIMIT 10; 5. Home › Circulation › Transfers 6. Create a transfer identical as the existing one 7. You should see «Item is already at destination library.» 8. Check the branchtransfers table 1. First one should have been canceled «Canceled, new transfer from A to A created» 2. Another one should have been created from A to A 3. These 2 things are the issue. Because doing the same without a hold - doesn't create a new transfer - doesn't cancel the first one -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 17921] New: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17921 Bug ID: 17921 Summary: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Items that shouldn't be displayed in the OPAC are displayed in the shelf browser The links work as expected (redirect to opac-blocked or 404) but we should not display them in the first place -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 20472] New: Working title
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20472 Bug ID: 20472 Summary: Working title 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 91

[Bug 20570] New: Add script to complete scanned article requests
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20570 Bug ID: 20570 Summary: Add script to complete scanned article requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 18948] New: Elasticsearch - Reindexes should use aliases to avoid down time while reindexing
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18948 Bug ID: 18948 Summary: Elasticsearch - Reindexes should use aliases to avoid down time while reindexing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This patchset aims to add the ability to leverage the ES alias feature during a reindex - when doing a full reindex or a deletion the indexer will look for an existing index under the alias - if not found it will create a new one, if found it will index into a new index and point the alias there when done and then delete the old index. -- You are receiving this mail because: You are watching all bug changes.

1 26