There seems to be one effect this has on the application:

Users that receive the "assignable user" permission via membership in this group (either directly or via the group being attached to a role in the project config) That user will fail to be populated in the assignee user field autocomplete.

Hi, our customers are still impacted by this.

Why propose a disable group feature, if it has no effect ? Pick one road: remove the feature if you don't want to make it work, or enforce it in apps (useful in our customer's case !)

Another disappointing solution by Atlassian

Expected (and I would say absolutely obvious) behavior of deactivated group:

• mark deactivated group the same way as deactivated user (word Inactive in brackets behind the group name)
• turn of the "activity" of group in permission schemes, notifications, project roles etc. (user that are in deactivated group are ignored)
• don't suggest deactivated group in search filters

I other words - use the "Active" checkbox in Groups the same way as you use it for users, which is something everyone expects it will behave.

What we are trying to solve by this: if often happens some project ends or it's name is changed or many other situations when some groups become obsolete. You currently can't rename groups so your only option how to deal with them is deleting them permanently or leave them be (but this way they appear in searches etc.). Deactivating would be much more useful - you could reactivated the group when needed, it would be easier to communicated the group is no longer active (instead of errors appearing in confluence macros etc.) and you could also more easily see what groups were assigned where - it's very difficult to check all the places where the group is used with current tools. To have only option to completely delete group is quite strange and sometimes risky.

This has been closed due to a lack of interest and a lack of common understanding about what deactivating a group should mean. We will proceed to remove "Active" tickbox for deactivating groups in CWD-3636 to avoid further confusion.

To reiterate, if anyone would like Crowd to implement support for deactivating groups, please vote on this issue and comment with

1. The problem you're trying to solve by wanting to deactivate groups
2. What effect you think deactivating a group should have
3. How this will solve your problem (if it's not obvious from the previous 2 points)

Your comments are what will draw our attention to the issue; without them, we don't have a reason to do anything here

I've updated this issue to be more specific to groups, since users are tracked here: https://jira.atlassian.com/browse/CWD-995.

Crowd does not pick up inactive groups from LDAP.

If your use case is that you want to disallow access to all the members of a group to an application, then you can do this by removing the link between the group and application in Crowd.

If your use case is that you want to mark a number of users inactive, then please watch/vote on this issue https://jira.atlassian.com/browse/CWD-995.

If there is another use case that has not been accounted for, please let us know here so we can take it into account, otherwise I will be closing this issue as Won't Fix in a few weeks' time. Thanks, Helen

Hi stephan.kleine, thanks for your comment.
If what you want to do, is to disable a particular user or users in LDAP so that application access for that user is disabled, then as a work around I'd suggest that you remove the user from the group in Crowd that is associated to that application.
Hope that helps,
Helen

I'm sorry but I am honestly unable to understand how not being able to deactivate users (as in preventing them from login) can be considered a minor bug for over two years since people leaving $company and therefore must not be able to login anymore is not an uncommon event in my world? Even if it works in Crowd it does not work for any application that accesses LDAP directly. If we had known that in advance it certainly had saved us quite some licensing costs ...

So, what is the currently suggested workaround to disable people by storing that information in some LDAP attribute and making Crowd respect that flag?

Thanks a lot,
Stephan

Edited the subject and description to be more specific. This issue is about the "active" flag for users and groups. Active flag for directories is covered in CWD-1944

I'm an idiot who can't read. Sorry - Active flag for directories is sorted out, but not for users/groups yet.

Sorry to get your hopes up.

In Crowd 2.1, the "Active" flag for the directory is respected (see CWD-1944). Also in Crowd 2.1 is a fix for a problem where the SOAP service was not setting the "Active" flag for the group (see CWD-1980).