Bug 8331 - Hidden field does not hide from plain MARC and normal views in staff
Summary: Hidden field does not hide from plain MARC and normal views in staff
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Bibliographic data support (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Tomás Cohen Arazi
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-28 15:48 UTC by Eric P626
Modified: 2023-05-31 18:04 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric P626 2012-06-28 15:48:08 UTC
There is this bug that seem similar

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1756

But it does not seem to solve my problem. The hidden field does not hide what it should hide. The first problem is the documentation which is simply illogical if it's a simple bitfield:

---------------------------------------
9 => Future use
-8 => Flag
-7 => OPAC !Intranet !Editor Collapsed
-6 => OPAC Intranet !Editor !Collapsed
-5 => OPAC Intranet !Editor Collapsed
-4 => OPAC !Intranet !Editor !Collapsed
-3 => OPAC !Intranet Editor Collapsed
-2 => OPAC !Intranet Editor !Collapsed
-1 => OPAC Intranet Editor Collapsed
0 => OPAC Intranet Editor !Collapsed
1 => !OPAC Intranet Editor Collapsed
2 => !OPAC !Intranet Editor !Collapsed
3 => !OPAC !Intranet Editor Collapsed
4 => !OPAC Intranet Editor !Collapsed
5 => !OPAC !Intranet !Editor Collapsed
6 => !OPAC Intranet !Editor !Collapsed
7 => !OPAC Intranet !Editor Collapsed
8 => !OPAC !Intranet !Editor !Collapsed
9 => Future use
---------------------------------------

If you try to find the binary pattern in this you will not be able to do it. For example, I found that the 3rd bit ( value 4 ) trigers the display in the editor. According to the table above, 4 does not trigger it, but 5 does. But 5 is a combination of 4 and 1, so if 5 does, than 4 should block it too since 1 since used for collapsing.

According to my tests:

Bit 1 (value 1): Trigger the collapsing
Bit 2 (value 2): does nothing
Bit 3 (value 4): Hide the field from the editor
Bit 4 (value 8): does nothing
Sign Bit (+/-): does nothing

Which leave the following options not working:
Hide in OPAC
Hide in Intranet

I tried it with field 590 and field 300 which both are shown in OPAC and intranet.

I was wondering if there could be something else that could override the the hidden field.
Comment 1 Katrin Fischer 2015-01-06 18:53:46 UTC
In my testing it shows that hiding from the plain MARC view indeed does not work :(

To test:
- Edit a MARC framework - change 245$a to not display in OPAC and staff
- Check the plain MARC view in OPAC and staff
- Notice that the field still displays
- Notice that it hides correctly from the labelled MARC views
Comment 2 Katrin Fischer 2019-04-28 13:28:38 UTC
Confirmed, testing with 245$c this time.

Normal view and labelled MARC view are ok, plain MARC view displays the field.
Comment 3 Jonathan Druart 2019-10-16 09:20:50 UTC
(In reply to Katrin Fischer from comment #2)
> Confirmed, testing with 245$c this time.
> 
> Normal view and labelled MARC view are ok, plain MARC view displays the
> field.

I see it on both labelled MARC (catalogue/labeledMARCdetail.pl) and normal (catalogue/detail.pl) views. Tested with 245$h.


labeledMARCdetail.pl:
TITLE STATEMENT 	E Street shuffle : the glory days of Bruce Springsteen & the E Street Band / Clinton Heylin. this is 245$h

detail.pl (in the h1.title):
E Street shuffle : the glory days of Bruce Springsteen & the E Street Band / Clinton Heylin. this is 245$h 

MARC preview (from svc/records/preview):
245 	1 	0 	_aE Street shuffle :
_bthe glory days of Bruce Springsteen & the E Street Band /
_cClinton Heylin.
_hthis is 245$h 

Hidden in catalogue/MARCdetail.pl - OK

Note that catalogue/ISBDdetail.pl also displays the field (C4::Biblio::GetISBDView only hides the fields for OPAC):
 730                 # OPAC hidden subfield
 731                 next
 732                   if ( ( $template eq 'opac' )
 733                     && ( $tagslib->{$fieldvalue}->{$subfvalue}->{'hidden'} || 0 ) > 0 );
Comment 4 Katrin Fischer 2019-10-16 10:19:35 UTC
Thx Jonathan, I lost sight of this and it seems quite bad.
Comment 5 Katrin Fischer 2019-11-02 20:47:56 UTC
I think most important would be to fix the OPAC views - people want to hide things from patrons, staff views could be second priority.
Comment 6 Tomás Cohen Arazi 2020-03-30 17:32:56 UTC
(In reply to Katrin Fischer from comment #5)
> I think most important would be to fix the OPAC views - people want to hide
> things from patrons, staff views could be second priority.

I only reproduce on the svc/records/preview script. Can you please re-check?
Comment 7 Tomás Cohen Arazi 2020-05-15 22:39:16 UTC
(In reply to Katrin Fischer from comment #5)
> I think most important would be to fix the OPAC views - people want to hide
> things from patrons, staff views could be second priority.

This is solved in the OPAC \o/
Comment 8 Tomás Cohen Arazi 2020-05-15 22:52:14 UTC
Setting In discussion until some more feedback is provided. OPAC is done on separate bugs and is already fixed in master.
And svc/records/preview I think it shouldn't be filtered, as batch modifications should display all subfields to avoid unknowingly removing/changing unwanted fields/subfields.
Comment 9 Katrin Fischer 2020-05-23 22:19:57 UTC
I've tested this again with 245$b, hidden in OPAC and staff interface:

OPAC
- Normal view: OK
- MARC view: OK
- MARC view (Plain): OK!
- IBSD view: OK

Staff interface
- Normal: VISIBLE
- MARC tab (labelled): OK
- ISBD: OK
- Plain MARC view (link on Normal): VISIBLE

> And svc/records/preview I think it shouldn't be filtered, as batch
> modifications should display all subfields to avoid unknowingly
> removing/changing unwanted fields/subfields.

If this is used for creating the plain MARC view in staff, I think we should filter it here and discuss batch modifications separately. I think as 'batch' inquires editing, we could use the editor flag there instead.

I am changing the bug description to reflect the current status. Also decreasing  importance to normal.
Comment 10 Laura Escamilla 2023-05-31 18:04:55 UTC
Commenting to put this back on everyone's radar. We are still running into this issue.