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

[Bug 28323] New: Invalid record in sample data leading to error when displaying
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28323 Bug ID: 28323 Summary: Invalid record in sample data leading to error when displaying 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: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org Strk̆v̜elser illustreret af Jean Anderson dansk udgave ved Lis Engel [overst̆telse ved Jesper Langer] staff://cgi-bin/koha/catalogue/detail.pl?biblionumber=369 opac://cgi-bin/koha/opac-detail.pl?biblionumber=369 ========= error ============ Invalid data, cannot decode metadata object (biblio_metadata.id=368, biblionumber=369, format=marcxml, schema=MARC21, decoding_error=':8: parser error : PCDATA invalid Char value 31 <controlfield tag="001">00aD000015937</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ============ Here is some analysis by Caroline ============ I can't find the exact problem with record 369, but it's definitely problematic, even MarcEdit won't open it I can view it with a command line tool that I have Problem record : https://snipboard.io/paTtIK.jpg the error messages seem to point to the control fields 001, 004 (which doesn't exist in MARC21 afaik), and 008 Compared with a healthy record : https://snipboard.io/XFZ5VN.jpg In fact, there are a couple more fields in the problem record that dont exist in MARC21 : 021 (should probably be 020), 245$d (should probably be 245$c?), 245$f should be dates The fact that indicators are all 00 is also wierd... anywho, I think there is probably a character at the beginning of the record that is messing up everything else tuxayo: does this look like a legitimate record to have in sample data? Because real world data can be weird ^^ tuxayo: Or is this worthless and should be removed from sample data? caroline: I think it should be removed.... I mean it's just sample data and this one is clearly a problem Unless it was there for a specific purpose like you suggested it causes problem when searching for danish documents too :/ Advanced search > Language Danish > Search > Error ====== issue with search of Danish records ======= - OPAC - advanced search - Language dropdown => Dansk - search - error Actually it's just that it redirects to the record page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 29104] New: Add new columns to table_borrowers column configuration
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '23

07 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29104 Bug ID: 29104 Summary: Add new columns to table_borrowers column configuration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliwho(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The present options under columns_settings.pl for the table_borrowers table are name, cardnumber, date_of_birth, category, library, address, & phone. It would be helpful to have the dateexpiry column available for display as well. Others may have prefer additional columns as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 28607] New: Error: Session timed out. Please log in again
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '23

06 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28607 Bug ID: 28607 Summary: Error: Session timed out. Please log in again Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: xuan(a)klc.edu.sg QA Contact: testopia(a)bugs.koha-community.org Created attachment 122228 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=122228&action=e… error prompt once user login, unable to click on buttons as it redirect us to this timeout error. please advise. http://23.239.31.27:8080/cgi-bin/koha/admin/authorised_values.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

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

06 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 06 Jul '23

06 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 29633] New: Unecessary GetMarcBiblio call in Koha::UI::Form::Builder::Item (?)
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29633 Bug ID: 29633 Summary: Unecessary GetMarcBiblio call in Koha::UI::Form::Builder::Item (?) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Andrew contacted me to raise a potential problem coming from bug 27526: commit 7a8357f7099d0863a322d1e91741b792b97fd6e1 Bug 27526: Adjust code to use Koha::Items -C4::Biblio::EmbedItemsInMarcBiblio({ - marc_record => $temp, - biblionumber => $biblionumber }); has been removed. I have tried to know where the items subfields could be used and found, in Koha/UI/Form/Builder/Item.pm: 1. only if itemcallnumber is used 164 my $temp2 = $marc_record->field($CNtag); 2. cataloguing plugins: 316 record => $marc_record, I have not found any cataloguing plugins using the MARC::Record (some are retrieving it when they have been passed in parameter, but that's another story). So maybe we could: * Remove marc_record from generate_subfield_form param list * Fetch it in the itemcallnumber block * Remove it from the cataloguing plugins -- You are receiving this mail because: You are watching all bug changes.

1 5

[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 29290] New: Add routes to fetch checkouts for a given biblio
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29290 Bug ID: 29290 Summary: Add routes to fetch checkouts for a given biblio Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com I propose we add GET /biblios/:biblio_id/checkouts it will have the same behavior as /checkouts, but filtering by the specified biblio. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30