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

[Bug 31551] New: Add a 'Quick add' option for harmful content warnings.
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31551 Bug ID: 31551 Summary: Add a 'Quick add' option for harmful content warnings. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 32799] New: ILLSTATUS authorized value category name is confusing
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32799 Bug ID: 32799 Summary: ILLSTATUS authorized value category name is confusing Change sponsored?: --- Product: Koha Version: 22.11 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 Bug 20581 introduced the ability to manually select custom ILL request statuses. These custom ILL request statuses are stored in the ILLSTATUS AV and are then stored in the status_alias column of illrequests. Staff members are lead to believe that ILL statuses are stored in the ILLSTATUS authorized values list when these are just aliases used for display purposes. The actual ILL statuses are fed from the backend or Koha::Illrequest. My suggestion would be rename this to ILL_STATUS_ALIAS or ILL_STATUS_ALIASES -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 22428] New: MARC modification template cuts text to 100 characters
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22428 Bug ID: 22428 Summary: MARC modification template cuts text to 100 characters 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When trying to update a field using a MARC modification template, it is impossible to put a value of over 100 characters. To reproduce: 1. Go to Tools > MARC modification templates 2. Click on 'New template' 3. Name your new template and click on 'Submit' 4. Click on 'New action' 5. Enter the following information in the form - 'Add new' - field(s): 856 y - with value: Organization-wide access - sign on to OnePass / Accès à l'échelle de l'organisation - Ouvrez une session (OnePass) 6. Click on Add action 7. Note that the text is cut in the displayed table 'Organization-wide access - sign on to OnePass / Accès à l'échelle de l'organisation - Ouvrez une ses' 8. Do a search to obtain a biblionumber 1. Make a search in the catalog 2. Click on the title to go to the detailed record 3. Click on the 'MARC' tab 4. The biblionumber is written next to MARC record: 5. Copy the biblionumber 9. Go to Tools > Batch record modification 10. In the 'List of biblionumbers...' text box, paste the biblionumber 11. Choose the template created at step 3 in the 'Modify record using the following template:' drop down menu 12. Click on 'Continue' 13. Click on 'Show MARC' to see the result of the modification (the added line is usually at the bottom, note that the text is still cut after 100 characters, so not only a display bug) 14. Click on 'Close' 15. Click on 'Modify selected records' 16. Click on the biblionumber to see the modified record 17. In the detailed record, the 856y field is under 'Online resources' (note that the text is still cut) I noticed that in the database, the field field_value in the table marc_modification_template_actions is limited to 100 characters. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 28126] New: Remove AllowPurchaseSuggestionBranchChoice from the Koha manual
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28126 Bug ID: 28126 Summary: Remove AllowPurchaseSuggestionBranchChoice from the Koha manual Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: erohlfs(a)equinoxinitiative.org QA Contact: testopia(a)bugs.koha-community.org In version 20.11, we saw the introduction of a new System Preference "OPACSuggestionUnwantedFields" and the removal of "AllowPurchaseSuggestionBranchChoice" via https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23420 This is a request to remove the AllowPurchaseSuggestionBranchChoice description from the official Koha manual. https://koha-community.org/manual/20.11/en/html/systempreferences.html#allo… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 30213] New: Hide Delete (aka Priority) column when user only has place_hold permission
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30213 Bug ID: 30213 Summary: Hide Delete (aka Priority) column when user only has place_hold permission Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the change to holds permissions in Bug 29540, the Delete (or Priority, with full holds permissions) column isn't useful and is misleading for users with only the place_hold permission. They don't have the option to change holds' priority using the column, and if they select 'del' on a patron to delete their hold, they get locked out for having insufficient permissions when they click the Update Hold(s) button. But this is misleading because they *can* delete an individual hold using the red X. It would be clearer if that entire column were hidden for users with only the place_hold permission. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 32994] New: Remove compiled files from src 2
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32994 Bug ID: 32994 Summary: Remove compiled files from src 2 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com small followup patch for bug 32609 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 32975] New: Error in package.json's definition of css:build vs css:build:prod
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32975 Bug ID: 32975 Summary: Error in package.json's definition of css:build vs css:build:prod Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 32609 package.json defines these commands: "css:build": "gulp css && gulp css --view opac", "css:build:prod": "gulp build && gulp css --view opac", The second one, css:build:prod is not running the "build" process for the OPAC. It should say "gulp build --view opac" Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32609 [Bug 32609] Remove compiled files from src -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 32806] New: Some Vue files need to be moved for better reusability
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32806 Bug ID: 32806 Summary: Some Vue files need to be moved for better reusability Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 32030 So far the Vue files are only used by the ERM module, but some needs to be move in a parent directory to make them reusable by another module. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 85

[Bug 32978] New: 'npm install' fails in ktd on aarch64, giving unsupported architecture error for node-sass
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32978 Bug ID: 32978 Summary: 'npm install' fails in ktd on aarch64, giving unsupported architecture error for node-sass Change sponsored?: --- Product: Koha Version: master Hardware: Macintosh OS: Mac OS Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org The summary already says it, but you can't build Koha's dependencies on aarch64 because it breaks on node-sass which has native bindings that demand x86_64. Therefore we should switch to sass (aka dart-sass) which doesn't have this problem . For a possible migration path, see https://dev.to/ccreusat/migrating-from-node-sass-to-sass-dart-sass-with-npm… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 29252] New: Document the uses of 942c (MARC21)
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29252 Bug ID: 29252 Summary: Document the uses of 942c (MARC21) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org There was a discussion on the mailing list about the reasons of 942c. See this thread : https://lists.katipo.co.nz/pipermail/koha/2021-October/056838.html >Good afternoon, > >I recall reading (in the Koha manual?) the explanation for why it is >advantageous to define Koha item type in the bib 942 field. I believe it >has to do with exporting records, or the scope of records that is included >when doing some type of report? I'm trying to locate that information >again, but can't find it for the life of me. > >Does this seem familiar to anyone? Thanks. > > >Tasha Bales ------------ >I can't find the information right now, though I know I've seen it somewhere. >My understanding is when importing a MARC record, 942$c is treated as the >item type in the bibliographic record, and 952$y is the item type >for the item record (assuming a 952 holding field was present). > >I have also observed that when you create a new item record from an >existing bib record, 942$c gets copied into the new item's type. So >it's helpful to make sure that the item type in the bib record was set >correctly when it was created (or imported). > >This wiki page talks about 952, but not 942: > >https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx) > >I'm sure someone more knowledgeable can correct this if I'm wrong. -------------------- >942$c - defines the type of material the bibliographic record represents, >sort of like it's GMD (general material description). Has no bearing on >circulation of material. Stored as marcxml in biblio_metadata. > >952$y - defines the item-level item, and is used mandatorily for Koha's >circulation rules which work as a permutation of (a) branchcodes (b) patron >categories and (c) item-level item types. Stored as itype column in items >table. > >Hope this helps >Indranil --------------------- >952$y is mandatory for circulation IF item-level_itypes is set to "specific >item". Otherwise, 942$c is used as the item type for circulation. > >Another thing that I have observed about 942$c is that it is indexed for the >search in the same way as 952$y. So if you have records without items (for >journal articles, websites or ebooks for example), these will still be >searchable through the item type filter. > >Also, if 942$c and 952$y are not the same in one record (for example, 942$c is >Book and 952$y is Reference), they will show in the results of a search for >either type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1