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

[Bug 20178] New: Fix output_pref with dateformat=iso
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '24

26 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20178 Bug ID: 20178 Summary: Fix output_pref with dateformat=iso Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: julian.maurice(a)biblibre.com Blocks: 17258 This bug is a continuation of bug 20144 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17258 [Bug 17258] [OMNIBUS] MySQL 5.7 -- You are receiving this mail because: You are watching all bug changes.

1 24

[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 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 23012] New: Possibility to mark processing fee by default refund when item is found
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '24

18 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 21159] New: Blank item shelving location (952$c) on issue and return based on syspref values
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '24

17 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 18207] New: smart-rules.pl should validate that all branches / patron categories / item types are covered by circ rules.
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '24

12 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18207 Bug ID: 18207 Summary: smart-rules.pl should validate that all branches / patron categories / item types are covered by circ rules. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com At present, It's possible to have combinations of branch / category / item type that are not covered by circulation rules. This may cause issues with circulation, holds and fines; we should require that all are covered. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 18054] New: Refreshing the screen for a confirmed checkout can cause odd results ( item checked out and waiting on hold)
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '24

11 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18054 Bug ID: 18054 Summary: Refreshing the screen for a confirmed checkout can cause odd results (item checked out and waiting on hold) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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 To recreate: 1 - Place a hold and confirm it to mark waiting 2 - Checkout that item to another patron and override the hold 3 - Leave that window open 4 - In a new tab checkin the item and confirm the hold as waiting 5 - Refresh the tab from #3 - the item checksout but waiting hold does not revert -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 16440] New: Update report parameters
by bugzilla-daemon＠bugs.koha-community.org 10 Jan '24

10 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16440 Bug ID: 16440 Summary: Update report parameters Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 51217 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51217&action=ed… Placement of report parameters on report results. Let's say you have a report that asks you for parameters. You run the report, get the results, and then you want to run the report again with different parameters. Or maybe you made a mistake and need to change it. Yes, you could back up and change things and run it again. But what if the parameters were showing over on the left of the report under the "Useful resources" section? You could see what you set, and change whatever you needed and then click update. Perhaps the row setting and update button could also be on the left of the report. Just a thought. I was able to change a parameter up in the URL, and hit update, and it worked. It was nice because I set the report to show more than 20 records, and I didn't have to repeat that step after updating. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 24383] New: koha-create doesn't restart / empty memcached causing installer fail
by bugzilla-daemon＠bugs.koha-community.org 10 Jan '24

10 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24383 Bug ID: 24383 Summary: koha-create doesn't restart / empty memcached causing installer fail Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org If in /etc/koha/koha-sites.conf I have defined USE_MEMCACHED="yes" and then I run "koha-create --create-db kvkoha" and after that "koha-remove kvkoha" and then again "koha-create --create-db kvkoha" then when I try to access the web installer page I get the following error: > DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: Access denied for user 'koha_kvkoha'@'localhost' (using password: YES) at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1520. at /usr/share/koha/lib/Koha/Database.pm line 107 This seems to happen because the memcached instance still holds the database credentials from the first time koha-create was run. The solution is to clear the memcached cache: > $ systemctl restart memcached After this the web installer loads correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 23660] New: Add system preference to remove message body from sent notices after notice status switches to sent.
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '24

08 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23660 Bug ID: 23660 Summary: Add system preference to remove message body from sent notices after notice status switches to sent. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: brendon.ford(a)manhattan.edu QA Contact: testopia(a)bugs.koha-community.org Currently the "Sent notices" list on a borrower's record retains the body of all sent notices. It may be useful for patron privacy to have the option to have message body removed after the notice has been sent. Ideally this would be done immediately after the notice has been processed, but having this scheduled could also be an option. Currently we can have the ability to remove the entire notice, but we would like to keep a record that a notice was sent and just remove what was in the notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5