Forum OpenACS Q&A: Response to ecommerce administrator

Collapse
Posted by Walter Smith on
Cathy,
This is something I've been wrestling with, and I haven't found a straightforward way (i.e., without hacking code) to do it.

What I don't like about the News module permissions is that you have to be a site-wide admin to see the public items. The way the scope authorization works, it seems that you can't assign general administration of the module to a designated News administrator, it's basically all or nothing.

I'll tell you how I handle it, although if someone has a better way I hope they will come forward.

First, I set up filters for all of the */admin sections, to control who can view those pages. I add entries to the list of filters in the intranet-defs.tcl file, so the user has to be a member of one of the intranet groups (e.g., employees) to get to the */admin directories. This can give you a little more peace of mind when hacking permissions, because you know that you've at least excluded the public.

To create general administrators on a module level, I set up a separate "Administration" group for each module, in this case "News," and add the person(s) who will be responsible for it to that group.

The last step is slightly more complicated, but not too bad. I create some code based on the permission checking in the "Press" module for identifying the module administrator(s). This way I can enforce that additional level of granularity that's missing from the News permissions.

This is my code for checking for an administrator of a module called "Content," based on the original press_admin_p procedure:

if [ad_administrator_p $db $user_id] {
	# this is a site-wide admin, return true always
	return 1
} elseif {$user_id != 0} {
	if ![empty_string_p $group_id] {
	    # the person isn't a site-wide admin but maybe he can be authorized
	    # because he is a group admin (since this is for a group-specific item)
	    return [ad_user_group_authorized_admin $user_id $group_id $db]
	} elseif {0 < [database_to_tcl_string $db "
	    select count(*)
	    from    user_groups ug, user_group_map gm
	    where   lower(group_name) = 'content'
	    and     lower(group_type) = 'administration'
	    and     gm.group_id = ug.group_id"]} {
		return 1
	}
}
# not authorized via one of the preceding mechanisms
return 0
The above procedure has the module name hard-coded, but it could easily be generalized to take a "module name" argument.

Of course I'd be happy to hear about alternatives or suggestions for improving this method for handling module admin permission.