https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #1 from Phil Ringnalda <phil@chetcolibrary.org> --- *** Bug 37788 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #3 from Phil Ringnalda <phil@chetcolibrary.org> --- Oh, and we should probably consider the Fast Add framework too, since it only has 099$t and not 942$c - if the reason for TYPEDOC is something like FRBR, umm, Fast Added FRBR? Neato! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #5 from Mathieu Saby <mathsabypro@gmail.com> --- I had time to do some archeology : Before bug 30373 (conversion to yaml, and suppression of the french framework) the french UNIMARC framework was quite different from the english one. The new yaml framework seems to have inherited from both, in a way that is not completely correct. * History of the french UNIMARC framework before its conversion to yaml : In 2008 : At biblio level : - no 942 field - 099 field "information locales" (local information) only used for creation and modification dates - 200$b field "type de document" (document type) <=> biblioitems.itemtype, linked to itemtypes AV - 686$a field "type (indice)" linked with itemtypes AV At item level : 995$r field "type de prêt" (type of loan) mapped with items.itype, linked to itemtypes AV Note that the label was "type of loan" and not "Type of item and material" like in the english framework Bug 6557 in 2012 : - creation of a 942 field "total des prêts" (number of checkouts) with only one subfield $0 Bug 11586 in 2014 : - 686$a and 200$b fields no longer mapped with biblioitems.itemtype neither linked to any AV - new subfield 099$t "Type de document" (document type) <=> biblioitems.itemtype, not linked to any AV - new subfield 099$x "Nombre de prêts" (number of checkouts) <=> biblioitems.totalissues => duplicate of 942$0 ! At item level : 995$r field "type de prêt" has now a default value "PRETLIV" (loan of book) => weird because it did not fit the values defined in sample_itemtypes.sql At that point (just before the framework conversion to yaml) 099$t and 995$r were both mapped to biblioitems.itemtype, BUT only 995$r were linked to itemtypes AV. French libraries were free to linked their 099$t to the AV of their choice (like "TYPEDOC") ======== Changes to english UNIMARC framework : In 2008 : At biblio level : 990 field "ADDED ENTRY ELEMENTS (KOHA)", with: 990$0 : Koha issues (borrowed) <=> biblioitems.totalissues 990$c : Koha item type <=> biblioitems.itemtype ; linked to itemtypes AV At item level : 995$r field "Type of item and material", mapped with nothing, not linked to any AV Bug 5128 in 2010 (at the initiative of the Italian Zeno Tajoli https://lists.koha-community.org/pipermail/koha-devel/2010-July/034235.html ) - Removal of 990 field - Creation of 099 field "local dates" : same use as 099 of fr-FR framework, but with a different name, more restrictive (in french it was "local information" - Creation of 942 field "ADDED ENTRY ELEMENTS (KOHA)", with : 942$0 : Koha issues (borrowed) <=> biblioitems.totalissues 942$c : Koha item type <=> biblioitems.itemtype ; linked with itemtypes AV At item level : the 995$r field (Type of item and material) is mapped with 'items.itype' and linked with 'itemtypes' At that point (just before the framework conversion to yaml) 942$c and 995$r were both mapped to biblioitems.itemtype, AND linked to itemtypes AV (contrary to the french framework). The use of 099 was more restricted than in french framework, the use of 942 much broader. And the wording of 099, 942 and 995$r were different from french framework. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Mathieu Saby from comment #6)

By the way, this bug is linked : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38042

