Forum OpenACS Development: Re: listbuilder: permissions on columns

Collapse
Posted by Dave Bauer on
Filter by form already exists in listbuilder. This is basically what I'll be extending. I added a new parameter to template::list::create and it builds a form based on all the filter definitions.

We can add a "displayed_columns" and "hidden_columns" built in filters to go along with the other built in filters.

To make it simple I am going to just present all filter options for my application. In your case you need to have two pages. One for admins to build a view from all options, then a user visible page that does not have the filters in ad_page_contract, and only allows selecting a pre-defined view from the list they are allowed to see (of if there's only one, just show that automatically.)

The thing I need to add is a saved_list_view object. Right now you can't save the filters from a form. This is going to be very simple. Right now it just stores all the filter criteria in a list in a session property. All we need to do to save it is create an object and store the list in the database.

Collapse
Posted by Tom Jackson on
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.