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

[Bug 23924] New: Add a parameter to the script add_date_fields_to_marc_records.pl to specify a date field
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '24

25 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23924 Bug ID: 23924 Summary: Add a parameter to the script add_date_fields_to_marc_records.pl to specify a date field Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 22509 This date field will be used to set the date used in the script, instead of today. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22509 [Bug 22509] Add a script to generate MARC fields containing date formatted strings -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 35098] New: ILL batch is not displayed in ILL table
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '24

25 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35098 Bug ID: 35098 Summary: ILL batch is not displayed in ILL table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor 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, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 35096 To reproduce, k-t-d: 1) Install FreeForm and enable ILLmodule, run: bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.…) 2) Install an ILL availability plugin (e.g. pubmed): https://github.com/PTFS-Europe/koha-plugin-api-pubmed/releases/tag/1.1.1 3) restart plack: koha-plack --restart kohadev 4) Create a new ILL batch, visit: /cgi-bin/koha/ill/ill-requests.pl 5) Click '+New ILL requests batch' 6) Input a name, '42' on the cardnumber and pick a library. Click 'Continue'. 7) On the identifiers textarea, insert '123' and click 'Process identifiers' 8) After the metadata has been retrieved, click the bottom 'Add items to batch' button, click 'Finish and view batch' 10) Go back to ILL requests table, visit: /cgi-bin/koha/ill/ill-requests.pl 11) On the top right of the table, click 'Columns' and enable Batch 12) Notice the batch column is empty for the request we just created within a batch Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35096 [Bug 35096] ILL request manage page explodes if it belongs to a batch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 22605] New: Adding the option to modify search like in the OPAC (advanced search)
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '24

25 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22605 Bug ID: 22605 Summary: Adding the option to modify search like in the OPAC (advanced search) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Once we did an advanced search in the OPAC, we have have the option to modify the criterias of this last search ("Return to the last advanced search" just on top of the results list). But in the "on site" Koha we don't have this option. Wchich can save a lot of time when we have long and precise searches to do allowing to refine the criterias rather than enter all of them again. Thanks, Alexandre -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 97

[Bug 31769] New: We need a clear guideline regarding how to display 'filters' and 'sidebar nav' at the same time
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '24

25 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31769 Bug ID: 31769 Summary: We need a clear guideline regarding how to display 'filters' and 'sidebar nav' at the same time Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 We really should consistently use the left sidebar for module navigation.. but this raises the question of what to do with the 'filters' option some pages use that area for.. we should come up with a solution that allows for both displays in a coherant manner. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 32031] New: Sidebars and Breadcrumbs
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '24

25 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32031 Bug ID: 32031 Summary: Sidebars and Breadcrumbs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 With the staff client refresh I've had a nagging feeling about the breadcrumbs appearing above the sidebar navs.. it feels a bit messy but I hadn't come up with a better solution. I wonder about shifting the sidebar so it goes all the way to just under the top header and shift the breadcrumbs to the right... a bit like gitlab? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 34294] New: Bottom tabs inconsistent with moremember.tt on circulation.tt
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '24

25 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34294 Bug ID: 34294 Summary: Bottom tabs inconsistent with moremember.tt on circulation.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 Depends on: 33528 We streamlined and improved the bottom content block of the member details and circulation pages in bug 33528. But as we don't pass fines as a template parameter in circulation.pl we don't get the benefit of displaying that tab in circulation.tt yet, thus we're still inconsistent with moremember.tt displays. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33528 [Bug 33528] Use template wrapper for tabs: Patron details and circulation -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 34839] New: Shouldn't TinyMCE initialise with the Koha interface stylesheet?
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '24

25 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34839 Bug ID: 34839 Summary: Shouldn't TinyMCE initialise with the Koha interface stylesheet? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When we initialise TinyMCE in the HTML Customisation page we pass `content_css : "[% interface | html %]/[% theme | html %]/css/tinymce.css"`. Shouldn't we be passing the stylesheet/stylesheets of the interface we're editing rather than a specific tinymce sheet? That would more accurately represent how your content block is actually going to appear to the end user than it does now.. for example taking account of page-section classes if you add such a div into your markup? Or am I mis-understanding what the content_css option does? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 27825] New: Add preference for choosing the default format for patron barcodes
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '24

24 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27825 Bug ID: 27825 Summary: Add preference for choosing the default format for patron barcodes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: barbara.johnson(a)bedfordtx.gov, gmcharlt(a)gmail.com, lisetteslatah(a)gmail.com, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, testopia(a)bugs.koha-community.org Blocks: 26777 Whether we add scannable barcodes to the OPAC via a JS library (as suggested in Bug 26777) or via an API (Bug 26692), it would be good to provide the library with a way to define the format for the barcode output. This could also be used as the default in the patron card creator. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26777 [Bug 26777] Give the user the option to display their patron card barcode from the OPAC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 34122] New: Updating Shelvingloc changes location of all related records
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '24

24 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34122 Bug ID: 34122 Summary: Updating Shelvingloc changes location of all related records Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Partners have reported that updating the shelving location on one item updates all of the items in the record regardless of their branch location. For example, Branch A has Item A located in the Genealogy department, and Branch B has it in their Reference section. Changing the location in Branch A to Genealogy will also change the shelving location for Branch B to Genealogy even if Branch B doesn't have a Genealogy shelving location. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 32707] New: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields)
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '24

24 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32707 Bug ID: 32707 Summary: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com Koha with Zebra prevented auto truncation in some circumstances -- see the first return for ccl inside C4::Search:: buildQuery, before applying auto truncation, and setting $auto_truncation = 0 for some search fields. Koha with ElasticSearch applies auto truncation for all search fields, not paying attention to these special cases when it should not be done. This leads to various problems as described in bug 26508, 26608, etc. The solution would be to prevent auto truncation for certain search fields, above all – the identifiers. In addition, under no circumstances should a search field other than of text type be truncated (an attempt to truncate would generate an exception from ElasticSearch, e.g. number_format_exception for integer). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61