Allow limiting of content types available for filter

This patch adds a settings page, and a new permission to control access to that page. A user with access to the settings page can limit which content types are available for use as a filter. Only the content types allowed by this setting will show up in the Display field when a simple view is created or edited.

The default is to allow all content types so this patch does not change simple views' out-of-the-box behavior.

If the setting is set to something other than all, and a simple view is created with Display set to all, the resulting view will only filter by the allowed types, not by all types. So, for example, if our system has content types A, B, and C, and the setting is set to only allow A and C, then a simple view with Display set to all will actually filter by A and C. Also, as indicated above, given that setting, the only choices available when creating or editing a simple view would be All, A, and C.

In line with the general architecture of the module, I have created a new inc file for the settings page. Currently, it only includes the one setting, but it could obviously grow.

My reason for requesting this feature is that I would like to be able to give my clients simple views as a cool tool they can use to work with their content. However, I often have content types which I would not want the client including in a view. Excluding those content types from the Display select list has three positive effects. It ensures that a client will not accidentally include such a content type in a view they create using simple views. It means that clients do not have to worry about making such a mistake. And finally, it simplifies the interface for clients by hiding options they should never choose.

Here are three cases where this feature would be useful:

1) The flexifield module (http://drupal.org/project/flexifield) lets administrators create content types which in turn can be used as fields in other content types. This lets an administrator create a flexifield which is actually a set of fields: e.g. an image and text flexifield which contains an image field and a text area. The administrator can then use that flexifield in other content types to help structure the client's and end user's input. Since the flexifield content type is really just a field, not a piece of content, it would not make any sense for a client to include it in a view. Since sites can have a lot of flexifields, removing them from simple views' Display field will significantly simplify its interface.

2) The promos module (http://drupal.org/project/promos) lets clients create nodes which can then be displayed as part of a block. This is a way of giving clients access to block-like content without having to give them access to administer blocks. A site often has a variety of promo content types for different kinds of promo content. It would not normally make sense for a client to include promo content in a view, and thus it would not make sense to include the promo content types in the Display field.

3) The attached node module (http://drupal.org/project/attached_node) lets nodes include other nodes as part of their content. One way in which this is very useful is with the webforms module. An administrator can keep clients from directly editing webforms while also letting them edit text above or below an actual form. The administrator does this by creating a node for each piece of text they want to make accessible to the client, and attaching those nodes to the webform. The client can then edit those nodes to change what appears above or below the form. As with flexifields and promos, it would not make sense for the client to include the attached nodes in a view, and thus does not make sense to expose the content types used for that purpose in the Display field.

Of course, when exceptions arise, they can easily be handled by adjusting the setting added by this patch. Thus, for example, if a client did have a reason to include flexifields, promos, or attached nodes in a view, it would be very easy for and administrator to make those content types part of the allowed set used by simple views.