OpacSuppression does not work in Unimarc. If I understood correctly, need to add <index_subfields tag="955" subfields="n"> <target_index>Suppress:w</target_index> <target_index>Suppress:n</target_index> </index_subfields> in https://git.koha-community.org/Koha-community/Koha/src/branch/main/etc/zebradb/marc_defs/unimarc/biblios/biblio-koha-indexdefs.xml
It's not quite enough, you also need to run a script to translate the readable entry. See here: https://wiki.koha-community.org/wiki/How_to_add_new_zebra_index (Step 5) For MARC21 the index is set up by default and I think it would be nice to have it also for UNIMARC Is 955$n OK to make the default for UNIMARC? (adding some other UNIMARC users/devs in CC)
(In reply to Katrin Fischer from comment #1) > > Is 955$n OK to make the default for UNIMARC? (adding some other UNIMARC > users/devs in CC) We largely use 099$o but I can't find a doc about this field. We already use it in Koha for 099 $c and $d.
If UNIMARC is similar to MARC21 it's maybe a custom field (like the 9xx in MARC). Do we know where the 955$n came from? We could index both maybe?
In UNIMARC: 9-- Local Fields
I would love to add an index to make it work out of the box for UNIMARC users, but I am a little worried about picking the wrong field. If the library has other data in the field already and OpacSuppression is activated, all those record would be hidden on update. I'd like to get some more opinions on the use of 9xx maybe, to see how much of a risk that would be.
There are big doubts that someone at Koha is using $955n for other purposes. And when you "move" from another ILS, all 9xxs are converted to the new 9xx.
(In reply to Igor A. Sychev from comment #6) > There are big doubts that someone at Koha is using $955n for other purposes. > And when you "move" from another ILS, all 9xxs are converted to the new 9xx. Hi, we do use 995$n for other purpose. For my library, this field is mapped with items.onloan. Sonia
(In reply to Koha Team University Lyon 3 from comment #7) > (In reply to Igor A. Sychev from comment #6) > > There are big doubts that someone at Koha is using $955n for other purposes. > > And when you "move" from another ILS, all 9xxs are converted to the new 9xx. > > Hi, > we do use 995$n for other purpose. For my library, this field is mapped with > items.onloan. > > Sonia Hi Sonia, thanks for letting us know. I am not sure how to get out of this situation really without causing pain for anyone :(
Hello If I understand well, in Marc21 this field is defined in 942, at record level. In my opinion the equivalent for Unimarc should be a subfield of 099 Currently in main, these subfields are used : c (date created),d (timestam),s (serial) ,t (record type),x (nb of issues) So why not 099$n ? (By the way the name of 099 field should be changed, it should not be "local dates" but something more generic)
Can you make a suggestion for the new name?
For the 099 field? Maybe "Local field (Koha)". Or "Added entry elements (Koha)" like Marc21 942
I will submit a patch for fixing this issue
Usually we use 099$o for the Suppress field at bibliographic level. It is not a Unimarc field, but a local one. The 'o' was defined by BibLibre years ago ('o' for opac), so I propose we use it for standard configuration.
The choice between 099 and 942 will depend on the resolution of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336