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

[Bug 23433] New: Make consistent use of patron-title.inc in hold confirmation dialogs
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23433 Bug ID: 23433 Summary: Make consistent use of patron-title.inc in hold confirmation dialogs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 23399 We have inconsistent use of patron-title.inc in returns.tt. Sometimes it is used and sometimes it isn't. Where it was added it seems to have reversed the display of patron surname and first name: Previously last, first; now first last. All uses of patron-title.inc in this situation should be consistent. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23399 [Bug 23399] Reindent returns.tt -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 21674] New: Data integrity not enforced for library groups
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21674 Bug ID: 21674 Summary: Data integrity not enforced for library groups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 15707 You can create hierarchical groups of libraries you are not allowed to add several times the same library to a given group/subgroup. The libraries that are part of the group is not displayed on the interface, to prevent the user to select it. However this restriction is only done template-side, the controller and module does not handle it. To recreate the problem: - Go to Home › Administration › Library groups - Add a group - Add a library - reload the page several times => The same library appears several times in the group Note that we should also replace the "Add" and "Remove" links with buttons. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15707 [Bug 15707] Add ability to define hierarchical groups of libraries -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 17374] New: Make use of fields from syspref ' DefaultPatronSearchFields' in patron search fields dropdown
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17374 Bug ID: 17374 Summary: Make use of fields from syspref 'DefaultPatronSearchFields' in patron search fields dropdown Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 14874 introduced syspref 'DefaultPatronSearchFields' to define what fields should be used in default patron search. It would be nice see the fields in the search fields drop down as well. At the moment the are hard coded to: Surname,Email,Borrower number,Username,Phone number,Street Address,Date of birth,Sort field 1,Sort field 2 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 77

[Bug 21010] New: Add a script to search for data inconsistencies
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21010 Bug ID: 21010 Summary: Add a script to search for data inconsistencies Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org 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 17

[Bug 23084] New: Replace grep {^$var$} with grep {$var eq $_}
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23084 Bug ID: 23084 Summary: Replace grep {^$var$} with grep {$var eq $_} 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(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- See bug 23006 and bug 22941. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 17268] New: Advanced cataloging editor - rancor - macros are lost when browser storage cleared
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17268 Bug ID: 17268 Summary: Advanced cataloging editor - rancor - macros are lost when browser storage cleared Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In development macros were stored in the browser to allow different users to have their own. Unfortunately this means macros are lost when browser storage is cleared. Should have a more robust method for retaining these. -- You are receiving this mail because: You are watching all bug changes.

1 129

[Bug 23173] New: ILL should be able to search third party sources prior to request creation
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23173 Bug ID: 23173 Summary: ILL should be able to search third party sources prior to request creation 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: andrew.isherwood(a)ptfs-europe.com Target Milestone: --- Currently, there is no integrated way of knowing if an item being requested is already available. If a user creating a request wants to know if the item they are requesting is already available, it is necessary to search the, possibly, multiple sources the library has available (catalogue, discovery interface, open access provider etc.) first. The problem is further compounded if the institution has the unmediated ILL workflow enabled where a request can be placed with no oversight, even though the institution may already have access to it. I propose a mechanism by which, during request creation, one or more "sources" are searched with the provided metadata to try and determine if the item being requested is already available and, if so, links to that item are provided. This behaviour will be optional, via a syspref. "Sources" will be provided as Koha plugins and will provide the ability to accept metadata conforming to the established ILL schema, search the source with which they're concerned, and return results in a prescribed format. This will be performed via an API common to all "source" plugins. All plugins performing this task will be in a common plugin category and therefore enumerable. The workflow for two backends: Freeform: - User fills in Freeform form, clicks submit button - User is taken to an "Availability" page - ILL enumerates source plugins that can service this type of request (mostly determined by material type) and makes search requests to each using provided metadata - Displays results from each source, with links to matching items - User can then either choose a result and be taken to it, or choose none and continue with the request as normal BLDSS: - Identical to above except the user will choose a BLDSS result rather than filling in the Freeform form As part of this work, a source plugin, which will serve as a reference, will be provided. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 21443] New: Add ability to exclude holidays when calculating rentals fees by time period
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21443 Bug ID: 21443 Summary: Add ability to exclude holidays when calculating rentals fees by time period 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 It would be a nice addition if we could have the option to not count holidays when creating time period based rental fees. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49

[Bug 23185] New: Koha::Objects supports passing through 'update' which means we can side step 'set' + 'store'
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23185 Bug ID: 23185 Summary: Koha::Objects supports passing through 'update' which means we can side step 'set' + 'store' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P1 - high 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 CC: dcook(a)prosentient.com.au, jonathan.druart(a)bugs.koha-community.org, koha-bugs(a)lists.koha-community.org, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 21761 Target Milestone: --- +++ This bug was initially created as a clone of Bug #21761 +++ If we're adding triggers at the code level all over the place by overloading the store method we need to never ever let dbic handle it.. by allowing the 'update' method through we are exposing ourselves to places in the codebase skipping the store triggers. This would in effect bind us to the 'update_all' style of update call from dbic, which results in a loop over the affected rows so that in code triggers can be called per row rather than allowing any form of 'update all these rows to X' in one query. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21761 [Bug 21761] Koha::Object supports passing through 'update' which means we can side step 'set' + 'store' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. You are on the CC list for the bug.

1 70

[Bug 22774] New: Limit Purchase Suggestion in a specified Time period
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '20

14 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22774 Bug ID: 22774 Summary: Limit Purchase Suggestion in a specified Time period Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Many libraries would like the ability to limit purchase suggestions made by a patron to a certain number over a specified period. i.e. 3 suggestions every 30 days. The MaxOpenSuggestions works to limit 'open' suggestions, but does not take into account the total suggestions made by patrons. We need the ability to limit the number of suggestions a patron can make in a "rolling number of weeks" (over last X weeks). The variables for this would be the number of suggestions and the number of rolling weeks. Suggested system preference "MaxTotalSuggestions" with two variables. First is the number of total suggestions and the second is the number of days. e.g. MaxTotalSuggestion Allow 3 total suggestions over 30 days. (user configures the numbers to suit their policy) Result: Users are prevented from making any suggestions if the total suggestions (pending/checked/accepted/rejected) they've made over the last X days is equal to the max specified. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56