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

[Bug 25925] New: In the alert box for unfilled important field in cataloging, the cancel button is not translatable
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '21

05 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25925 Bug ID: 25925 Summary: In the alert box for unfilled important field in cataloging, the cancel button is not translatable 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 Created attachment 106522 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106522&action=e… Alert box in French (CA) where the Cancel button is not translated I noticed when you try to save a record where an important field is not filled, the Cancel (and probably the OK) button is not translatable. I tried to find the string in my staff-prog.po file and couldn't find it. To get the alert: 1- Modify a framework and mark one of the fields as important 2- Open a new record in cataloging and fill out the mandatory fields but not the important field 3- Try to save the record There is a "Cancel" string and a "Cancel " string in staff-prog.po, but they only apply on the following lines, which is not the important alert as far as I can tell. #: intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt:632 #: intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt:636 #: intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt:640 #: intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt:644 #: intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt:648 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 24557] New: Cancel Hold on check in
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '21

05 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24557 Bug ID: 24557 Summary: Cancel Hold on check in Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 It would be great if there were another option next to the Cancel hold button during check in like "Cancel and process next", which would be available if there were other holds on the item, or the item needed to transfer back home. If neither are the case, the button would not appear. Currently, we cancel holds by checking an item in, and using the Cancel hold button. Then, not know if there are any holds or if the item is being transferred, we have to check it in again to see. This second step could be automated with a new conditional button. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 23815] New: Cancel hold confirmation should display specific information
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '21

05 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23815 Bug ID: 23815 Summary: Cancel hold confirmation should display specific information Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Any cancellation or deletion confirmations should display the information that is being cancelled or deleted when confirmed. request.pl uses and alert type confirmation that does not display any specific information. With items so close to each other, it would be easy enough to click on the wrong X to cancel a hold and cancel the wrong hold. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 26532] New: Error when cancelling a hold from check-in page
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '21

05 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26532 Bug ID: 26532 Summary: Error when cancelling a hold from check-in page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com - Place a hold and note a valid barcode - Go to the checkin page - Return the item - choose 'cancel hold' Can't call method "biblio" on an undefined value at /home/vagrant/kohaclone/circ/returns.pl line 147 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 24500] New: Cancelling a hold at the same time produces internal server error
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '21

05 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24500 Bug ID: 24500 Summary: Cancelling a hold at the same time produces internal server error Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Need to have a page for holds (and probably other instances) where an object you are working with is no longer available. Maybe something like a "Whoops!" page (the item you are working with is no longer available), rather than having a default internal server error page. We should trap these kinds of issues better. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 27367] New: Housebound and CheckPrevCheckout
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '21

05 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27367 Bug ID: 27367 Summary: Housebound and CheckPrevCheckout Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently the system preference CheckPrevCheckout is an everyone or no one setting. It would be particularly helpful in Housebound module to have that system preference apply in only specific situations. For instance, only for a specific patron category, or only for patrons with a specified attribute. Without this, staff have to manually search a patron's circ history to see if an item has already been checked out to them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 27852] New: Link YES_NO authorized value category to 942$n in Default framework
by bugzilla-daemon＠bugs.koha-community.org 04 Aug '21

04 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27852 Bug ID: 27852 Summary: Link YES_NO authorized value category to 942$n in Default framework Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When OpacSuppression is set to Hide, a value of 1 in 942$n will hide the record from the OPAC, whereas a value of 0 or empty will show the record in the OPAC. I think it would be logical to link the authorized value category "YES_NO" to the 942$n field in the Default framework. I usually add the link manually for all new installations (and sometimes I forget), but I feel like it's a normal use. Maybe we could add it to master? And also add 0 as default value, just to make sure the Yes is not selected by default. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 25026] New: RaiseError must be set for the UI
by bugzilla-daemon＠bugs.koha-community.org 04 Aug '21

04 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25026 Bug ID: 25026 Summary: RaiseError must be set for the UI Change sponsored?: --- Product: Koha Version: unspecified 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 Depends on: 22001 This is a follow-up for bug 22001. The patch "Bug 22001: Set unsafe only if RaiseError is not set" proved that unsafe => 1 and RaiseError => 0 was wrong. We should move forward and turn RaiseError for the UI, and... see what's happening. The change goes to the right direction, but we need to know how big is the task to have a stable release with these parameters correctly set. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22001 [Bug 22001] RaiseError and PrintError flags must be set for tests -- You are receiving this mail because: You are watching all bug changes.

1 48

[Bug 27987] New: Canceling an order / deleting item will result in warning even though there was no problem
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '21

03 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27987 Bug ID: 27987 Summary: Canceling an order / deleting item will result in warning even though there was no problem Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is due to the return result from Koha::Item::safe_delete being different than what DelOrder expects. We should be checking for the correct return value in DelOrder. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 25321] New: Move translatable strings out of strings.inc into merge-record.js
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '21

03 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25321 Bug ID: 25321 Summary: Move translatable strings out of strings.inc into merge-record.js Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 21156 Strings which were put in strings.inc for translation purposes can now be wrapped in the new translation function and put in the various JavaScript files where they're used. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21156 [Bug 21156] Internationalization: plural forms, context, and more for JS files -- You are receiving this mail because: You are watching all bug changes.

1 22