March 2021 - Koha-bugs - lists.koha-community.org

[Bug 16865] New: marking branchcode unwanted breaks self registration
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '23

10 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16865 Bug ID: 16865 Summary: marking branchcode unwanted breaks self registration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you add branchcode to PatronSelfRegistrationBorrowerUnwantedField then self registration fails silently. The library and the user have no idea what happened. We should have an error and/or not let branchcode be added to that preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 17364] New: branchcode should not be allowed in BorrowerUnwantedField , PatronSelfRegistrationBorrowerUnwantedField
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '23

10 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17364 Bug ID: 17364 Summary: branchcode should not be allowed in BorrowerUnwantedField, PatronSelfRegistrationBorrowerUnwantedField 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: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If branchcode is among the fields in BorrowerUnwantedField, saving the borrower record in members/memberentry.pl will generate an Internal Server Error because there is a foreign key constraint on borrowers.branchcode. To replicate the issue: 1/ Set the syspref BorrowerUnwantedField so that it contains branchcode 2/ Create a patron on members/memberentry.pl 3/ Save the patron, you will get "Internal Server Error". It follows that PatronSelfRegistrationBorrowerUnwantedField should not contain branchcode either -- it's necessary to create a record in the borrowers table, so we shouldn't be able to exclude it. Details for those who like that sort of thing: If you're watching the plack error logs,you'll see something like this: DBD::mysql::st execute failed: Cannot add or update a child row: a foreign key constraint fails (`koha_salinas`.`borrowers`, CONSTRAINT `borrowers_ibfk_2` FOREIGN KEY (`branchcode`) REFERENCES `branches` (`branchcode`)) [for Statement "INSERT INTO `borrowers` ( `address`, `address2`, `borrowernotes`, `cardnumber`, `categorycode`, `city`, `contactnote`, `country`, `dateenrolled`, `dateexpiry`, `dateofbirth`, `debarred`, `email`, `emailpro`, `fax`, `firstname`, `initials`, `mobile`, `opacnote`, `othernames`, `password`, `phone`, `phonepro`, `privacy`, `sex`, `sort1`, `sort2`, `state`, `surname`, `title`, `userid`, `zipcode`) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )" with ParamValues: 0="1234 MAIN ST", 1="", 2="", 3="TESTYTESTERSON", 4="STAFF", 5="Bradley, CA", 6="", 7="", 8='2016-09-27', 9='2024-12-27', 10=undef, 11=undef, 12="", 13="", 14="", 15="TESTY", 16="", 17="", 18="", 19="", 20='!', 21="555 555 1212", 22="", 23=1, 24="", 25="C", 26="", 27="", 28="TESTERSON", 29="", 30='testy.testerson', 31="93426"] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1832. DBIx::Class::Storage::DBI::_dbh_execute(): Cannot add or update a child row: a foreign key constraint fails (`koha_salinas`.`borrowers`, CONSTRAINT `borrowers_ibfk_2` FOREIGN KEY (`branchcode`) REFERENCES `branches` (`branchcode`)) at /usr/share/koha/lib/C4/Members.pm line 769 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 22592] New: Elasticsearch - Support for index scan
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '23

10 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22592 Bug ID: 22592 Summary: Elasticsearch - Support for index scan Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: ere.maijala(a)helsinki.fi Target Milestone: --- We can emulate index scan at least to some extent by using faceting with an include filter. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 51

[Bug 17842] New: Broken diacritics on records exported as MARC from cart on reimport
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17842 Bug ID: 17842 Summary: Broken diacritics on records exported as MARC from cart on reimport Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I have experienced this problem for a while now in different versions, but I am not quite sure what's going wrong: - Add a records with diacritics, such as German umlauts äüö to your cart - Download the record from the cart in MARC - Import the record into Koha using the staged MARC import - Verify that the MARC preview doesn't work in the staged MARC import table - Verify that the umlauts didn't import correctly When using the 'import record' feature in Rancor, the diacritics also appear broken, fields containing diacritics get cut off and other oddities happen. -- You are receiving this mail because: You are watching all bug changes.

1 63

