Download & Extend

Pls, make it possible to disallow *ALL* roles to search content per (!) content type

Project:Search Restrict
Version:6.x-1.3
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

Sometimes, it is neccessary that content of certain content types are not indexed at all.

Currently, it is impossible to disallow *ALL* roles to search content per (!) content type, as unselecting all roles allows ALL roles to search.
Quote of the help text in the web management UI: "If all checkboxes are unselected then everyone can search."

Comments

#1

Title:Pls, make it possible to disallow *ALL* roles to seach content per (!) content type» Pls, make it possible to disallow *ALL* roles to search content per (!) content type

Aforementioned is for both the 'search form' AND 'indexing'.

A module offering similar functionality: http://drupal.org/project/search_config

#2

As a workaround, create a new role that no one is assigned to. Then set that role to have search permissions for the content types you don't want people to see.

#3

I would also like to see functionality to exclude an entire content type from search all together.

A check box to the affect of "Exclude from search results for all roles" would probably suffice.

#4

+1 on that. I don't really want the admins to even think about adding users to that non-search role.

#5

Status:active» needs review

I've attached a patch that adds a checkbox to the search settings page and excludes access by default when the box is checked. There's also a D7 port in another thread that apparently adds similar functionality:

http://drupal.org/node/663916

AttachmentSize
default_no_access.patch 2.53 KB

#6

Great feature addition - thanks. Still needs work IMO.

Installed this on a site with 24 content types installed (hey, I just work here).

In order to restrict people from searching one content type, I'll need to save the unchecked box on the search config screen, then click to visit 23 pages, click to expand the search restrict box, check "anon" and "auth" to grant access to those people, and click save. 115 clicks later ... ugh.

The settings screen could be worded with more clarity, too:

Search Restrict
[ ] Default to No Access
If unchecked, any content type with no roles checked will give access to all users. If checked, any content types with no roles checked will give access to no one.

There's no indication of what's meant by "with no roles checked" (checked where?).

This patch should probably alter the wording of the content edit screen, to remove the text "By default all roles can search", perhaps only when that option is in effect.

I think a good addition would be a centralised form which shows roles vs content types on the search settings page.

But first, I'll test to see if this one works.

#7

xurizaemon, if you don't check the box, it doesn't change anything, so the 115 click scenario is what happens in the unpatched module, and exactly what the patch is supposed to avoid. If you check "Default to No Access," that should block access to all 24 of your content types. Then you'd just need to check those two boxes on the one content type you want to be searchable. So that's 3 checks total.

I agree the description is confusing, but I'm not sure how to make it clearer. Any suggestions?

#8

I'm favouring this approach of just moving the UI to the access permissions page:

http://drupal.org/node/600450

Default on creation of a new content type would be to allow search.

#9

@sreynen -

If you check "Default to No Access," that should block access to all 24 of your content types. Then you'd just need to check those two boxes on the one content type you want to be searchable. So that's 3 checks total.

Agreed, but you may have misread - we want to restrict people from searching for one specific content type - not restricted to one content type. I guess we could use the role workaround ScoutBaker suggests and only have admins (or nullroles) able to search for the restricted content type, but I'm with johnpitcairn there - it's a little too mystic for my liking.

Anyway, not a complaint against your patch - just raising an issue with the UI for our use case, which hopefully I'll get a chance to code up an improved UI for.

Q: Are there any advantages to having the search restriction in the content type pages at all? I would have thought this would be more usefully located on the search settings page on the first place.

EDIT: Oh look, Robert's comment points to #600450: Move admin to user permissions which I think is a better UI model (though I was imagining a separate table on the search settings form, and that issue would move the UI to the permissions page). I guess that answers my (unasked) question re whether the maintainer would consider a patch to that effect ;)

#10

I agree the description is confusing, but I'm not sure how to make it clearer. Any suggestions?

No, I don't have a better suggestion, but I did want to flag that it was confusing and hopefully draw some input on how it could be less so.

#11

I think it's pretty critical to able to actually remove content types from the index all together.

If only 2-3 out of 12 content types will be searched by end users, it's important not to waste the mySQL table space and look-up time on other content.

#12

An option to hide content types to all roles is very welcome. The creation of a dummy role is a temp workaround

Thanks, buckly

#13

This option would be more useful if it provided a way to exclude the types from the search index and not just hide it from results.
See how it's done here http://www.lullabot.com/articles/hiding-content-drupals-search-system

#14

This option would be more useful if it provided a way to exclude the types from the search index and not just hide it from results.

Did you actually look at the code? That's exactly what it does. search_restrict_db_rewrite_sql() does almost exactly what your_module_db_rewrite_sql() does in the Lullabot article.

#15

Status:needs review» fixed

Added checkbox to exclude all roles for a content type - note that user 1 always has full access to search all content.

#16

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

#17

Seems a detriment to not be able to actually exclude things from the index.

Imagine a scenario with status update type, aggregated news, or other run-away content that needs to be truly excluded to make search even usable.
(That was my original need.)