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

[Bug 10762] Make it possible to adjust the barcode height and width on labels
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '25

10 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 --- Comment #54 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm, I think it might have only been the 0.08 vs 0.8 and not the datatype. But this should have a new bug number now as the original is so old. the "oldness" could also explain why we didn't spot it. We did comparisons between the previous and the new, but not from 23.11 upwards. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39059] New: Do not use "semi: false" for .vue files
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '25

10 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39059 Bug ID: 39059 Summary: Do not use "semi: false" for .vue files Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 38664 .vue files are kept tidy since we introduced them. And the prettier rule "semi: false;" has been used since then. In JavaScript, the use of semicolons (;) to terminate statements is optional due to a feature called Automatic Semicolon Insertion (ASI). This mechanism allows developers to write code without explicit semicolons: the JS engine automatically inserts them where necessary. Pro: omitting semicolons leads to cleaner and more readable code by reducing visual clutter. Modern tools catch potential issues arising from ASI, making explicit semicolons redundant. However, relying only on ASI can introduce subtle bugs. For instance: ``` function getValue() { return { value: 42 } } ``` A semicolon is automatically inserted after the return statement: the function returns undefined instead of the object. This happens because it is interpreted as: ``` function getValue() { return; { value: 42 } } ``` Such unintended behavior can be avoided by explicitly using semicolons. One source: https://github.com/airbnb/javascript?tab=readme-ov-file#semicolons Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38664 [Bug 38664] Tidy the whole codebase -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 10762] Make it possible to adjust the barcode height and width on labels
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '25

10 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 --- Comment #53 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #52) > (In reply to Katrin Fischer from comment #51) > > (In reply to Marcel de Rooy from comment #50) > > > This patch set added an inconsistency in the db schema: > > > > > > kohastructure > > > + `scale_width` decimal(28,6) NOT NULL DEFAULT 0.08, > > > + `scale_height` decimal(28,6) NOT NULL DEFAULT 0.01, > > > > > > dbrev > > > ADD COLUMN scale_width FLOAT default 0.8 NOT NULL AFTER font_size > > > ADD COLUMN scale_height FLOAT default 0.01 NOT NULL AFTER scale_width > > > > > > > > > Could the authors of this patch set please give follow-up on that and > > > correct? Thanks. > > > > > > PS Not completely sure but I feel that for a scale like this DECIMAL would > > > be a better choice than FLOAT. > > > > Did we not fix this? It looks familiar at least and we did a lot of > > comparisons between updated and new. > > Ah. You are right. I didnt catch the correction on master. I came from 23.11 > here. > Master is fine indeed. No wait. I cannot find a correcting dbrev on master. So structure and DBIX schema are in sync. And a new install will have DECIMAL. But if you come from an upgrade, you will still have FLOAT because of the dbrev. Am I overlooking something? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10762] Make it possible to adjust the barcode height and width on labels
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '25

10 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 --- Comment #52 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #51) > (In reply to Marcel de Rooy from comment #50) > > This patch set added an inconsistency in the db schema: > > > > kohastructure > > + `scale_width` decimal(28,6) NOT NULL DEFAULT 0.08, > > + `scale_height` decimal(28,6) NOT NULL DEFAULT 0.01, > > > > dbrev > > ADD COLUMN scale_width FLOAT default 0.8 NOT NULL AFTER font_size > > ADD COLUMN scale_height FLOAT default 0.01 NOT NULL AFTER scale_width > > > > > > Could the authors of this patch set please give follow-up on that and > > correct? Thanks. > > > > PS Not completely sure but I feel that for a scale like this DECIMAL would > > be a better choice than FLOAT. > > Did we not fix this? It looks familiar at least and we did a lot of > comparisons between updated and new. Ah. You are right. I didnt catch the correction on master. I came from 23.11 here. Master is fine indeed. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10762] Make it possible to adjust the barcode height and width on labels
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '25

10 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 --- Comment #51 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Marcel de Rooy from comment #50) > This patch set added an inconsistency in the db schema: > > kohastructure > + `scale_width` decimal(28,6) NOT NULL DEFAULT 0.08, > + `scale_height` decimal(28,6) NOT NULL DEFAULT 0.01, > > dbrev > ADD COLUMN scale_width FLOAT default 0.8 NOT NULL AFTER font_size > ADD COLUMN scale_height FLOAT default 0.01 NOT NULL AFTER scale_width > > > Could the authors of this patch set please give follow-up on that and > correct? Thanks. > > PS Not completely sure but I feel that for a scale like this DECIMAL would > be a better choice than FLOAT. Did we not fix this? It looks familiar at least and we did a lot of comparisons between updated and new. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10762] Make it possible to adjust the barcode height and width on labels
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '25