[Bug 26635] New: Expand authorised values in REST API call
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26635 Bug ID: 26635 Summary: Expand authorised values in REST API call Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: agustinmoyano(a)theke.io Reporter: agustinmoyano(a)theke.io We need a way to embed expanded authorised values in a REST API call. It's specially needed when you have to show authorised values descriptions in tables that are fetched through api. The proposed solution adds to object's api definition (even embedded content) the following key: _authorised_values For each column that contains an authorised value, it will be reflected inside this property, with the authorised value expanded. So for example if we embed the authorised values of an item, the result from the API call could look like this: GET /api/v1/items/1 { "_authorised_values": { "location": { "authorised_value": "GEN", "category": "LOC", "id": 27, "imageurl": null, "lib": "General Stacks", "lib_opac": null } }, "acquisition_date": "2014-05-07", "acquisition_source": null, "biblio_id": 1, "item_id": 1, ... "location": "GEN", ... "uri": null, "withdrawn": 0, "withdrawn_date": null } -- You are receiving this mail because: You are watching all bug changes.

1 155

[Bug 24284] New: Canelling of holds and order should allow for different translation then cancel as options in dialogs
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24284 Bug ID: 24284 Summary: Canelling of holds and order should allow for different translation then cancel as options in dialogs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr At least in German the verb used for cancelling orders/holds is different than the verb used for cancelling a process/cancelling a dialog. It would be nice if Koha allowed for different translations in this case. Maybe the new I18N features could be helpful here? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 27875] New: CollapseFieldsPatronAddForm reveals guarantor_template
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27875 Bug ID: 27875 Summary: CollapseFieldsPatronAddForm reveals guarantor_template 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you use CollapseFieldsPatronAddForm to hide the guarantor section of the member entry form, toggling that section reveals the guarantor_template. I have yet to find a way to work around this problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 26977] New: Update Koha Documentation to use absolute paths instead of relative ones
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26977 Bug ID: 26977 Summary: Update Koha Documentation to use absolute paths instead of relative ones Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: rex(a)nicic.gov QA Contact: testopia(a)bugs.koha-community.org Hi, I'm new to Koha, the previous Koha expert left their position a number of years ago and we left our version running along until the server crashed during an OS update. After that, I had to build a new server from scratch, install and upgrade Koha and get it working. I would like to ask that the Koha documentation be updated to make it easier for new people to learn Koha. Request: Please provide at least one absolute path location (rather than relative paths) when referring to file locations in a section. One example is the Cron jobs and Daemons page. I guess under the Cron Jobs subheading, I'm supposed to infer where files are located in the OS based on my flavor, but for someone new like me who is now responsible for becoming the expert on Koha, it would really ease my learning curve to have an absolute path offered at least once on the page. The relative paths on the page give me no indication of absolute location and even the Cron jobs description is making a huge assumption as to the user having knowledge that the writer of the documentation does. The text suggests that the files are in misc/ or bin/ but doesn't state that those are to be found in /usr/share/koha/, which would really help. Alternatively, a find command suggestion could be offered under the "Cron jobs" subheading for the user to locate the files. Since Koha files can be found in so many places, a new person like me doesn't know where to look and at least one absolute path to help someone get started and have a little confidence that they're finding the right file would be really nice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 27297] New: When itemtype is marked as required in OpacSuggestion MandatoryFields the field is not required
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27297 Bug ID: 27297 Summary: When itemtype is marked as required in OpacSuggestion MandatoryFields the field is not required Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Two issues: 1 - We only add the required class, we don't make the input required 2 - We don't add a 'blank' option, so the field is preselected -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 27957] New: Attributes removed in LDAP
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27957 Bug ID: 27957 Summary: Attributes removed in LDAP Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Working on bug 27857 (actually, on the follow-up bug 27956), I found that the Koha::Patron->extended_attributes setter is used to write the new attributes. This happens inside a Koha::Patron::Attribute::Types loop which is used to determine 'valid' attributes (good). The problem is 'extended_attributes' actually calls: $self->extended_attributes->filter_by_branch_limitations->delete; which deletes the existing attribute. So calling it for setting a single attribute makes it... delete all the attributes each time! There's also some funky logic in checkpw_ldap. The $patron object seems to be retrieved in several places and even inside a loop. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12