Bug 10195

Summary: Records hidden with OpacSuppression can still be accessed
Product: Koha Reporter: Katrin Fischer <katrin.fischer>
Component: OPACAssignee: Mirko Tietgen <mirko>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P5 - low CC: dcook, gmcharlt, mirko, mtj, sophie.meynieux
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on:    
Bug Blocks: 28478, 27685    
Attachments: Bug 10195 Records hidden with OpacSuppression can still be accessed
Bug 10195 Records hidden with OpacSuppression can still be accessed
Bug 10195 Records hidden with OpacSuppression can still be accessed
[SIGNED-OFF] Bug 10195 Records hidden with OpacSuppression can still be accessed
Bug 10195 Records hidden with OpacSuppression can still be accessed

Description Katrin Fischer 2013-05-05 13:37:02 UTC
It's possible to access an OpacSuppression hidden record in the OPAC with a direct link to the record:

Example:
localhost/cgi-bin/koha/opac-detail.pl?biblionumber=299
Comment 1 Mirko Tietgen 2013-07-16 12:09:48 UTC Comment hidden (obsolete)
Comment 2 Mirko Tietgen 2013-07-16 15:01:02 UTC Comment hidden (obsolete)
Comment 3 Mirko Tietgen 2013-07-16 18:35:51 UTC Comment hidden (obsolete)
Comment 4 Owen Leonard 2013-07-23 14:44:44 UTC Comment hidden (obsolete)
Comment 5 Kyle M Hall 2013-08-16 16:26:02 UTC
Created attachment 20428 [details] [review]
Bug 10195 Records hidden with OpacSuppression can still be accessed

Records hidden with OpacSuppression are filtered from the search
results, but the opac-detail page is still visible if you know the
biblio number. This patch hides the detail page for suppressed biblios
by redirecting (controlled by the syspref OpacSuppressionRedirect)
either to opac-blocked (default), explaining that the record is blocked
(including optional explanatory text from the syspref
OpacSuppressionMessage) or to Koha's 404 page, giving no hint that a
biblio with that number exists in the system.

Test plan:

Make sure you have at least one record with 942$n == 1.
Set OpacSuppression to "Don't hide".

Do an OPAC search that should bring up your hidden record and other
records.
  Observe that your record is found.
Open the detail page for the record.
  Observe that it is accessible. Copy the URL for later(!).

Set OpacSuppression to "Hide".
Leave OpacSuppressionByIPRange blank.
Set OpacSuppressionRedirect to "an explanatory page ('This record is
blocked')."
Leave OpacSuppressionMessage blank for now.
Disable queryparser(!) (because of bug 10542).

Do a full zebra reindex.

Do an OPAC search that should bring up your hidden record and other
records.
  Observe that your record is not found.
Open the opac-detail URL of the record (the one you copied before).
  Observe that you are redirected to opac-blocked and it displays a
short standard message.

Edit OpacSuppressionMessage and input some text.
Open the opac-detail URL of the record again (the one you copied
before).
  Observe that the text you entered in OpacSuppressionMessage is
displayed under the standard text you have seen before.

Set OpacSuppressionRedirect to "the 404 error page ('Not found')."
Open the opac-detail URL of the record again (the one you copied before).
  Observe that you are redirected to Koha's 404 error page.

Sign off the patch. :)

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, works as advertised.
Comment 6 Galen Charlton 2014-05-05 15:51:37 UTC
Pushed to master.  Thanks, Mirko!
Comment 7 Frédéric Demians 2014-08-29 09:39:42 UTC
This patch could be seen as a regression for some libraries. I know one of them which doesn't want to show 'hidden' biblio records on result page, but want to propose to users direct links to some of those records from their intranet web site: something like a 'confidential' bibliography.
Comment 8 Katrin Fischer 2014-08-29 09:41:51 UTC
I think the best solution would be to add a third option then?
Comment 9 Sophie MEYNIEUX 2017-02-21 13:17:00 UTC
The field used for OpacSuppression should be set in a syspref : 942$n is used in marc21 but not in Unimarc
Comment 10 Katrin Fischer 2017-02-21 19:39:20 UTC
(In reply to Sophie MEYNIEUX from comment #9)
> The field used for OpacSuppression should be set in a syspref : 942$n is
> used in marc21 but not in Unimarc

Could we hardcode a field for UNIMARC? You also need an index with a specific name for it to work - would be good to have a default. Or have harcoded values and a pref if they don't apply, with a warning that you have to take care of indexing?

Anyway, we will need a new bug! :)
Comment 11 David Cook 2018-04-26 03:02:15 UTC
(In reply to Katrin Fischer from comment #10)
> (In reply to Sophie MEYNIEUX from comment #9)
> > The field used for OpacSuppression should be set in a syspref : 942$n is
> > used in marc21 but not in Unimarc
> 
> Could we hardcode a field for UNIMARC? You also need an index with a
> specific name for it to work - would be good to have a default. Or have
> harcoded values and a pref if they don't apply, with a warning that you have
> to take care of indexing?
> 
> Anyway, we will need a new bug! :)

I'm thinking it's worthwhile having a database field for OpacSuppression, and then people can map the relevant MARC field using /cgi-bin/koha/admin/koha2marclinks.pl
Comment 12 Katrin Fischer 2018-04-26 04:53:32 UTC
(In reply to David Cook from comment #11)
> (In reply to Katrin Fischer from comment #10)
> > (In reply to Sophie MEYNIEUX from comment #9)
> > > The field used for OpacSuppression should be set in a syspref : 942$n is
> > > used in marc21 but not in Unimarc
> > 
> > Could we hardcode a field for UNIMARC? You also need an index with a
> > specific name for it to work - would be good to have a default. Or have
> > harcoded values and a pref if they don't apply, with a warning that you have
> > to take care of indexing?
> > 
> > Anyway, we will need a new bug! :)
> 
> I'm thinking it's worthwhile having a database field for OpacSuppression,
> and then people can map the relevant MARC field using
> /cgi-bin/koha/admin/koha2marclinks.pl

It would be cleaner by fitting in better with existing patterns, but it wouldn't solve the problem that you'd need an index defined. Having a pre-defined index for UNIMARC could help people being able the feature in Koha out of the box.

Btw. this bug has been fixed ages ago.