Forum OpenACS Development: Should only site-wide-admins be able to add users to the system?

So the application group of the main site holds all registered users of the system. Currently only site-wide-admins have admin privilege on this group which means someone with admin privilege only on the main site acs-subsite package cannot invite members to the main site. I assume that this is an oversight in acs-install.sql file and I've changed it on the 5.1 branch so that the registered users group has a context_id to be the package_id of the main site package instead of null.

I just wanted to double check that the null context_id wasn't intentional, maybe to assure that only site-wide-admins can add users. If we indeed want the site-wide-admin restriction then we need to roll back my change, and also change the acs-subsite package to consistently enforce that, something it currently only does for the main site.

This is not a bug fix, IMO, certainly not a "beta blocker".

Isn't 5.1 frozen?  Aren't we supposed to only be fixing "beta blocker" bugs here?

I don't have a problem with the change but think it should go in HEAD not 5.1 ... just in case there IS a problem we're not thinking of.  It's more likely to come out in the lengthy process leading to a 5.2 release than our rapid push towards beta with 5.1...

I've found a similar problem that prevents a subsite admin from adding users to groups. The problem is that the /admin/relations/add uses a monster query that will only allow you to add users to the group on which you have read permission. Now it just so happens that all our users have a null context_id so that in practice, and once again, only the site-wide-admin can actually admin users and groups.

It seems to me that the best fix here is to remove the read permission check and simply allow the admin to add any user in the system to a group that he admins. Does that make sense?

Peter,

Wouldn't it be more correct to set the context_ids of the groups and grant the proper permissions?

I agree with Dave and, again, think it ought to be fixed for 5.2, not 5.1.

But I'm curious about this:

"It seems to me that the best fix here is to remove the read permission check and simply allow the admin to add any user in the system to a group that he admins"

How can you not have the read priv on a group you have admin on since read is a child of admin?

Dave and Don,
it's not about the read privilege on the groups but on the *users* that the admin wants to add to a group...
Oh, I see ... yes, those semantics seem odd to say the least.
Ok, I've removed the read check on users. Where should I commit this? Leiden is on 5.1 and needs this fix. I don't consider this change high risk as it's a change only on one page, not in the core datamodel or API.
Just removing the read check seems OK to me ...