I have just added a comment there explaining a bit why I think UNIMARC should change that and introduce a proper field for document type instead. The current mapping requires patching again and again and you STILL have broken features available to MARC21 users that rely on it being an itemtype in the record and not something else. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #9 from David Nind <david@davidnind.com> --- As France uses UNIMARC (as well as some other countries), I would suggest getting some feedback from the KohaLa user group (https://koha-fr.org/liste-koha-infos/) and perhaps from the chat channel (koha-Francophone). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #10 from Mathieu Saby <mathsabypro@gmail.com> --- Oh I tried the list, being a member of Kohala. There seems to be no interest for the subject, or more probably a lack of cataloging skills in our librairies, due to changes in recruitment policy... And I asked on Mattermost too. If there are no objection I will provide a patch this weekend -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m --- Comment #12 from David Nind <david@davidnind.com> --- I've added Fridolin from BibLibre to the cc list. Maybe, he can ask someone from BibLibre to have a look or provide some comment (I think they may look after one or two UNIMARC libraries 8-)). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #14 from David Nind <david@davidnind.com> --- +1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #16 from Mathieu Saby <mathsabypro@gmail.com> --- Created attachment 178126 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178126&action=edit Bug 38336: Fix confusion between 099 and 942 UNIMARC fields This patch fixes 099 and 942 fields (and incidentally 200$b) in the default and the FA UNIMARC frameworks and provides the changes that follow logically : - Zebra and Elasticsearch indexing - removal of the unused TYPEDOC authorized values category - UNIMARC facets in Koha.pm - test in TestBuilder.pm These changes are minimal and are intended to correct only the most serious problems. Subsequent work may bring improvements. Detail of changes : - The 099 field is renamed "Local dates (Koha)" and should be used in default configuration only for this storing creation and modification dates of record. - The 942 field is mandatory (because its $c subfield is) and should be used for all other Koha local information, like its MARC21 counterpart. - The 200$b field is no more indexed (it is now obsolete in cataloguing standards, and its MARC21 counterpart is not indexed). - Like in MARC21, ccode is now defined only at item level and itemtype/itype is now defined at item and biblio level. - The default values for itemtype at biblio and item level are the same, controlled by itype values (document type). - The TYPEDOC authorized values category, which was used for controlling the value if itemtype at record level, is removed. - In Koha.pm UNIMARC facets are fixed to be a mirror of MARC21 facets: a facet for itemtypes is created, and the facet for ccode is now based only on items. - A test on record-level itemtype in TestBuilder.pm is fixed in order to replace 099 with 942 field. Test plan: Note that sample data in ktd and sandbox will need to be fixed once this patch is pushed (there is no data in 942$c for example). It may cause warnings if you edit existing record but it is not a bug. A. Check framework changes 1/ In a UNIMARC k-t-d or sandbox, with Zebra search engine 2/ Apply the patch 3/ Check default and FA framework - 099 should be labelled "Local dates (Koha)" and contain 2 subfields:c and d - 942 should be mandatory, labelled "ADDED ENTRY ELEMENTS (Koha)" and contain 5 subfields : 0,2,6,c (mandatory),s 4/ Create a new record with default framework -- add a 200$a field, a 100$a field (with the cataloging plugin) -- in 942$c field, check that the values in dropdown list are the one defines for 'item types' in administration (Books, Computer Files, Continuing Resource, etc). -- Choose the value "Computer field" and Save the record -- Koha displays the item creation form. Check that the preselected value in 995$r (item type) is "Computer field" 5 / Do the same operation for a new record with FA framework B. Check Zebra indexing changes 6 / Search "livre" in the catalog. 419 results should be shown 7 / Check that an "Item type" facet is visible and functional 8 / Edit the first record of the result list, change its 942$c value and save 9 / Edit an item of that record and change the 995$r value (with a value different from the 942$c) and the 995$h value (3 possible values: Non-fiction, Fiction, Reference) 10 / Refresh the search for "livre" 11 / Check that the facet "Item types" has been updated and that a facet "Collections" is shown (from the 995$h) and functional C. Check Elasticsearch indexing changes 12 / I believe you cannot currently test Elasticsearch in a sandbox, so, open a new k-t-d with Elasticsearch search engine (ktd --es7 up) 13 / Repeat operations 6 to 11 in that new instance (277 results should be shown after the search in step 6, instead of 419 for Zebra, this is normal) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |normal -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178126|0 |1 is obsolete| | --- Comment #18 from Mathieu Saby <mathsabypro@gmail.com> --- Created attachment 179007 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179007&action=edit Bug 38336: Fix confusion between 099 and 942 UNIMARC fields This patch fixes 099 and 942 fields (and incidentally 200$b) in the default and the FA UNIMARC frameworks and provides the changes that follow logically : - Zebra and Elasticsearch indexing - removal of the unused TYPEDOC authorized values category - UNIMARC facets in Koha.pm - test in TestBuilder.pm These changes are minimal and are intended to correct only the most serious problems. Subsequent work may bring improvements. Detail of changes : - The 099 field is renamed "Local dates (Koha)" and should be used in default configuration only for this storing creation and modification dates of record. - The 942 field is mandatory (because its $c subfield is) and should be used for all other Koha local information, like its MARC21 counterpart. - The 200$b field is no more indexed (it is now obsolete in cataloguing standards, and its MARC21 counterpart is not indexed). - Like in MARC21, ccode is now defined only at item level and itemtype/itype is now defined at item and biblio level. - The default values for itemtype at biblio and item level are the same, controlled by itype values (document type). - The TYPEDOC authorized values category, which was used for controlling the value if itemtype at record level, is removed. - In Koha.pm UNIMARC facets are fixed to be a mirror of MARC21 facets: a facet for itemtypes is created, and the facet for ccode is now based only on items. - A test on record-level itemtype in TestBuilder.pm is fixed in order to replace 099 with 942 field. Test plan: Note that sample data in ktd and sandbox will need to be fixed once this patch is pushed (there is no data in 942$c for example). It may cause warnings if you edit existing record but it is not a bug. A. Check AV and framework changes 1/ In a UNIMARC k-t-d or sandbox, with Zebra search engine 2/ Apply the patch 3/ Check that there is no "TYPEDOC" authorized value category 4/ Check default and FA framework - 099 should be labelled "Local dates (Koha)" and contain 2 subfields:c and d - 942 should be mandatory, labelled "ADDED ENTRY ELEMENTS (Koha)" and contain 5 subfields : 0,2,6,c (mandatory),s 5/ Create a new record with default framework -- add a 200$a field, a 100$a field (with the cataloging plugin) -- in 942$c field, check that the values in dropdown list are the one defines for 'item types' in administration (Books, Computer Files, Continuing Resource, etc). -- Choose the value "Computer field" and Save the record -- Koha displays the item creation form. Check that the preselected value in 995$r (item type) is "Computer field" 6/ Do the same operation for a new record with FA framework B. Check Zebra indexing changes 7 / Search "livre" in the catalog. 419 results should be shown 8 / Check that an "Item type" facet is visible and functional 9 / Edit the first record of the result list, change its 942$c value and save 10 / Edit an item of that record and change the 995$r value (with a value different from the 942$c) and the 995$h value (3 possible values: Non-fiction, Fiction, Reference) 11 / Refresh the search for "livre" 12 / Check that the facet "Item types" has been updated and that a facet "Collections" is shown (from the 995$h) and functional C. Check Elasticsearch indexing changes 13 / You cannot currently test Elasticsearch in a sandbox, so, open a new k-t-d with Elasticsearch search engine (ktd --es7 up) 14 / Repeat operations 7 to 12 in that new instance (277 results should be shown after the search in step 7, instead of 419 for Zebra, this is normal) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Andreas Roussos <a.roussos@dataly.gr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |a.roussos@dataly.gr -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |37600 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37600 [Bug 37600] OpacSuppression does not work in UNIMARC out of the box -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #20 from Mathieu Saby <mathsabypro@gmail.com> --- Following an discussion with Laurence Rault : maybe we could get rid of 942 and use only 099, or get rid of 099 and use only 942 (by copying the 2 remaining fields in 099 into unused 942 fields, such as 942$A or 942$B). My choice was to keep both, as both are curently defined in default framework. Completely changing the way "Koha" information is managed in UNIMARC records would require a much heavier patch, and would be more complex to test. Maybe we could consider this one as a "fix" (since Koha in UNIMARC out of the box doesn't work properly...), and give ourselves the chance to rethink everything more deeply? In that case, we'd need to seek the opinion not only of the French-speaking UNIMARC community, but also that of other countries (Italy, Portugal, etc.), which could take a long time. The advantage of using 942 would be to simplify documentation and align UNIMARC with MARC21. But perhaps 942 is used by UNIMARC data providers, or for data specific to some union catalogs (in France I can assure it is NOT used by SUDOC union catalog). In that case, using 099 as a default field could be an idea. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |release-notes-needed --- Comment #22 from David Nind <david@davidnind.com> --- I can't really comment authoritatively on UNIMARC, but everything worked as set out in the test plan. Testing notes (using KTD): 1. After applying the patch, run reset_all (this is required to update the sample data and remove the authorized value list no longer required) 2. Step 5 - the item type selected should be "Computer files" (not "Computer fields"). 3. I had some trouble with the collection facet, but I think that is more a data issue. If I made sure that a few records had a 942$c and the item had a 955$h and 955$r everything worked OK. 4. Elasticsearch: ktd --es7 up works fine using KTD. 5. I tested using Zebra and Elasticsearch, in both the staff interface and OPAC. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |baptiste.wojtkowski@biblibr | |e.com, | |julian.maurice@biblibre.com --- Comment #23 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Julian, Baptiste: Would anyone of you care to QA here ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #25 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- ping Victor or Fridolin (fredlibre) ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #27 from Mathieu Saby <mathsabypro@gmail.com> --- Thank you Paul for your feedback. Could you specify which changes should be made without discussion ? I don't see which changes will have consequencies on existing catalogues (if they are only applied on 25.11 instances). Could you be more specific please ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #29 from Mathieu Saby <mathsabypro@gmail.com> --- I wanted to stay close to the historical configuration, which combined 099 and 942 fields, but I understand the value of simplification. Placing all "koha-specific" information in a unique field, which could easily be 099 rather than 942, would be convenient, and a lot of libraries already have this kind of configuration. I can rewrite this patch by removing the three subfields from 942 that duplicate subfields from 099 (you mention 942$c and $s, but I believe there is also 942$0, which duplicates 099$x). A subsequent patch could deal with the "suppressed" flag (there is already a BZ for that) A last patch could allow us to get rid of 942 field completely by moving the rest of its subfields to 099 field. However, before doing any of this, I would like to send a general message to the koha-info list to check that there are no objections to this simplification (I highly doubt it!). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #30 from Mathieu Saby <mathsabypro@gmail.com> --- Created attachment 186392 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186392&action=edit Bug 38336: Fix confusion between 099 and 942 UNIMARC fields (updated) This patch fixes 099 and 942 fields (and incidentally 200$b) in the default and the FA UNIMARC frameworks and provides the changes that follow logically : - Zebra and Elasticsearch indexing - removal of the unused TYPEDOC authorized values category - UNIMARC facets in Koha.pm These changes are minimal and are intended to correct only the most serious problems. Subsequent work may bring improvements. Detail of changes : - The 099 field is renamed "ADDED ENTRY ELEMENTS (KOHA)" like 942 in MARC21, and should be used in the same way. It is mandatory, because the 099$t (item type) is mandatory - The 942 field is renamed "OTHER ADDED ENTRY ELEMENTS (KOHA)". It is not mandatory, and may removed by subsequent Bugzilla bugs. - Subfields $c and $s are removed from 942 because they are already defined in 099 - The 200$b field is no more indexed (it is now obsolete in cataloguing standards, and its MARC21 counterpart is not indexed). - Like in MARC21, ccode is now defined only at item level and itemtype/itype is now defined at item and biblio level. - The default values for itemtype at biblio and item level are the same, controlled by itype values (document type). - The TYPEDOC authorized values category, which was used for controlling the value if itemtype at record level, is removed. - In Koha.pm UNIMARC facets are fixed to be a mirror of MARC21 facets: a facet for itemtypes is created, and the facet for ccode is now based only on items. Test plan: Note that sample data in ktd and sandbox may need to be fixed once this patch is pushed. It may cause warnings if you edit existing record but it is not a bug. A. Check AV and framework changes 1/ In a UNIMARC k-t-d or sandbox, with Zebra search engine 2/ Apply the patch 3/ Check that there is no "TYPEDOC" authorized value category 4/ Check default and FA framework - 099 should be labelled "ADDED ENTRY ELEMENTS (KOHA)" and contain subfields c, d, t (item type), s (serial flag), x (totalissues) - 942 should be labelled "OTHER ADDED ENTRY ELEMENTS (KOHA)" and contain subfields 2 and 6 5/ Create a new record with default framework -- add a 200$a field, a 100$a field (with the cataloging plugin) -- in 099$t field, check that the values in dropdown list are the one defines for 'item types' in administration (Books, Computer Files, Continuing Resource, etc). -- Choose the value "Computer field" and Save the record -- Koha displays the item creation form. Check that the preselected value in 995$r (item type) is "Computer field" 6/ Do the same operation for a new record with FA framework B. Check Zebra indexing changes 7 / Search "livre" in the catalog. 419 results should be shown 8 / Check that an "Item type" facet is visible and functional 9 / Edit the first record of the result list, change its 099t value and save 10 / Edit an item of that record and change the 995$r value (with a value different from the 099$t) and the 995$h value (3 possible values: Non-fiction, Fiction, Reference) 11 / Refresh the search for "livre" 12 / Check that the facet "Item types" has been updated and that a facet "Collections" is shown (from the 995$h) and functional C. Check Elasticsearch indexing changes 13 / You cannot currently test Elasticsearch in a sandbox, so, open a new k-t-d with Elasticsearch search engine (ktd --es7 up) 14 / Repeat operations 7 to 12 in that new instance (277 results should be shown after the search in step 7, instead of 419 for Zebra, this is normal) Sponsored-by: Université Côte d'Azur -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Change sponsored?|--- |Sponsored -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #33 from David Nind <david@davidnind.com> --- Testing notes (using KTD): 1. Step 2: run reset_all after applying the patches 2. Step 8: With Zebra, the item types facet was only visible after changing a record, or using a search term where a valid item type is used in 099$t. Most records have "LIVRE (Not an authorised value)" for 099$t. No item types facet was shown when searching for "livre". Otherwise, everything else works as per the test plan. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #35 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Laurence Rault from comment #28)