10 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 --- Comment #50 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- This patch set added an inconsistency in the db schema: kohastructure + `scale_width` decimal(28,6) NOT NULL DEFAULT 0.08, + `scale_height` decimal(28,6) NOT NULL DEFAULT 0.01, dbrev ADD COLUMN scale_width FLOAT default 0.8 NOT NULL AFTER font_size ADD COLUMN scale_height FLOAT default 0.01 NOT NULL AFTER scale_width Could the authors of this patch set please give follow-up on that and correct? Thanks. PS Not completely sure but I feel that for a scale like this DECIMAL would be a better choice than FLOAT. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14322] Add option to create a shareable link for item searches
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '25

10 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14322 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39072 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39072 [Bug 39072] 24.11 - Item Search Shareable Link Adding Selections for Similar LOC Auth Values -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39073] New: UNIMARC value for coded data 135a
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '25

10 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39073 Bug ID: 39073 Summary: UNIMARC value for coded data 135a Change sponsored?: --- Product: Koha Version: unspecified 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: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org In French? koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_135a.tt ... 46 [% IF ( f1e ) %] 47 <option value="e" selected="selected">données bibliographiques</option> 48 [% ELSE %] 49 <option value="e">données bibliographiques</option> 50 [% END %] 51 [% IF ( f1f ) %] 52 <option value="f" selected="selected">polices de caractères</option> 53 [% ELSE %] ... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 17791] New: On UNIMARC system, USMARC field 100 gets overwritten
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '25

09 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17791 Bug ID: 17791 Summary: On UNIMARC system, USMARC field 100 gets overwritten Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: synapse.ova(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Overview: On Z39.50 search some functions depend not on the remote server marc flavour, but on current server setting. This bug is present on versions 3.22+ Steps to Reproduce: 1) On UNIMARC system, go to Cataloguing → New from Z39.50/SRU 2) Search USMARC server (Library of Congress, for example) for a book, that has field 100 (for example, isbn 0816310653) 3) On results list, press «MARC» to see MARC fields Actual Results: Instead of seeing the author name in subfield A, you'll see something like «20161219 frey50 », yet you could see other subfields properly Expected Results: Name of the author in 100$a Additional Information: LC Z39.50/SRW/SRU Server Configuration Guidelines: https://www.loc.gov/z3950/lcserver.html -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 38110] New: Staff interface tables with filters - date format needs to be YYYY-MM-DD, need to use authorized value codes
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '25

08 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38110 Bug ID: 38110 Summary: Staff interface tables with filters - date format needs to be YYYY-MM-DD, need to use authorized value codes Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When using filters on tables in the staff interface (for both "Search: ______ x Clear filter" and with "Show filters"): 1. Date fields: you need to enter the date in YYYY-MM-DD format, not the way it is displayed in the table 2. Fields using authorized values: you need to enter the code, rather than the description To replicate: 1. Go to a record in the staff interface with multiple items (for example record 146, The definitive guide to Catalyst : writing extensible, scalable, and maintainable Perl-based Web applications <staffinterfaceurl>/cgi-bin/koha/catalogue/detail.pl?biblionumber=146). 2. In the holdings table section, click "Show filters". 3. Using the "Search: ______ x Clear filter": 3.1 Enter "Midway" ==> no results 3.2 Enter "MPL" ==> one result 3.3 Enter "09/04" ==> no results 3.4 Enter "2014-09" ==> results Note: Bug 38071 fixes the "Clear filter" that is not working, in the meantime click "Hide filters" and "Show filters" or clear the text in the search box to clear. 4. Using the table column filters: 4.1 Click "Show filters" 4.2 In the "Last seen" column, start typing 09/04 ==> no results 4.2 In the "Last seen" column, start typing 2014-09 ==> no change as it matches data in the column, if you type 2014-09-01 you should get no results 4.3 In the "Collection" column, start typing "Reference" > no change until you get to "Refe", then you get no results as it is looking for the authorized value code 4.4 Note that the Item type, Current library, and Home library columns all use select lists, so you can't type a value in them. 5. Go to Patrons and click the "Search" button. 6. Perform searches similar to steps 3 and 4, and you will get similar results (use the "Date of birth" column for dates and "Library" or "Category" columns for authorized values). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14