July 2023 - Koha-bugs - lists.koha-community.org

[Bug 34106] New: Patron search in member-search-box.inc always defaults to 'Starts with' search
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '24

20 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34106 Bug ID: 34106 Summary: Patron search in member-search-box.inc always defaults to 'Starts with' search Change 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: lucas(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. In the main search header switch to 'Search patrons'. Bring up the dropdown and look at 'Search type:'. 2. It defaults to 'Starts with'. 3. Go to '/cgi-bin/koha/members/members-home.pl' and look at the 'Search type:' on the left side. 4. It defaults to 'Contains' 5. Do a patron search from both these places, setting the 'Search type' to contains. 6. The search bar in the header always resets to 'Starts with' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 25228] New: Patron messaging preferences clearing if duplicate warning
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '24

20 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25228 Bug ID: 25228 Summary: Patron messaging preferences clearing if duplicate warning Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Patrons Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 18595 Same as bug 5161 for messaging preferences. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18595 [Bug 18595] Move C4::Members::Messaging to Koha namespace -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 33898] New: background_jobs_worker.pl may leave defunct children processes for extended periods of time
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33898 Bug ID: 33898 Summary: background_jobs_worker.pl may leave defunct children processes for extended periods of time Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor 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 appears that the background jobs worker can leave defunct processes for periods of time. Though it is mostly harmless, it would be nice if that did not happen. Children are reaped automatically when start or wait_all_children are called. We only call start when a new job is found, and wait_all_children after exiting our while loop. The solution is to simply call reap_all_children after we sleep. This is a non-blocking call that will clean up those defunct processes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43

[Bug 32029] New: Automatic item modifications by age missing biblio table
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32029 Bug ID: 32029 Summary: Automatic item modifications by age missing biblio table 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In automatic item modifications by age missing, conditions can be on columns of tables items or biblioitems. Table biblio is missing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 31427] New: Automatic renewal too_many error is confusing in notices
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31427 Bug ID: 31427 Summary: Automatic renewal too_many error is confusing in notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I am not sure if this error, too_many, should be removed or just handled differently. It is confusing for patrons, here is why: Day 1, a patron gets an email telling them an item has been successfully renewed. It is auto renewal 5/5, the item will no longer renew. Day 2: The next a patron receives a new auto renewal message telling them the same item, from yesterday, cannot be renewed. Patrons are confused. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 69

[Bug 29570] New: unable to sort pending_orders table on parcel.pl by summary column
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29570 Bug ID: 29570 Summary: unable to sort pending_orders table on parcel.pl by summary column Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Have a pending order and go to: /cgi-bin/koha/acqui/parcel.pl?invoiceid=X Most of the columns you are able to sort but they summary column you cannot, it has the 'sorting_disabled' class. Librarians with large orders need to be able to sort by Summary. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 29033] New: Add C4::Context->multivalue_preference
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29033 Bug ID: 29033 Summary: Add C4::Context->multivalue_preference 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I've seen many places in which a syspref is read, and then split used to convert the contents into a list. It seems it would be simple to add a method to do that. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 23540] New: Gender 'N' is not translatable
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23540 Bug ID: 23540 Summary: Gender 'N' is not translatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Patrons of type 'I' (institution) automatically get their sex/gender set to 'N' (which is short for "None"), but the 'N' is not translatable and actually shows up in the patron details page. Relevant code in memberentrygen.tt: [% IF ( I ) %]<input type="hidden" name="sex" value="N" />[% END %] The template code for showing the gender text should be unified into single included file, instead of spread over multiple places like: koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt: [% IF ( patron.sex == 'F' ) %]Female[% ELSIF ( patron.sex == 'M' ) %]Male[% ELSE %][% patron.sex | html %][% END %] koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember-brief.tt: [% IF ( patron.sex ) %]<li><span class="label">Gender:</span>[% IF ( patron.sex == 'F' ) %]Female[% ELSIF ( patron.sex == 'M' ) %]Male[% ELSE %][% patron.sex | html %][% END %]</li>[% END %] -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 21314] New: Koha enforces 3 character password length even if RequireStrongPassword is disabled
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21314 Bug ID: 21314 Summary: Koha enforces 3 character password length even if RequireStrongPassword is disabled Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 18298 added the option to enforce password complexity *if* the new system preference RequireStrongPassword is enabled. However, it appears that the code defining the minimum number of characters was not put under control of this preference and thus Koha enforces a minimum password length of 3 even if RequireStrongPassword is disabled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 33262] New: When an ordered record is deleted, we lose all information on what was ordered
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33262 Bug ID: 33262 Summary: When an ordered record is deleted, we lose all information on what was ordered Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, michaela.sieber(a)kit.edu Blocks: 10758 I am moving this out from bug 10758 that was filed for the display issue. But that is actually only the symptom, while we are actually facing a data loss issue. Libraries need to be able to account for the money they spent even after the items and records have been removed from their collection. At the moment we lose the connection between order and bibliographic record when the record is deleted: -- -- Table structure for table `aqorders` -- DROP TABLE IF EXISTS `aqorders`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `aqorders` ( `ordernumber` int(11) NOT NULL AUTO_INCREMENT COMMENT 'primary key and unique identifier assigned by Koha to each line', `biblionumber` int(11) DEFAULT NULL COMMENT 'links the order to the biblio being ordered (biblio.biblionumber)', [...] CONSTRAINT `aqorders_ibfk_2` FOREIGN KEY (`biblionumber`) REFERENCES `biblio` (`biblionumber`) ON DELETE SET NULL ON UPDATE CASCADE, We do have the information about the deleted record and the items, but we need to preserve the link between order and deleted record in some way. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10758 [Bug 10758] Show bibliographic information of deleted records in acquisitions -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 47