Bug 37600 - OpacSuppression does not work in UNIMARC out of the box
Summary: OpacSuppression does not work in UNIMARC out of the box
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Bibliographic data support (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 38336
Blocks:
  Show dependency treegraph
 
Reported: 2024-08-08 07:37 UTC by Igor A. Sychev
Modified: 2025-04-02 07:34 UTC (History)
6 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Igor A. Sychev 2024-08-08 07:37:59 UTC
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
Comment 1 Katrin Fischer 2024-08-08 09:20:34 UTC
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)
Comment 2 Fridolin Somers 2024-08-09 08:04:14 UTC
(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.
Comment 3 Katrin Fischer 2024-08-09 11:00:27 UTC
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?
Comment 4 Igor A. Sychev 2024-08-13 03:30:06 UTC
In UNIMARC: 9-- Local Fields
Comment 5 Katrin Fischer 2024-08-13 08:10:07 UTC
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.
Comment 6 Igor A. Sychev 2024-08-29 06:27:30 UTC
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.
Comment 7 Koha Team University Lyon 3 2024-08-29 08:13:24 UTC
(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
Comment 8 Katrin Fischer 2024-08-29 08:16:55 UTC
(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 :(
Comment 9 Mathieu Saby 2024-08-30 07:41:02 UTC
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)
Comment 10 Katrin Fischer 2024-08-30 08:51:13 UTC
Can you make a suggestion for the new name?
Comment 11 Mathieu Saby 2024-09-02 12:10:15 UTC
For the 099 field? Maybe "Local field (Koha)".
Or "Added entry elements (Koha)" like Marc21 942
Comment 12 Mathieu Saby 2024-10-27 13:49:33 UTC
I will submit a patch for fixing this issue
Comment 13 Laurence Rault 2025-04-01 14:20:30 UTC
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.
Comment 14 Mathieu Saby 2025-04-02 07:33:55 UTC
The choice between 099 and 942 will depend on the resolution of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336