How to prevent group manager from deleting own group

I had a similar problem but after many hours of debugging I realised that the option "Administer group" in Organic groups global permissions will by pass the delete permission.

So, if you have enabled "Administer group" - try disabling it.

So it would seem that if I want to allow the group owner the ability to administer their own group I have no choice but to allow them the ability to delete the group.

In OG for Drupal 6 the delete permissions for group nodes were handled by core. What was the reason for the change in OG for Drupal 7?

I would like to allow the owner the ability to administer their own group but I don't want them to have the permissions to delete it. Is this possible?

In OG for Drupal 6 the delete permissions for group nodes were handled by core

Using drupal 6.21, i do not succeed to disable "delete own page content" (page which is in a group when the user is the group's administrator );
i verified that my John Doe's account has no other role.

... though i created a new role "super_administrator" for me and kept only "access to content" and "edit own page content" for "regular" administrators

You are correct. The permission to delete the content in the group does seem to override core permissions in drupal 6. But the ability to delete the group node itself is handled by core permissions.

I guess it does make sense that the group owner should have the ability to delete offensive posts in the group. But if I had a case where I wanted to prevent the group owner from deleting the group or content in the group it would be nice to have the option. It would just make Organic Groups more versatile.

Kicking this up because it seems like a big problem that the group itself can be deleted by the group owner. Especially considering OG doesn't go a particularly good job of cleaning up after itself when a group is deleted.

Did you remove the "administer group" from those users?

The point is that "Administer Groups" shouldn't override the core permission to delete content. It is very reasonable to want a user to administer a group but not delete it.

> The point is that "Administer Groups" shouldn't override the core permission to delete content.

You should check the "Strict node access permissions" setting in admin/config/group/settings.

The "Strict node access permissions" setting does not seem to have any affect on whether or not a group owner can delete the group.

You can remove the "Group manager full permissions".

Yes. That setting works but that's not a solution. Group managers should have full permissions over the group but they shouldn't be able to strand everyone by deleting the group unless they are specifically given permission to do so.

It is a solution. If you don't want the manager to have full permissions, you need to assign them a role with the right permissions, upon subscription -- you need to do it in your custom module.

The thing is that one might think manager should not have even edit permissions, that is why it's all or nothing.

@lliss, can you work with that?

The all or nothing philosophy doesn't make any sense to me.

In my case I do want the group owners to have the ability to change the subscription type on the group. But in order to do that I have to give them administer group permissions which would not be a problem except that means the group owner can also delete the group. Not good.

The ability to assign them to a role during the creation of the group like we could in Drupal 6 will not solve the problem. The only permission that allows for the configuring of the group subscription is “administer groups” which allows for the deleting of the group.

The ability to delete or edit the group should be handled by core. This allows the site administrator the ability to decide which groups can be deleted by the owner on a content type basis.

As lliss said I also do not want my group owners deleting the group node because they had a bad hair day and leaving the rest of the group audience stranded.

> The only permission that allows for the configuring of the group subscription is “administer groups” which allows for the deleting of the group.

So maybe the problem is that it needs a different permission?

A different permission wouldn't cure the problem.

The way Organic Groups for Drupal 7 is designed you have to give the “administer group” permission to the group owner in order for groups to be useful. Without it the group owner can't even approve membership for other users.

> The way Organic Groups for Drupal 7 is designed
> Without it the group owner can't even approve membership for other users.

Indeed, but we can change stuff :)

Agreed. I think another permission would be a good thing to have here.

The best change would be to prevent the “administer groups” permission from overriding core permissions when it comes to editing or deleting the group node.

In order to do anything with the group right now you have to have “administer groups” permission. That isn't really a major problem except if you don't want the group owners to have the ability to delete the group node.

Unfortunately adding a permission to prevent the group from being deleted wouldn't help in my case since I do want the group owners to have the ability to change the subscription type within permissions. I can easily do this by overriding permissions but then the group owner would have the ability to change the permission to delete the group also.

I did some experiments with adding a new permission. I think I can get a patch up shortly. Basically we'll just do a form alter to remove the delete button and override the menu callback on node/*/delete

We'll check to see if the node object has a group type setting that is set to true and if so we'll check to see if the user has our new permission. If not we'll return access denied. If the node isn't a group we'll just pass to node access as per usual.

Seem legit?

> Basically we'll just do a form alter to remove the delete button and override the menu callback on node/*/delete

I don't think you need to do that, og_node_access() should take care of this for you.

If your going to take the form alter route, it might be better to provide a check box on the content type edit form allowing the delete button to be removed from the node edit form of that content type.

This provides the site administrator the ability to allow groups of one type to be deleted by the group owner and groups of another type not deletable.

By providing a permission your heading down the all or nothing path. If user has permission then user can delete any group other wise user can not delete any group.

I guess the permission would get the job done but it would be more versatile to check against the content type.

I think the og_node_access route described in comment 23 is a good solution. I hadn't thought of the case of letting group admins delete their own groups on a per node basis. This seems an unwieldy solution to me. I was assuming a global user permission of "delete own group node" which would allow a user with that permission to delete the node.

This patch adds a new permission and does not let a user delete a top level group that they do not own unless they have said permission. Groups that are sub-groups of a group that is owned and administered by a user are still able to be deleted.

I was able to apply the patch manually and it does appear to work just fine.

Thank you very much for your help.