The changes that could be made without discussion from my point of view are : - The 200$b field is no more indexed (it is now obsolete in cataloguing standards, and its MARC21 counterpart is not indexed). - The TYPEDOC authorized values category, which was used for controlling the value if itemtype at record level, is removed. - The default values for itemtype at biblio and item level are the same, controlled by itype values (document type). - In Koha.pm UNIMARC facets are fixed to be a mirror of MARC21 facets: a facet for itemtypes is created, and the facet for ccode is now based only on items.

However, I think that it would be better to keep all the local data in one 099 field, instead of splitting between 099 (for the dates) and 942. This choice does not concern unimarc standard, it has no impact regarding the functionality, but a lot of Unimarc libraries now in France are using the 099. It is handy to display all the Koha data in the same place. So I think there is no need to rename field 099 to "Local dates (Koha)" For the field 099, I would propose : - 099$t : set itemtype instead of TYPEDOC

For the field 942 : - 942$c : remove the kohafield link and the authorised value - 942$s : remove the kohafield link no subfield should be mandatory in this field

Update the index accordingly

For the 099, we could also add : 099$o : hidden in opac, linked to the YES_NO authorized value But this may be another BZ

Laurence, could you please check the latest status of this patch in view of your comments? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #37 from Mathieu Saby <mathsabypro@gmail.com> --- It's not very motivating for a librarian like me to have to wait more than six months for my contributions to go through QA. Can't someone take care of this? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m QA Contact|testopia@bugs.koha-communit |andrew@bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #39 from Mathieu Saby <mathsabypro@gmail.com> --- Yikes. That doesn't look good... It's probably a copy-and-paste error on my part. Thanks for pointing it out. I'll take a closer look at it and try to provide a corrected patch if needed. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #41 from Mathieu Saby <mathsabypro@gmail.com> --- I am wrong, as I wrote in comment 29, there is currently duplicate information for totalissues between 099$x and 942$0... This patch removes 942$0 and fixes the indexation accordingly. But there was a mistake in the way it was done... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #43 from Mathieu Saby <mathsabypro@gmail.com> --- In Elasticsearch configuration file the initial patch wrongly adds 099$x to title-other-variant index, instead of totalissues index. This follow-up moves 099$x to the adequate section. To test : 1. Use k-t-d to run a Koha instance using Elasticsearch 2. Apply all the patches 3. In k-t-d run reset_all 4. Do some basic searches 5. Activate the syspref UpdateTotalIssuesOnCirc 6. Checkin any item to any patron 5. Search totalissues:1 => there should be 1 record -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #45 from Victor Grousset/tuxayo <victor@tuxayo.net> ---

