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

[Bug 21903] New: koha-dump be able to include koha-upload
by bugzilla-daemon＠bugs.koha-community.org 24 Jan '24

24 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21903 Bug ID: 21903 Summary: koha-dump be able to include koha-upload 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: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz At this moments koha-dump include configuration files and mysql database, but it is not including a backup of /uploads, it should be great if we can add n option to also backup the uploaded files -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 27278] New: FindDuplicate uses 'exact' for searching and is too strict
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '24

23 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27278 Bug ID: 27278 Summary: FindDuplicate uses 'exact' for searching and is too strict Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using FindDuplicate to check for existing records the check for suggestions is too strict. Entering an author's name in direct order: John Jacob Jingleheiner-Schmidt Will not match Jingleheimer-Schmidt, John Jacob Entering partial title: The vixens Will not match: The vixens. A novel. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 23494] New: Tie Lists to CKO
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '24

23 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23494 Bug ID: 23494 Summary: Tie Lists to CKO Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: christofer.zorn(a)ajaxlibrary.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hello! We had migrated from a Bibliocommons system to Koha. In that previous system, our patrons had the ability to create a "for later" list that they could populate with books that they wished to read at a later time. When they did finally end up checking those items out, it was removed from their list. As a work around, I suggested that the patron put the item on a suspended hold and unsuspend it when they are ready for the book. However, having this functionality available through lists may be beneficial as well. Thanks Christofer -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29738] New: koha-run-backups can't use option --uploaded_files from koha-dump
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '24

23 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29738 Bug ID: 29738 Summary: koha-run-backups can't use option --uploaded_files from koha-dump 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: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 21903 Bug 21903 add tow options to koha-dump (--uploaded_files and --uploaded_temp_files) but these options can't be used from koha-run-backups. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21903 [Bug 21903] koha-dump be able to include koha-upload -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 26905] New: Purchase suggestion button hidden for users with suggestion permission but not acq permission
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '24

23 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26905 Bug ID: 26905 Summary: Purchase suggestion button hidden for users with suggestion permission but not acq permission Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: gormanp(a)parliament.uk QA Contact: testopia(a)bugs.koha-community.org We have library staff who may need to submit purchase suggestions to our acquisitions team, but do not need access to the rest of the acquisitions module. We do not have purchase suggestions turned on on the OPAC. We have permissions set so that they can manage purchase suggestions, but do not have any acquisitions module permissions set. Unless I'm mistaken, the only route to access the purchase suggestion form through the staff client is through the acquisitions module, but if these users have no acquisitions permissions, they do not have the acquisitions page link available on the Koha homepage. Can I propose that a link to the purchase suggestion form be added somewhere else on the staff client homepage, so that users with this particular set of permissions can access the form without needing to have additional acquisitions permissions? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 31132] New: Add button to clear the cataloguing authority plugin form
by bugzilla-daemon＠bugs.koha-community.org 22 Jan '24

22 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31132 Bug ID: 31132 Summary: Add button to clear the cataloguing authority plugin form 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: koha-training(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Add a button that will empty all of the search fields in the authority finder plugin when cataloguing biblios -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 23012] New: Possibility to mark processing fee by default refund when item is found
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '24

19 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23012 Bug ID: 23012 Summary: Possibility to mark processing fee by default refund when item is found 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: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- Hi, When you indicate a Processing fee and a replacement cost by default for a particular item type, these two fees are charge to users when an item is indicating as lost by the patron in koha. If you indicate that the item is now found, the replacement cost will be refund in the patron’s account if RefundLostOnReturnControl is activate. But, the processing fee is not refund in this situation. It would be nice to have the possibility to decide when the lost item is found that the processing fee by default will be refund ore not. It could be managed by a system preference or something like that. Test plan: -Activate WhenLostChargeReplacementFee -indicate a processing fee and a replacement cost by default for an item type. -check out an item with the same item type to a patron -Active RefundLostOnReturnControl -mark this item as lost by the patron in koha -see that the processing fee and the replacement cost are charge to the patron. -Mark the item as found by a check in -See that the replacement cost is refund and not the Processing fee. It could be a system preference in the same way that WhenLostChargeReplacementFee but for the processing fee. Regards, Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 67

[Bug 30934] New: Allow for this system preference NoRefundOnLostReturnedItemsAge to be library specific
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '24

18 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30934 Bug ID: 30934 Summary: Allow for this system preference NoRefundOnLostReturnedItemsAge to be library specific Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, each branch can identify what their refund rules are in the circulation and fine rule matrix in the 'Default lost item fee refund on return policy'. Recently the system preference, NoRefundonLostReturnedItemAge has been introduced however as a global option. It would be more beneficial to multibranch library systems to determine this specific system preference by branch and not a system rule. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21159] New: Blank item shelving location (952$c) on issue and return based on syspref values
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '24

18 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21159 Bug ID: 21159 Summary: Blank item shelving location (952$c) on issue and return based on syspref values 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Items shelving location (952$c) is blanked when the item is issued (if the new syspref BlankShelvingLocationOnIssue is enabled) and returned (if the new syspref BlankShelvingLocationOnReturn is enabled). i.e. This patch will blank shelving location on circulation actions, it will utilise two system preferences rather than one so it can work however people want it to. The sysprefs will both be off by default. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 153

[Bug 26071] New: Allow to configure fields not to be copied when using "Edit as new (duplicate)" in cataloging
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '24

15 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26071 Bug ID: 26071 Summary: Allow to configure fields not to be copied when using "Edit as new (duplicate)" in cataloging Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When duplicating a record for example for cataloging a newer edition an exact duplicate of the record is created. In some cases it would be nice if you could define fields that should be emptied out when duplicating, similar to what we can do when duplicating subscriptions (SubscriptionDuplicateDroppedInput). The use case here would be to drop 001 when copying, so no duplicate IDs are added to the catalog. The field is marked mandatory so then the cataloger will be reminded to fill it in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6