Bug #4334

Searching for hidden element terms still returns results for unauthenticated users

Added by Dan Gillean almost 10 years ago. Updated over 7 years ago.

Status:VerifiedStart date:
Priority:MediumDue date:
Assignee:Austin Trask% Done:

100%

Category:Access Control
Target version:Release 2.1.0
Google Code Legacy ID:atom-2386 Tested version:
Sponsored:No Requires documentation:

Description

To reproduce this error:
1) Log in as admin, and create an information object named "Peanut" (RAD template) - and add a conservation note in the Notes Area that says "FOOBAR"
2) Under the admin menu, navigate to the Visible Elements screen and uncheck the "Conservation note(s)" box beneath the RAD template so it will not display to unauthenticated users.
3) Log out
4) Use the simple search bar to search for "FOOBAR"

Resulting error:
Information object "Peanut" is returned

Expected result:
Information object "Peanut" should not be returned to an unauthenticated user - they are searching for a term that is not visible to them, and the search results should reflect this.

To unauthenticated users this will appear to be a false positive in the search results.

[g] Legacy categories: Access control, Search / browse

visible-elements-alignment.png - checkboxes are no longer beside their labels in Visible elements (28.5 KB) Dan Gillean, 12/30/2013 09:42 AM

History

#1 Updated by Jesús García Crespo almost 10 years ago

  • Priority set to Low
  • Target version set to Release 1.3

[g] Labels added: Milestone-Release-1.3, Priority-Low, Component-AccessControl, Component-SearchBrowse
[g] New owner: Jesús García Crespo

#2 Updated by José Raddaoui Marín over 8 years ago

  • Status changed from New to QA/Review
  • Assignee changed from Jesús García Crespo to Dan Gillean
  • Priority changed from Low to Medium
  • Target version set to Release 2.0.2
  • % Done changed from 0 to 100
  • Sponsored set to No

I've created a fix for this problem in 2.x. It's in https://github.com/artefactual/atom/tree/dev/issue-4334.

This will need a different fix for 1.x.

Regards.

#3 Updated by Dan Gillean over 8 years ago

  • File visible-elements-alignment.png added
  • Description updated (diff)
  • Status changed from QA/Review to Feedback
  • Assignee changed from Dan Gillean to José Raddaoui Marín

I've tested this on the dev branch.

  • Create a new description. Add data to: Archival/Custodial history; Sources; Conservation note (RAD). Save. Publish description, save.
  • Navigate to visible elements and uncheck Archival history (ISAD), Custodial history (RAD), Conservation note (RAD), Sources (both)
  • Log out
  • Navigate to published description

Resulting error
The elements that are supposed to be hidden are still visible on the page. When I search for the terms, I can't find them (they do appear to be hidden in the search index). However, the visible elements is no longer working as expected.

Note as well, that some CSS elements are affected - for example, the alignment of the checkboxes in the Visible elements module is no longer correct. See attached screenshot. (I also noted that the 2.0.1 upgrade announcement banner is no longer orange and the text in it is no longer centered, so there may be other CSS classes affected).

As a side note, when I went to compare this with the visible elements module in 2.x, I got a 500 error when trying to reach the visible elements module. Let me know if I should file a different issue for this (I can get a stack trace too), or what - it works in 4334 (or at least, you can get to the visible elements page), so i'm not sure if this issue was merged, if it would resolve the regression in 2.x or not.

#4 Updated by José Raddaoui Marín over 8 years ago

Hi Dan,

I haven't been able to reproduce any of the problems you said. We can talk about it today in the chat.

Also, there are some hidden fields without an ES related field, this are the relations:

