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

[Bug 23514] New: Call numbers are not splitted in Label Creator with layout types other than Biblio
by bugzilla-daemon＠bugs.koha-community.org 12 May '20

12 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23514 Bug ID: 23514 Summary: Call numbers are not splitted in Label Creator with layout types other than Biblio Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org In Label Creator, - when one chooses any "Layout type" OTHER THAN Biblio - AND "Split call numbers" IS checked the splitting does not work at all, regardless of the classification standard used. Indeed in Label.pm, the splitting functions are applied only when printing_type=BIB I think this is a residue from the past and should be removed (or altered to exclude printing_type=BAR) -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 22937] New: Searching by library groups uses group Title rather than Description
by bugzilla-daemon＠bugs.koha-community.org 12 May '20

12 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22937 Bug ID: 22937 Summary: Searching by library groups uses group Title rather than Description Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When using library search groups, the title of the group shows up in advanced search rather than the description. The description doesn't seem to be present anywhere except when calling <<X|GROUPS>> in a report. This seems confusing as most places the description label is what will show in pulldowns (both in Auth. values and itypes parameter setup.) Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 24769] New: DataTable error on patron hold page when hold placed using ILS-DI
by bugzilla-daemon＠bugs.koha-community.org 12 May '20

12 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24769 Bug ID: 24769 Summary: DataTable error on patron hold page when hold placed using ILS-DI Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 99820 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=99820&action=ed… Screenshots - DataTable error on patron hold page when hold placed using ILS-DI After placing a hold for a patron using ILS-DI an error occurs on the staff interface. After the hold is placed used ILS-DI, when clicking on the holds tab on a patron's details page: - an error message pops up; and - it no longer lists any holds. To replicate: 1) Place a hold for a patron. 2) Check the patron's details page and holds tab, the hold is listed. 3) Enable the ILS-DI system preference. 4) Use ILS-DI to place a hold for a patron, for example: http://127.0.0.1:8080/cgi-bin/koha/ilsdi.pl?service=HoldTitle&patron_id=19&…'27.0.0.1' (where: 19 = a patron id and bib_id = 12 a bibliographical record) 5) On the staff client go to Patrons > [Patron hold placed for] > Details > Holds tab. 6) An error is displayed in a pop-up window: DataTables warning: table id=holds-table - Ajax error. For more information about this error, please see http://datatables.net/tn/7 7) After clicking on OK for the error message, the holds tab no longer lists any holds - even though 2 should be listed. This occurs on master, but doesn't occur on 19.11.x It was discovered when testing bug 17229. See the attached screenshots. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 23601] New: Middle clicking a title from search results creates two tabs or a new tab and a new window in Firefox
by bugzilla-daemon＠bugs.koha-community.org 12 May '20

12 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23601 Bug ID: 23601 Summary: Middle clicking a title from search results creates two tabs or a new tab and a new window in Firefox Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When middle-clicking or ctrl-clicking a title in the results screen of the staff client, Firefox opens two new tabs. To reproduce: 1. Use a relatively recent version of Firefox (I've tested this on 68esr and 69) 2. Search for an item in the staff interface 3. From the results screen, middle click or control click a title. 4. Depending on your Firefox settings, Firefox will open an new window and a new tab or two new tabs. The popup blocker may also block the opening of these tabs. This appears to be related to the preventdefault() being used here, which Firefox handles differently than other browsers. There's the broader discussion of whether there's any need to use preventdefault() here at all. From the comments in the jquery it appears that someone thought it wasn't a good idea. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 17938] New: XSLT: if 583 is repeated, the label will appear multiple times.
by bugzilla-daemon＠bugs.koha-community.org 12 May '20

12 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17938 Bug ID: 17938 Summary: XSLT: if 583 is repeated, the label will appear multiple times. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: karenliang.student(a)wegc.school.nz QA Contact: testopia(a)bugs.koha-community.org This will build on the patch bug 17823. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 24636] New: Acquisitions planning sections untranslatable
by bugzilla-daemon＠bugs.koha-community.org 12 May '20

12 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24636 Bug ID: 24636 Summary: Acquisitions planning sections untranslatable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr When you go in Adminitration > Budgets > (Budget) > Planning > Plan by ... (aqplan.pl), the terms for MONTHS, BRANCHES and ITEMTYPES are not translatable. To reproduce: 1. Install another language if you don't already have one 2. Go to Administration > Budgets 3. Click on a budget (or create one if you don't already have one) 4. Click on Planning and choose one of the options (for example Plan by months) 5. Notice at the top it says 'Planning for <budget name> by MONTHS' 6. Switch languages 7. Notice 'MONTHS' is still in English I looked in my fr-CA-staff-prog.po file and 'MONTHS' is not in there (even after an update). I know it's been like this for several versions, but I can't find a bug report for this. Sorry if it is a duplicate. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 18308] New: Default value of minPasswordLength should be increased
by bugzilla-daemon＠bugs.koha-community.org 12 May '20

12 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18308 Bug ID: 18308 Summary: Default value of minPasswordLength should be increased Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org It defaults to 3, should be at least 8 or 10. -- You are receiving this mail because: You are watching all bug changes.

1 146

[Bug 24763] New: Backdating check-ins creating fine issues that can't be resolved
by bugzilla-daemon＠bugs.koha-community.org 11 May '20

11 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24763 Bug ID: 24763 Summary: Backdating check-ins creating fine issues that can't be resolved Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org >From ByWater: When libraries accept payment on accruing fines and then backdate the checkin of the item, the final amount due can end up less than the amount paid. (There are other ways for this to happen, but backdated checkin is the most common.) It's not a fine that can be paid off (because it's negative), but it's not truly a credit either so it cannot be reconciled or voided. We would like to see this addressed so we can continue to backdate our overnight bookdrop items without these issues, and without having to constantly ask our support vendor to remove them for us. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 17527] New: 245 $h Medium - hidden settings in MARC framework don' t work correctly
by bugzilla-daemon＠bugs.koha-community.org 11 May '20

11 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17527 Bug ID: 17527 Summary: 245 $h Medium - hidden settings in MARC framework don't work correctly Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: eb(a)efdss.org QA Contact: testopia(a)bugs.koha-community.org 245 $h will not be hidden. Even when this subfield is set to "ignore", it still shows up in the staff interface and the OPAC. However, the 245$h does not appear in the MARC view. Just checked and setting other subfields in other fields to "ignore" seems to work as expected. I haven't tested them all, but it consistently doesn't work in 245 This applies to 3.22 and 16.05 (MARC 21) -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 23133] New: Rename reserves.item_level_hold for reserves.item_level
by bugzilla-daemon＠bugs.koha-community.org 11 May '20

11 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23133 Bug ID: 23133 Summary: Rename reserves.item_level_hold for reserves.item_level Change sponsored?: --- Product: Koha Version: master 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 Target Milestone: --- Opinionated report, but I think new column names should match our latest practices. i.e. don't make it read: if ( $hold->item_level_hold ) { ... but if ( $hold->item_level ) { ... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19