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

[Bug 38254] New: Patron auto-complete search explodes when dateexpiry is NULL
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38254 Bug ID: 38254 Summary: Patron auto-complete search explodes when dateexpiry is NULL Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com This was moved from bug 31143: > We either need to fix the auto-complete patron search or have the > script re-calculate the dateexpiry from the patron category. I am > leaning towards making the patron search deal with NULL. borrowers.dateexpiry can be NULL so the code needs to be fixed. I have not tried it but this would be the idea: iff --git a/koha-tmpl/intranet-tmpl/prog/js/staff-global.js b/koha-tmpl/intranet-tmpl/prog/js/staff-global.js index 73a4a0251e1..28060fb35da 100644 --- a/koha-tmpl/intranet-tmpl/prog/js/staff-global.js +++ b/koha-tmpl/intranet-tmpl/prog/js/staff-global.js @@ -694,10 +694,13 @@ function patron_autocomplete(node, options) { } let new_date = new Date(); let today = Date.parse($date_to_rfc3339($date(new_date.toString()))); - let expiration = Date.parse( - $date_to_rfc3339($date(item.expiry_date.toString())) - ); - let expired = today > expiration; + let expired = false; + if (item.expiry_date){ + let expiration = Date.parse( + $date_to_rfc3339($date(item.expiry_date.toString())) + ); + expired = today > expiration; + } return $("<li></li>") .addClass(loggedInClass) .data("ui-autocomplete-item", item) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 36454] New: Staff - Provide indication if a patron is expired when creating an ILL request
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36454 Bug ID: 36454 Summary: Staff - Provide indication if a patron is expired when creating an ILL request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, rebecca.bradshaw(a)nnuh.nhs.uk, tomascohen(a)gmail.com Creating an ILL request, when staff adds a patron, there is no indication that the patron is expired, if said patron is indeed expired. Part of the problem tackling this, I believe, is that the 'create form' is ILL backend specific, so this should be tackled at each ILL backend level. Having said that, with bug 35570 in the pipeline, we could perhaps consider adding this little enhancement as a follow-up to that. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 37478] New: bulkmarcimport.pl can die on bad records
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37478 Bug ID: 37478 Summary: bulkmarcimport.pl can die on bad records Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz bulkmarcimport.pl will die on xml parsing errors when trying to convert the saved metadata (marcxml) back into a MARC::Record object Two cases we have seen are an invalid characters: :9: parser error : PCDATA invalid Char value 31 <controlfield tag="003">aPGcC</controlfield> and invalid/missing subfield: :91: parser error : attributes construct error <subfield code=""">Among nineteenth-century women's rights reformers, Elizab It turns out MARC::Record can read the incoming file - we can convert it to xml to save as metadata, but only on trying to create the record out of the xml do we die. This may point to a bug in MARC::Record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 36117] New: Can svc/bib_profile be removed?
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36117 Bug ID: 36117 Summary: Can svc/bib_profile be removed? Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Is this used? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 38824] New: Document the use of type field in packages (ERM)
by bugzilla-daemon＠bugs.koha-community.org 04 Jan '25

04 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38824 Bug ID: 38824 Summary: Document the use of type field in packages (ERM) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de The use of "type" field is not explained. What are the meaning of the standard default values, and the recommended use of this field? The standard default value in ERM_PACKAGE_TYPE AV are "complete" and "local" In EBSCO knowlegde base, the values are "complete", "variable", "selectable" and "custom", with meanings explained here : https://connect.ebsco.com/s/article/What-are-the-available-Package-Types-in… If EBSCO eHoldings are used in Koha (with HoldingsIQ API), I suppose those values are going to be used ? So maybe the standard values in ERM_PACKAGE_TYPE should be updated to reflect that ? But is this field of any use if you do not use EBSCO eHoldings? Do you need to select the value "local" ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 38796] New: ERM : record for print documents should not be imported into ERM
by bugzilla-daemon＠bugs.koha-community.org 04 Jan '25

04 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38796 Bug ID: 38796 Summary: ERM : record for print documents should not be imported into ERM Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Not sure if it is a bug or not, but I don't understand the purpose of importing records of "print" documents (without a link in 856) into ERM Currently Koha imports them but the field "coverage_depth" takes the value "print" Is it useful for some workflows ? Perhaps those records should better not be taken into account if they are present in the list ? -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 04 Jan '25

04 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #142 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- Comment 125: > Would it be useful to include a test case [...] This and the previous comment are about automated tests. Comment 126 mentions "test plan" which usually refers to the manual test plan for signing off. And then it says "from the interface" And «if a change like this is not tested thoroughly now on the interface, we might overlook stuff..» «In that regard an additional outside sign-off would be welcome.» So that really looks like to be about expanding the test plan to have a more reliable signoff. Thanks for all the follow ups with automated tests, they are really valuable now and in the future! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15461] Add shelving location to holdings table as a separate column
by bugzilla-daemon＠bugs.koha-community.org 04 Jan '25

04 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #175857|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15461] Add shelving location to holdings table as a separate column
by bugzilla-daemon＠bugs.koha-community.org 04 Jan '25

04 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david(a)davidnind.com --- Comment #43 from David Nind <david(a)davidnind.com> --- The text in the shelving location column is still in italics. This made sense when the value was displayed under the home library, but doesn't now with this change. Odd behavour noticed with the holdings table (not related to this bug): - If you click "Show filters", then all the available columns are shown, not just the default columns. - If you click "Hide filters", all of the available columns are still shown, it doesn't go back to just the default columns. I amended the commit message to fix the spelling. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15461] Add shelving location to holdings table as a separate column
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '25

03 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 --- Comment #42 from David Nind <david(a)davidnind.com> --- Created attachment 176142 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176142&action=e… Bug 15461: Add stand alone shelving location column to holdings table To test: 1. APPLY patch and restart_all 2. Go the detail page for some records and see the shelving location column. 3. Make sure the data looks correct 4. Try Table settings to make sure the column can be properly hidden NOTE: You cannot currently search the holdings table for AV descriptions, only the code. Signed-off-by: David Nind <david(a)davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

1 0