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

[Bug 16157] New: C4::Koha::GetAuthorisedValues should not handle the selected option
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '25

22 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16157 Bug ID: 16157 Summary: C4::Koha::GetAuthorisedValues should not handle the selected option Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org >From C4::Koha::GetAuthorisedValues # TODO: the "selected" feature should be replaced by a utility function # somewhere else, it doesn't belong in here. For starters it makes # caching much more complicated. Or just let the UI logic handle it, it's # what it's for. -- You are receiving this mail because: You are watching all bug changes.

1 12

[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 16275] New: Prevent patron creation if the email already filled in borrowers.email
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16275 Bug ID: 16275 Summary: Prevent patron creation if the email already filled in borrowers.email Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nicolas.legrand(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some of our patrons are not sure they succeed their self registration and self register multiple times. We would like to prevent this by blocking the selfregistration if the field borrowers.email is already filled by the same email address. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 16105] New: Cache::Memory is loaded even if memcache is used
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '25

18 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16105 Bug ID: 16105 Summary: Cache::Memory is loaded even if memcache is used Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 11998, 16104 Cache::Memory is loaded and Koha::Cache::_initialize_memory is called even if a memcached cache has been correctly initialize, it does not make sense. It should only be initialize if needed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11998 [Bug 11998] Syspref caching issues https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16104 [Bug 16104] Warnings "used only once: possible typo" should be removed -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 16104] New: Warnings "used only once: possible typo" should be removed
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '25

18 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16104 Bug ID: 16104 Summary: Warnings "used only once: possible typo" should be removed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Since bug 11998, the following warnings are raised: Name "Tie::Hash::FIELDS" used only once: possible typo at /usr/share/perl/5.22/fields.pm line 135. Name "Cache::RemovalStrategy::LRU::FIELDS" used only once: possible typo at /usr/share/perl/5.22/fields.pm line 135. Name "Cache::RemovalStrategy::FIELDS" used only once: possible typo at /usr/share/perl/5.22/fields.pm line 135. It comes from the Koha::Cache 103 if ( can_load( modules => { 'Cache::Memory' => undef } ) ) { -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 16196] New: Acquisitions Module Not Showing Subtotals
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16196 Bug ID: 16196 Summary: Acquisitions Module Not Showing Subtotals Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: amy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Partner reports that when receiving books in the Acquisitions module, subtotals are not identifying which fund they are for. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 15855] New: Disabling multiple submission on search form
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '25

16 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15855 Bug ID: 15855 Summary: Disabling multiple submission on search form Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: arthur.suzuki(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org Created attachment 48203 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48203&action=ed… Extract from koha-opac-access_log Some impatient users tends to click several times on the “Go” button of the search form on OPAC. Probably in a desperate hope that this will speed up the whole process. However the result is quite opposite, as Zebra is then queried multiple times which increases the server cpu load, until it reach 100% and cause Denial of Service (boooh…) We had the idea of disabling the “searchsubmit” button upon first click. This is done by adding onclick=”this.disabled=true;this.form.submit();return true;” after “id=searchsubmit” in masthead.inc. It is also possible to solve this issue by adding the following section to opacuser.js: $(document).ready(function() { $('#searchform').submit(function() { $('#searchsubmit').prop('disabled',true).text('searching...'); }); }); Thanks to Frederic Demians and Olivier Crouzet for their help. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 15725] New: Merge permission
by bugzilla-daemon＠bugs.koha-community.org 25 Dec '24

25 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15725 Bug ID: 15725 Summary: Merge permission Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice if Koha had a permission to limit access to the merge records option (Merge selected button) on the addbooks.pl search results page and the virtualshelves/shelves.pl page (lists). This is especially important in a consortial catalog environment where many people have cataloging permissions, but most probably shouldn't have the ability to merge records. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 16264] New: Confirm message on deleting an authority framework subfield
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16264 Bug ID: 16264 Summary: Confirm message on deleting an authority framework subfield Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org Just using this as an example because it appears in many places on the intranet Is there a reason that we navigate to a new page to confirm or cancel a delete rather than just using a Javascript confirm message? A JS message would use much less code. I realise that in the past we had a rule that everything had to work without JS enabled but a lot of stuff on the intranet wouldn't work at all without JS so I'm not sure how much that applies anymore. Anyway, just wondering if these extra pages for confirm or cancelling a delete are still necessary or if we can do this via JS now :) -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 15728] New: Hide component parts from search result
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '24

19 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15728 Bug ID: 15728 Summary: Hide component parts from search result Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org Add an option to hide component parts from search results. When searching for a song, we may want to see album results only (albums where the song appears). This option would help the process of seeing if a song is on an album that is available. -- You are receiving this mail because: You are watching all bug changes.

1 10