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

[Bug 25415] New: Suggestion for a good POD format
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25415 Bug ID: 25415 Summary: Suggestion for a good POD format Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: In Discussion Severity: enhancement Priority: P5 - low Component: Developer documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Search in the state of the art for what's best to use for POD (parameter, return values, etc.) Look at other Perl projects: Mojolicious, DBIx::Class, etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 25414] New: head2 POD inconsistent in Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25414 Bug ID: 25414 Summary: head2 POD inconsistent in Koha namespace Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Developer documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org There are: =head2 Class Methods =head2 Internal Methods TODO: * Remove unnecessary uppercase on "Methods" * Class methods is not correct in most of the case, a class method is a method that must be called on the class, not an instance. We should rename it "Instance methods" * Reposition the =head2 correctly (sometimes internal methods are in "Class methods" and vice versa) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 25413] New: Add missing POD to Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25413 Bug ID: 25413 Summary: Add missing POD to Koha namespace Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Developer documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Several modules and/or methods have none or incomplete POD. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 15253] Add Koha::Logger based logging for SIP2
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15253 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_20_05_candidate -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24299] New: Record if a transfer was triggered by 'rotating collections'
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24299 Bug ID: 24299 Summary: Record if a transfer was triggered by 'rotating collections' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Use the new 'trigger' field in branchtransfers to record if a transfer was added by the 'rotating collection' tool. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 10517] koha-restore fails to create mysqluser@mysql_hostname so zebra update fails
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #25 from Rudolf Byker <rudolfbyker(a)gmail.com> --- OK, if you really need to support older versions, let's do it cleanly. Here is a way to check if the user exists: EXISTS=$(mysql -uroot -p -s -e "select count(*) from mysql.user where user = 'asdf'" | tail -n 1) if [[ $EXISTS -gt 0 ]] then echo "Now delete the user." fi -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10517] koha-restore fails to create mysqluser@mysql_hostname so zebra update fails
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #24 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Rudolf Byker from comment #22) > (In reply to David Cook from comment #20) > > (In reply to Martin Renvoize from comment #16) > > > > > > I am, however, pretty keen to take such an approach and drop 5.5 support > > > with this release and so this patch is 'on hold' for now. > > > > For what it's worth, I think koha-remove uses "DROP USER IF EXISTS", so we > > already have mixed support for 5.5. > > > > I ended up removing "IF EXISTS" and updating koha-remove to use --force so > > that it could survive fatal errors. > > Are you talking about the `--force` option on the MySQL command line > utility? That smells like technical debt. Using it is the same or worse as > using `|| true`, since you will hide lots of potential errors. We only need > to handle one very specific error (which is not even an error, if you > consider Idempotency to be a good programming pattern for such scripts – > which it is). Using a catch-all to hide all errors is almost always a Bad > Idea (TM). Yes, the --force option for the MySQL cli utility. I am only suggesting it as a temporary measure. Versions of Debian we support are using MySQL server 5.5, but some Koha Debian utilities (the ones that are aiming at being idempotent) fail on those Debian versions. Either we remove the idempotency targeting newer versions of MySQL server, or we do a measure like --force (which will still warn so it doesn't hide the errors it just doesn't die on them). We really need to do one or the other. Or drop support for older versions of Debian I suppose. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15148] Serials: Test prediction pattern starts at First issue date, not Subscription start date
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15148 Myka Kennedy Stephens <mkstephens(a)lancasterseminary.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Failed QA --- Comment #12 from Myka Kennedy Stephens <mkstephens(a)lancasterseminary.edu> --- I like Nick's solution. Give the user a choice (radio button) to generate issues based on date of first issue or subscription date. Scenario: A library acquires a run of a serial that started in 2000. The back issues are already bound together and ready to be added as items. The library also starts a subscription to continue receiving new items beginning on January 1, 2020. The library wants to preserve the information that the first issue was published on January 1, 2000 but the predicted issues only need to be generated from January 1, 2020 and on. In this scenario, it makes more sense to base a prediction on the subscription start instead of the date of first issue. Our library workflow would use acquisitions or simply add the back issues as items to the biblio instead of receiving them through the serials module -- especially if they were already bound together as volumes. (I'm also going to change the status to 'failed QA' since I incorrectly used 'patch doesn't apply' when I tested this back in October.) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24432] New: Request an endpoint with a date column in order by throws bad parameter exception
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24432 Bug ID: 24432 Summary: Request an endpoint with a date column in order by throws bad parameter exception Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: agustinmoyano(a)theke.io CC: tomascohen(a)gmail.com Depends on: 23893 Blocks: 20936 When you request an endpoint in the API with a date as orderby, it throws Koha::Exceptions::BadParameter. Koha::REST::Plugin::Query in _build_order_atom, in order to get the model parameter for the order by, it requests {instance of Koha::Objects}->attributes_from_api({ <api parameter name> => 1 }); to get that hash translated, and use the resulting key as the model column to do the order by. This works ok for all datatypes except date types, because it's trying to transate the value of "1" as a date, throwig the mentioned exception. In my opinion, _build_order_atom should not use attributes_from_api, but should use the mapping in Koha::Object to get the column name. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20936 [Bug 20936] Holds History for patrons in OPAC https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23893 [Bug 23893] Add ->new_from_api and ->set_from_api methods to Koha::Object -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 25044] New: No need to define koha_object[s]_çlass for standard object class names
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25044 Bug ID: 25044 Summary: No need to define koha_object[s]_çlass for standard object class names 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(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 24356 In Koha::Object[s]->prefetch_whitelist, there is a call to the koha_object[s]_class DBIC resultset class. We should not, otherwise those 2 methods will have to be defined all the time, even when we can guess it easily. Koha::Item <> Schema::Result::Item => standard Koha::Acquisition::Order <> Schema::Result::Aqorder => non-standard sub _get_object_class { my ( $type ) = @_; return unless $type; if( $type->can('koha_object_class') ) { return $type->koha_object_class; } $type =~ s|Schema::Result::||; return ${type}; } Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24356 [Bug 24356] objects.search prefetch -- You are receiving this mail because: You are watching all bug changes.

1 28