'isad_archival_history' => 'i18n.'.$culture.'.archivalHistory'
'isad_immediate_source' => 'i18n.'.$culture.'.acquisition'
'isad_appraisal_destruction' => 'i18n.'.$culture.'.appraisal'
'isad_notes' => 
'isad_physical_condition' => 'i18n.'.$culture.'.physicalCharacteristics'
'isad_control_description_identifier' => 
'isad_control_institution_identifier' => 'i18n.'.$culture.'.institutionResponsibleIdentifier'
'isad_control_rules_conventions' => 'i18n.'.$culture.'.rules'
'isad_control_status' => 
'isad_control_level_of_detail' => 
'isad_control_dates' => 'i18n.'.$culture.'.revisionHistory'
'isad_control_languages' => 
'isad_control_scripts' => 
'isad_control_sources' => 'i18n.'.$culture.'.sources'
'isad_control_archivists_notes' =>
'rad_archival_history' => 'i18n.'.$culture.'.archivalHistory'
'rad_physical_condition' => 'i18n.'.$culture.'.physicalCharacteristics'
'rad_immediate_source' => 'i18n.'.$culture.'.acquisition'
'rad_general_notes' => 
'rad_conservation_notes' => 
'rad_control_description_identifier' => 
'rad_control_institution_identifier' => 'i18n.'.$culture.'.institutionResponsibleIdentifier'
'rad_control_rules_conventions' => 'i18n.'.$culture.'.rules'
'rad_control_status' =>
'rad_control_level_of_detail' =>
'rad_control_dates' => 'i18n.'.$culture.'.revisionHistory'
'rad_control_language' => 
'rad_control_script' => 
'rad_control_sources' => 'i18n.'.$culture.'.sources'

Regards.

#5 Updated by Jessica Bushey over 8 years ago

I tried to test this in 2.X dev site and got a 500 Internal Server Error when I tried to click on the visible elements menu in the drop-down from admin menu. Until this error is resolved in the testing site, I can't test.

#6 Updated by Dan Gillean over 8 years ago

Ok, we need to resolve the problems in the demo site, and merge this into 2x once that has happened, so we can test this robustly with a lot of data. Radda thanks for your work on making this happen - I hope we can get this resolved soon, because it is holding up work on #5908.

Radda, we should also talk further about this - for the hidden fields without a matching ES field, does this mean that we are unable to hide them in search results, or does it mean that these fields are not indexed for searching at all? Please clarify for me what the issue is, and what input you need from me - thanks! :D

#7 Updated by Dan Gillean over 8 years ago

  • Status changed from Feedback to Verified

Ok, the 2x site has been fixed! Thanks Radda for the patch, and David for applying it. After having run into some similar discrepancies testing other issues via the Vagrant box in dev branches, I am beginning to suspect that the problems encountered in #4334#note-3 above may have been caused by some local issue.

Interestingly, I am no longer sure how I got the inital results in the issue description - because I think I now understand what you mean, Radda. I could not get a hit on data in the RAD Conservation notes whether it was hidden or not, and whether I was logged in or not - and I notice on your list that it has no corresponding ES field - am I correct in assuming that it is not indexed for searching at all then?

However, I repeated the same steps with data in the following fields for testing - archival history/custodial history; Dates of creation, revision and deletion; and Rules or conventions.

  • I was able to get hits on all these fields when logged in and searching.
  • I unchecked them in the Visible Elements module, and confirmed that i could still see them when logged in, and still get results on them. Check.
  • I logged out, navigated to the test description, and confirmed I could no longer see those fields. Check.
  • I searched in the general search box for the data values added to each field. As expected, got no results.
  • I searched again with the institutional delimiter set to the associated repository. No hits - check.
  • I also tried using the advanced search module, both generally, and when limited to both the correct repository AND top-level description. no hits - check.
  • I logged back in while on the advanced search results page - my result appeared.

This now seems to work to me. Marking verified.

#8 Updated by Dan Gillean over 8 years ago

  • Assignee changed from José Raddaoui Marín to Austin Trask

Hi Austin, we will need to ensure that this issue's fix is applied ASAP to the ANU testing site. When it has been applied there, please mark issue #5908 as QA review and assign to me - I want to do a few quick tests to ensure it works before reassigning for acceptance testing. Thanks!

#9 Updated by José Raddaoui Marín over 8 years ago

Sorry for the late response Dan. Yes, those fields are not indexed for searching yet.

#10 Updated by Dan Gillean almost 8 years ago

  • Target version changed from Release 2.0.2 to Release 2.1.0

#11 Updated by Dan Gillean over 7 years ago

  • Category set to Access Control

Also available in: Atom PDF