Forum OpenACS Q&A: ecommerce administrator

Collapse
Posted by Jason Tauber on
Is it possible to have an ecommerce administrator who only has
permission to work in that part of the site?  We need an admin that
can see who has ordered what to send out thank you cards, but we
definitely do not want this employee to have access to site wide
administration.  Does anybody know how I can go about doing this?

I'm using openacs 3.2.

Any help would be greatly appreciated.  Thanks.

-Jason Tauber

Collapse
Posted by Cathy Sarisky on
I have a similar question, with 3.2.5.  How does one allow a user to approve news items, again without making them the site-wide admin.  I suspect I could do something ugly to hack the tcl involved, but I don't understand ad-scope well enough not to screw it up in the process.  Is there a straight-forward way to do this?

(I want this user to be able to approve all public news, not just group news.)

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.

Collapse
Posted by Walter Smith on
Jason,
To get back to your original question, the situation with ecommerce is a little different. One convention that wasn't followed too consistently in the original ACS was how the admin functions were broken down. At some point they started differentiating between higher level admin functions (e.g., creating bboards) and lower level admin functions (administering/moderating an individual bboard).

The higher level admin functions were located in the top-level /admin directory (and required site-wide administrative privileges), while the lower level functions, for those modules that followed the convention, were located in the /*module name*/admin directory (and varied somewhat in how they enforced permissions).

Although I haven't used ecommerce, myself, I can see that it centralizes all admin functions under the site-wide administrative area. So what I would do is to break out the lower level functions that you want to delegate and put them in an /ecommerce/admin directory, or just copy the whole directory if you're not concerned about separating the functions.

Again, I haven't used ecommerce, so I don't know if you'll run into cases where you need to be a site-wide administrator to execute some of the ecommerce administrative functions.

Then if it makes sense to you, use the technique outlined in my last post for creating the administrative hierarchy to assign one or more "ecommerce administrators" who have authority over that part of the site but don't have access to site-wide administration.