I talked this through a little bit more with guys at Quest and one way to handle this was to use arbitrary objects just as you suggest Andrew. This way you can have a call in your page or TCL proc which checks for permission on the function object , though we would have to make sure that the function objects have a unique label.
Driving this further for listbuilder I was then thinking that each list has a name, so we could provide the permission on an arbitrary object with the name "list.$list_name.$element_name" and provide a permission interface for an admin to create the object and to provide permissions to it.
This could actually be done fairly quickly both from a UI as well from a code point of view.
In listbuilder UI you would provide for Admins a link "provide permissions on columns", which would go to a page which takes as parameters the name of the list and the elements available in this list. On this page you have the ability (for each of the possible elements / columns) to create the object or give permissions on it. It would inherit the permissions from the package.
In the listbuilder code we could then have the elements that are to be displayed and we would run a check against this permission (does the user have functional permission on this column), if listbuilder is called with "has_column_permission_p"). If the object does not exist he has permission (unless you want to run a really restricted site), which is probably the case most of the time, so you would run a query which gives you the list of possible object names with ids and returns the ones which exist. You can probably cache that and flush the cache once you create a new object.
This being said I am curious how the view will work out and how the UI for that will look like, because I dont understand it fully yet.
We have something called "Saved searches" in contacts, which we will bring into AMS, allowing you to create a search with certain attributes to prefiled to limit the number of results returned and the ability to add columns to the table view, either by having a direct attribute of the attribute type, or by defining extended columns which you join in SQL (e.g. the turnover of a project, where the turnover is calculated in a subselect from the ecommerce tables). We have permissions on that so if this is what you envision Dave, then it would be good to talk this through with Matthew who is going to work on getting this out of contacts and into AMS, working directly off the acs-attributes table.
