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

[Bug 10532] koha-run-backups option --output doesn't work
by bugzilla-daemon＠bugs.koha-community.org 28 Nov '23

28 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10532 Thomas Klausner <domm(a)plix.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |domm(a)plix.at --- Comment #9 from Thomas Klausner <domm(a)plix.at> --- We also stumbled upon this problem recently. I think the best solution would be to pass --output from koha-run-backups on to koha-dump, plus some code to check if the dir exists. And IMO it would make more sense to write those scripts in Perl than in bash. It's much easier/shorter in Perl, and we can be confident that Perl is installed, because ... Koha.. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34807] New: Move EnableItemGroups in cataloging preferences
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '23

27 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34807 Bug ID: 34807 Summary: Move EnableItemGroups in cataloging preferences Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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: gmcharlt(a)gmail.com While doing bug 31832, I thought that while EnableItemGroupHolds is a circulation preference, EnableItemGroups is actually more a cataloging preference, since it pertains to grouping the items in a record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 35058] New: No contents displaying when an authority record is saved
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '23

27 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35058 Bug ID: 35058 Summary: No contents displaying when an authority record is saved Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I believe this has to do with our changes for tabs: When an authority record is edited and saved, you get directed to the authority detail page, but only the tabs themselves and no contents show. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 33879] New: Cookie_auth overwrites interface set by get_template_and_user
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '23

27 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33879 Bug ID: 33879 Summary: Cookie_auth overwrites interface set by get_template_and_user Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org >From bug 33608 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 32965] New: System logs show incorrect interface after logging into SCO and OPAC
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '23

27 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32965 Bug ID: 32965 Summary: System logs show incorrect interface after logging into SCO and OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org I'm not totally sure if this is a Koha issue or a KTD issue (or, for that matter, whether there's a real-life use case where this would come up)... To reproduce on KTD: 1. Log into the staff client (using the koha/koha login) 2. Log into the SCO module by going directly to cgi-bin/koha/sco/sco-main.pl (also using the koha/koha login) 3. Log into the main OPAC page (also using the koha/koha login) 4. Return to staff client. 5. Perform some checkouts, returns, renewals, and fee payments. 6. Check recent entries in the system logs. Result: The staff client will not ask you to log in again in step 4. Further checkouts, returns, renewals, and accounts payments from the staff client will be logged as having originated from the OPAC interface, instead of the intranet interface. Logging out of the staff client and back in will fix the issue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 35385] New: Typo in ILL template
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '23

27 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35385 Bug ID: 35385 Summary: Typo in ILL template Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org There is in koha-tmpl/intranet-tmpl/prog/en/includes/ill-batch-modal-strings a sentence "Unable to updatecreate batch request". Should it be "Unable to update batch request"? The sentence above this one is "Unable to create batch request" -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 35384] New: New Arrivals Display
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '23

