How to disable a group?

If you have a group, which has one or more applications, and because it wasn't a joinless, it has members....how do you 'switch it off'?  I want to block access to and visibility of it, and I want all the app in it to lock/freeze as they are.

I don't want anyone (inc. members) from being able to access it.  However, I don't want to delete the group as that's too permanent and removing the information contained in it.

Parents Reply Children
  • 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.

  • Would you prefer the password option vs. an explicit list of allowed users? Unless unregistered users need to access the group, an explicit access list would provide a more direct way to identify access under the scenarios you identified and would prevent leaking of a shared password.

  • Password seems simpler and preferable to me.  I can set a password and anonymous users could even get in if required - great way to get users to look at a restricted group before deciding they want to sign up.  With an allowed list it works OK for a handful of users, but with 10s, 100s, 1000s it get unmanageable.  The maintenance would be more of headache scrolling through for 'that user' and removing them or checking they are listed.  And the password is, as mentioned earlier, a familiar concept to all. Plus username don't really ID real people, the email address does and exposing that seems to tricky as privacy is affected.

    I dislike the idea of some asking me, say via email, to be let in, I ask for their username, they don't know, I ask if they are even registered, they say probably not, I say go register and then tell me your username, they go register and email me their username, i can't see it, they check and email me the correct one, i add them to the allow list, they decide it wasn't what they expected and don't join in...oh darn it, a whole ping pong match of emails to do nothing.  Just give them a password to get in and it's up to them to join if they like it. :o)

    Passwords can leak sure.  But you could officially call the whole thing a 'gate' to avoid any responsibility.  And if the password leaks just reset it and re-share to the desired of users.  A policy for the admin could be that the password should be changed every Wednesday at noon and added to a secure password manager system where access is control - there's another thing.  Because people already are using and sharing passwords for multiple systems in their organization, they'll have password management policies already in place.  This new password can align with that (be it a super secure encrypted solution with voice activated unlock, or they just write it in a light 4H pencil on the big post-it note stuck on the bottom of their monitor with all the other passwords).

  • The bug I logged will address the enablement option. Could you add the gate idea to the community ideation?

     

  • Done.  Currently says...

    Content Under Review

    This content is currently pending review by moderators and is not available. Please try again later.