How to disable a group?

You can change the group type to private unlisted to restrict any new access.

You should be able to delete all members in the group, or edit permissions for the group to remove Read Group from every role except Administrators.

Ok, I was hoping I missed the big button for 'disable group and/or hide'.  A feature request then.  For now I'm moving them to be sub-groups of the 'administrators' group.  That's working for the time being.  Thanks.

Groups do not inherit permissions, it does not change who has access if they have the url.  You actually would have to change them on the group itself.

All I can say is that it's working.  If I move the group beneath the administrators group, then no one but admins can get to it or forums/threads in the group.  I've impersonated current members of the group and tried to get to threads they started and they all 404.

So the group I moved to be under the administrators group, and that was nicely being blocked from being accessed, now suddenly is accessible.

According to Patrick this should never have worked but did and now is not doing so.  I'll could open a support ticket but with little hope as I assume it's not supported.

Steven, you suggested private unlisted but this isn't acceptable.  The content of the group is all over the internet and when a user clicks any one of thousands of third-party results they are prompted to login (Note: We use SAML to authenticate with a third-party system on our community.).  Imagine the user does try to log in, that they go to the trouble of logging in.  All of those people still cannot access it.  They just wasted their time and are just that bit more annoyed. 

The group needs to stop all 'knocking on the door'.  Now.  It needs to disappear.  I don't think this has been thought through and is lacking a vital feature.

Not being able to disable a group is inconsistent. I've logged this as:

Unfortunately, there isn't a work-around aside from perhaps a custom plugin (an IHttpRequestFilter: https://community.telligent.com/community/9/w/api-documentation/51073/ihttprequestfilter-plugin-type ) that forces a 404 response for the path where the group exists.

For me, ideally, I would want both the option to disable the group AND, this is ideally, the option to gate the group.  I'm thinking these options on the the Group Options dialog...

Could you elaborate on the use case for gating the group?

I should say, to be clear: the gating shouldn't be part of the disable option. I don't want the mock up to confuse by the option to gate being immediately beneath the disable option. It's far more useful to allow active groups to be gated.

What would password protecting a particular group give you?

• Any group privacy option can be selected but access is still allowed/blocked/controlled purely on a password.
• The password can be changed at any time to stop everyone, even existing members from getting access. Hence to can have a rolling access list by creating a group, sharing the link and password, waiting a week or two, reset the password, reshare to another set of users
• You can block any role (except admins) from getting in. So if you have created some very powerful roles you can still be sure of controlling a group with setting a quick password
• Everyone understands password protection. Protect something with a password or telling someone they need a password is universally understood. Much easier concept than me explained to every manager 'I've made the group private unlisted, so what this means is...' and then two paragraphs of text in an email or a blank look on their face after I've explained it's protected but only by a method they don't deal with day to day.
• If something happens to the group and you need to leave all of the users and settings alone, adding a password easily can help massively.

Scenario one: running a time limited two-round product beta

• A product manager wants a dedicated group with two forums ('bugs'and 'feature requests')
• The beta is running for a two month period
• Round one is running May 1st to May 31st and round two June 1st to June 30th.
• Users taking part in round one is tighter and will consist of 100 premium partners selected and emailed by product management
• Users in round two is wider and consists of 1000 premium customers
• Removal of access of some of the initial 100 premium partners may be required
• Content generated in round one must be available to round two participates
• Users must register with the site but otherwise barrier to participation should be extremely low to aid adoption
• After June 30th the group must close with no further content creation allowed and access to read existing content blocked
• After June 30th existing content must only be accessible to a limited number of internal staff
• Post beta staff access should be allowed without authentication (staff should not have to sign up/login to allow access)

Scenario two: Change in support channel and process of a product

• A group called Group A exists for Product X that contains three forums, two wikis, and one media gallery.
• Support for Product X has been outsourced to a third-party
• Support via a community forum and online information must stop on December 1st
• Access for any external customer to Group A must be disabled (not the group, but access to any and all content in it)
• Access for any internal staff to Group A (which include existing moderators and members of Group A) must be blocked
• Current membership lists and roles of users joined to Group A must be preserved
• Access to the historical content of Group A is required for a new set of people: the new external servicedesk team at the third-party support provider
• The external servicedesk team are unable to authenticate with the community to control access
• A link to the group and password must be shared with the new servicedesk team which will be documented in their internal support KB database

Scenario three: A group has been defaced

• A group's structure and/or content has been defaced
• This could be maliciously or accidentally
• A security team member has requested the group be removed from external access immediately
• A set of internal users from across the company, who are as yet unidentified and will not have registered with the community, still required access to investigate
• Access to perform remediation is required

For the last one, imagine you woke up to your site looking like the below.  I think a group kill switch with access for a small set would be a blessing.  If your site security has been compromised, then a bit of old fashioned password protection goes a long way to limited the reputational damage.

Do those scenarios help explain the idea?

Additional thought: If there was a password protection option I'd probably use it during the creation of the group, while I was setting it up.

I'd create the barebones group and set a password.  I could walk away right now and the group is locked down.  However I could add some content on day two. Add a role to the members on day three. Add applications and play with permissions.  Make more and more changes. I could fiddled with the group for the next two months. All the time knowing that when I add or remove some permission or change the privacy, there is zero danger of giving access as the password is set.