27 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35384 Bug ID: 35384 Summary: New Arrivals Display Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: iiglibrary1(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org how to create a slideshow of new arrivals (manually or automatically) using Koha 23.05. I am trying the option of RSS feeds using https://feed.mikle.com/ however, not successful. I tried manually writing a script, but am unable to find the option of OPAC MainUserBlock in which to copy, paste and run the script. Kindly help and guide. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 35382] New: Possibly unreasonable condition for showing "Set" row in biblio marc detail template (checking character in leader field instead of presence of 773 field)
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '23

27 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35382 Bug ID: 35382 Summary: Possibly unreasonable condition for showing "Set" row in biblio marc detail template (checking character in leader field instead of presence of 773 field) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org In these two places for opac/intranet: - https://github.com/Koha-Community/Koha/blob/f587d0a3620c94d4777fff8506b56f2… - https://github.com/Koha-Community/Koha/blob/f587d0a3620c94d4777fff8506b56f2… ```  <xsl:if test="$leader19='c'"> <span class="results_summary set"><span class="label">Set: </span> <xsl:for-each select="marc:datafield[@tag=773]"> ``` it is tested whether 19th character of leader equals "c" in order to display "Set:" row enlisting contents of field 773. Is this reasonable and expected behavior? A librarian has pointed this out to me asking what makes this field appear while it's empty and none of the normal fields seem to suggest its appearance, and I found this out. But I wasn't able to find out the reasoning for this check, given it was already there the very moment the file was created to begin with 11 years ago. I think it would be more reasonable to show this and enlist Sets only if there are non-zero occurences of field 773, right? And the condition checks arbitrary character in leader field instead, which I'm not entirely sure if it's standardised either, given our source of biblio records had the field there defined, but no 773 fields. And the other way around, we found records where field 773 was expected and present, but the "c" character condition wasn't fulfilled then on the other hand! So I suggest that this check should be replaced by a check for whether there's any 773 fields. Also, take a look at other occurences of $leader19 var, it's checked to show "Set" somewhere above where the field is... "a" on the other hand? While in our bibliographic records with field 773, that character instead seemed to be a space. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 14293] Error in the calculation of the suspension of users per day
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '23

27 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14293 --- Comment #52 from Thibaud Guillot <thibaud.guillot(a)biblibre.com> --- (In reply to Marcel de Rooy from comment #50) > FAIL > FAIL git manipulation > The file has been added and deleted in the same patchset > > OK C4/Circulation.pm > > WARN C4/Overdues.pm > WARN tidiness > The file is less tidy than before (bad/messy lines before: > 122, now: 125) > > WARN t/db_dependent/Circulation/maxsuspensiondays.t > WARN tidiness > The file is less tidy than before (bad/messy lines before: > 52, now: 77) > > > Processing additional checks > > * Signed-off-by line ' Signed-off-by: Arthur Suzuki > <arthur.suzuki(a)biblibre.com>' seems invalid > * Signed-off-by line ' Signed-off-by: Mark Tompsett > <mtompset(a)hotmail.com>' seems invalid > * Signed-off-by line ' Signed-off-by: Mark Tompsett > <mtompset(a)hotmail.com>' seems invalid > > Running tests (1) > * Proving > /usr/share/koha/t/db_dependent/Circulation/maxsuspensiondays.t KO! > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st > execute failed: Incorrect datetime value: 'SCALAR(0x5595a6847398)' for > column `koha_myclone`.`borrowers`.`updated_on` at row 1 at > /usr/share/koha/Koha/Object.pm line 170 > Invalid value passed, borrowers.updated_on=SCALAR(0x5595a6847398) expected > type is datetime # Looks like your test exited with 11 before it could > output anything. > /usr/share/koha/t/db_dependent/Circulation/maxsuspensiondays.t .. > Dubious, test returned 11 (wstat 2816, 0xb00) > Failed 4/4 subtests Thanks for your feedback, I've rebased it and hope it's ok now for the order and bad commit messages. For the tests I don't understand because it was and still is okay on my instance. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14293] Error in the calculation of the suspension of users per day
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '23

27 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14293 Thibaud Guillot <thibaud.guillot(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #159128|0 |1 is obsolete| | Attachment #159129|0 |1 is obsolete| | --- Comment #51 from Thibaud Guillot <thibaud.guillot(a)biblibre.com> --- Created attachment 159277 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159277&action=e… Bug 14293: The suspension should be calculated in days There was a mismatch between bug 13909 and bug 5549. The get_chargeable_units call from _debar_user_on_return should specify that we want a suspension in days. However I don't understand the comment let by the author of bug 5549 f61a9617184ec4b24100c1d99150bfd4ebf13336 1/ > finedays is in days, so hourly loans must multiply by 24 Yes but the suspension is in days, so no need to * 24 2/ And we should have a look on this one too: > grace period is measured in the same units as the loan But the grace period is always in days. On the circ rules the column is "Fine grace period (day)". I think we should replace DateTime::Duration->new( $unit => $issuingrule->{firstremind} ); with DateTime::Duration->new( days => $issuingrule->{firstremind} ); Anyway, we definitelly need more tests in this area! Test plan: 1/ Define an issuing rule with a unit=hour 2/ Set a suspension in days 3/ Check an item out and specify a past due date. 4/ Check the item in 5/ The patron should be debarred correctly -- You are receiving this mail because: You are watching all bug changes.

1 0