4/ Check default and FA framework ... - 942 should be labelled "OTHER ADDED ENTRY ELEMENTS (KOHA)" and contain subfields 2 and 6

There is no 942 in FA framework. Should it be added in the fields & subfields copied in unimarc_sample_fastadd_framework.yml ? ----- testing notes:

1/ In a UNIMARC k-t-d or sandbox, with Zebra search engine 2/ Apply the patch

Apply before starting, the patch is for new installations. ----

8 / Check that an "Item type" facet is visible and functional

It also lists LIVR. Likely related to

Note that sample data in ktd and sandbox will need to be fixed once this patch is pushed

TODO that will be something to doublecheck in the future. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #47 from Mathieu Saby <mathsabypro@gmail.com> --- Please disregard the reference to the FA framework in the description and test plan. This is a remnant from an older version of the patch, which completely replaced the 099 field with the 942 field. The logic is now different: the primary field for "Koha" data is the 099 field. The 942 field contains only some secondary information. It is therefore not necessary to add a 942 to the FA grid. So, if there are no other objections, can we go back to "Signed off"? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #49 from Victor Grousset/tuxayo <victor@tuxayo.net> ---

Please disregard the reference to the FA framework in the description and test plan. This is a remnant from an older version of the patch

Thanks, no worries then :) The test plan and relevant parts of commit messages still need to be updated. So it doesn't require going through the comments to correct the info. The commit message/test plan should be able to mostly stand on their own as they are often looked first. And should represent the final version of sometimes many changes that happened in the ticket comments. Meanwhile I'll continue checking "C. Check Elasticsearch indexing changes" :) And since the whole test plan is split between the 2 commits, that's also something to amend in the 1st test plan => have a few words to say there is a test plan on the 2nd commit also. So it can't be missed. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #51 from Victor Grousset/tuxayo <victor@tuxayo.net> --- testing note: double check that ES is indeed used (in the about page) For some reason, I have to toggle the SearchEngine for it to be applied. Not caused by this patch but will trick you when testing. test of "Adds 099$x to totalissues (Elasticsearch)" ok :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #188438|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 --- Comment #55 from Mathieu Saby <mathsabypro@gmail.com> --- Maybe I should have keep the sign-off ? Victor now that you've started the QA, what do you think of it? -- You are receiving this mail because: You are watching all bug changes.