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.
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.
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?
Scenario one: running a time limited two-round product beta
Scenario two: Change in support channel and process of a product
Scenario three: A group has been defaced
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?