Not sure why this patch didn't work the first time. Posting again with version changed to 7.x-1.x-dev

@Amitaibu This this can get rolled in or does it need some more work?

@lliss,
We can have this permission declared in hook_og_permissions() -- so it can be controlled per group. Will that work for your use case?

Yes, that seems reasonable. The important thing as far as I am concerned is that a site admin does not unknowingly allow node deletion when the permissions say that it is not allowed. New patch attached.

@Amitaibu is this something we can move into the 7.x-2.x branch as well?

Here's the patch for 2.x version.

Actually this doesn't really solve the problem at all because the goal is to have the group admin still have full group access and yet not be able to delete a top level group. The variable og_group_manager_full_access undercuts these efforts as it always gives the manager full permission. So I think we need another solution. The original patch from 30 still works. But the last two that attempt to use permissions defined by hook_og_permission fail for this purpose.

Any other suggestions.

> The variable og_group_manager_full_access undercuts these efforts as it always gives the manager full permission

Indeed, but why not turn it off? (I usually do it on my projects).

Isn't it on by default though?

> Isn't it on by default though?

It's a setting, enabled by default for the sake of novice users. In 7.x-2.x I'm going to add an option to auto assign manager with a role.

My concern is that since it's on by default, and since we generally expect the permissions on the permissions page to tell us the truth about how our users can interact with the site, that not having this off be default is a security hole. It's a user expectation and a user interface based security hole but its a security hole nonetheless. It's wrong to assume that people should know that turning on og and letting a user create a group automatically means they should be able to delete that group. It should default to not allowing this behavior and they should be able to configure otherwise if they want. Even more considering we have a delete own node permission that this is overriding. Also, we have a 1.x version that is supported and is being used out in the wild so let's fix for those users.

@lliss,
On a project I'm working on (using 2.x), and without any patch I'm able to give the manager full permissions, but without delete group.
If in 1.x you are not able to do the same (i.e. some permission ih hard-coded to "administer group"), we should fix that.

On 1.x branch by default after setting a content type as a group, the creator of that group can delete the group even if he/she does not have delete own content permission. Tested on 15 Feb with most recent dev version.

To test:
1. On a fresh install download and install OG.
2. Choose a content type (article for this test) and go to /admin/structure/types/manage/article/edit
3. Select group type radio button and save.
4. Alter permissions so that authenticated users can create this content type.
5. Create a new user and log in as that user.
6. Create a node of this type making sure to make it a group.
7. Visit the new node, click edit, scroll down, delete the node.

The exact functionality described in 44 is also true on 2.x dev version as of 15 Feb.

lliss, in #44 you didn't disable "Group manager full permissions", right?

Correct. I am describing the default scenario.

Ok, but if you want to prevent the user from being able to delete you can disable "Group manager full permissions", and that's it. The setting is there to be used if needed.

But that setting does much more than just prevent deletion does it not.

It just makes sure the group manager is treated like any other group member. think of it as group manager with the setting is like Drupal user ID 1, without it they are just a regular user.

Okay, I don't really have any issue with this. In fact I do think it should be the default for group creators but I think that external to that scenario a site admin should be able to choose whether or not the user can delete the top level groups he creates and I don't think those two should be inherently tied to one another. All it comes down to is whether you think out of the box config should allow content removal from a site. I think that is a bad assumption and that this default scenario results in confusion and the possibility that many people have unwittingly allowed top level groups to be deleted when they did not want to.

I think that in 7.x-2.x we can indeed make the group manager full access disabled by default, as we now have #1444516: Add setting to auto-assign role to group manager in.

Okay. If it's off by default in the 2.x branch then I'd be satisfied with adding a patch similar to the one in comment 36 which is now working, see attached. But since this isn't the case for the 1.x version how will we handle it there. Also, I think we should provide some better documentation explaining some of these things as there are so many settings, this is probably going to start confusing newer users.

But why do we need the patch -- why not follow #44 + #46?

When I tested this, unchecking the box for "Group manager full permissions", the user was still able to delete the group if they had the edit permission. Ideally I think the edit, group administration, and deletion should be different permissions. I may want to allow an admin to create, manage, and change a group, but not delete it. This patch allows that case.

@Amitaibu, we still need to patch this in the 1.x branch since we can't auto assign the group creator to be a group admin. The only good way to handle this is to give them full administration permission and if we do that we need to consider the case of not wanting to allow users to delete the top level group.

> we still need to patch this in the 1.x branch since we can't auto assign the group creator to be a group admin

There is no UI for this in 1.x, but you can do this programmatically. I don't think we should have a special permission in 1.x that won't exist in 2.x, just because we are missing the auto-role assign UI. Sorry for asking for the patches earlier, I admit it took me some time to fully understand the problem, however it appears to me it can work without the patch as-well.

How would this be done programmatically?

og_role_grant()

So it sounds like, instead of a permission, we need to backport the auto role assignment to the 1.x branch.

I stumbled upon this recently. And I support lliss's request to get a patch for this, as there is no other way except giving too much permissions to a group admin. Is there any progress on this topic? Can I help?

It's been over three years. The latest version seem to still have same issue. Why can't the patch be incorporated into the main line of code?

This can always be changed using hook_form_alter(), but I prefer using the patch in #53. It should be a part of the module. I will open feature request in https://github.com/Gizra/og/issues.

Github issue - https://github.com/Gizra/og/issues/16