Forum OpenACS Development: listbuilder: permissions on columns

I think it would make more sense to create a "view" object which was a list of columns to display, and grant permissions on that. The view could be either hard coded in the tcl file by the developer, or you could allow user creation of views if you wanted.

I am going to start work on a saved view feature for listbuilder soon and I think you could build on that. It will save all features of the current state of a list, ie: fitlers, sorting, grouping, and which columns are displayed.

I don't think it makes sense to try to grant permissions on the actual columns, but just create a view object that contains a list of 1) diplayed columns and 2) hidden columns that may be choosen to be displayed.

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.

Dave, I think we should figure a way to come up with a solution that suits both (contacts/AMS and yours). Because if it is keyed to a list in listbuilder or keyed to an object_type or multiple object types should not matter (that much) and be it for the simple reason that we could have a simple list which displays all objects of an object type. And thats basically what contacts does.

At the moment here is my idea (very theoretical): We have a package / place where we can say: This are the columns available and please create a view out of these columns. Basicly that is what we do in AMS (after all it is not necessarily keyed to the attributes, that is just and example how we use it).

What I want to have in addition for this view: Filter by element, meaning, you can create a view which might contain prefilled in filter values but also define one element as searchable by the user using the view. This way the admin, when creating the view, can preset certain filters. And additionally he can say "These are filters the user is allowed to use". Do we have textbox filters in listbuilder?

Do you have a timeline when you want to work on that?

Hmmm, interesting ideas. I hate to always look at problems via my query-writer package, so please try to ignore that, I'm not wishing anyone to pick it up and use it.

Actually, query-writer has never been used to build views, do selects, etc. as I have always thought it nearly impossible to pass through the expressiveness of a nice SQL query to Tcl or any other language. One thing query-writer starts with which is helpful is a list of columns available for certain operations on objects: new, set, del, rst (reset). A view operation/permission is easy to add. This simply provides a method of tagging which columns of a defined object are available to a certain qw group (tied to a relational segment). qw groups span objects, and in general there is an admin group, usually getting all columns, and a site member group, getting a developer defined subset.

The concept is that the developer can establish in one place what a particular group of users can do with a set of objects without the need to write new pages for each group.

Ditching query-writer, you can get the same effect with tying a list of object/columns to a rel segment, and add users to the rel segment, or just re-use an existing rel segment that is already related to the package making use of list builder. Query-writer reuses main site members and site wide admins for the default access controls.

So the only thing I'm really suggesting here is to use a proxy object, same as for the features object, but assign permissions based upon the type of membership in a rel segment.