Forum OpenACS Development: Re: listbuilder: permissions on columns

Posted by Andrew Piskorski on
I've never actually done it, but I've long had a use case for something like that too.

At work, we have various pages that implement "features". Some "features" might be read access to particular columns, but others are more arbitrary - a "feature" might be the ability to execute certain Tcl procs or whatever. Right now we control access to the various features in an ugly, quick and dirty style which makes it very hard to change or verify just who has permission to do what.

A much nicer system would be to, as Dave essentially described above, model each "feature" as an acs_object row, and then add/remove the usual read/write permissions to that object. I think the only other major design question is how to map the conceptual "features" to the acs_objects. Probably I would stick a Tcl call onto each page declaring that "this page provides feature X", but it would also be possible to track the page to feature mapping in the RDBMS.

I don't think this is quite the same as your column display permissioning case, Malte, but it seems close enough that I'm definitely curious about whatever solution you come up with.

Posted by Malte Sussdorff on
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.