OK, first, you do not explicitly create a "mixed" group of "compatible" group now. We used to in the past, but now, you just create a "group". Depending on the members in the group, we automatically change it to mixed or compatible group on the fly.

The "New" button in the UI is the same New button when looking at the compatible group list and mixed groiup list. The UI could be argued to be inferring you are created a compatible group if you are looking at the commpatible group list. But this actually isn't the case.

This BZ should be closed IMO, there is nothing to do here. We've had a history of this "feature" and much discussion over this periodically - some people wanted a 0 member group to be considered a mixed group, some people wanted a 0 member group to be considered a compatible group. The choice was fairly arbitrary and if we don't stop the cycle, we'll just keep waffling back and forth over time :)

A 0 member group is a mixed group. If you have a N-member compatible group and you remove all members, we automatically convert it to a mixed group.

Note that if you have a N-member mixed group, and you remove all members, it stays a mixed group.

IIRC there are other issues with 0-member groups that were considered (I think there are certain query assumptions that had to be made, I can't remember all the details).

Close this BZ and forget it every happened :)

I've looked into it and there is a flag on ResourceGroup called groupCategory, however, on many places the fact if the group is compatible or mixed is derived from the resource type.

On ResourceGroupManagerBean, there is method called setResourceType which is called from many other methods for manipulating the group as such, and basically it recalculates whether the group is compatible or mixed.

I've already made some changes to the ResourceGroupManagerBean, but there are so many edge cases in UI. So probably the safest change would be to leave it as it is and inform the user that the resulting group will be mixed when creating empty group and when clicking on "New" from Mixed/Compatible group view and creating the other type of a group, then just inform the user about it and open the appropriate view where the newly created group is present.

This is more a GUI issue than anything else.  We allow people to do a New from what looks like a compatible group view.  We should change that, perhaps.

A BZ search will reveal that we've been through this before.  The fact is that a compatible group is a group that contains all members of the same type.  An empty group has no members and therefore is semantically unclear.

We specifically decided that an empty group should be Mixed, and the code now supports that.

Put another way, group type can change given changes in membership, this is pretty much ingrained in our design.  To change this by forcing a group type be defined at group creation time, and forced to stay that way, means we would need to rework several things and figure out various other semantics, like autogroup recalculation and such.

So, in short, I disagree with Lukas on this one, and I think the semantics should stay as is. We should do better perhaps in the UI/docs.

So what about just letting the user know what is happening and navigate him/her to the view where the new group is present (to mixed or comp. list), because it is really confusing if nothing new appears in UI after successful creation.

I agree with Jirka here, that we should at least inform the user what is going to happen if they create a group with no members from the compatible group view. The fact that a mixed group is going to be created and that it won't appear on the list the user is currently at is I think at least worth of a message dialog warning the user about the fact.

I think the main problem is that the UI still tries to persuade the user that there are 2 distinct types of groups, where there really is just "groups" that happen to have different features available based on the type of members they contain (the fact that we internally still flag the groups as mixed or compatible explicitly should be irrelevant to the user, because the groups "flow freely" between the mixed and compatible).

So I'd add a bunch of message dialogs warning the user when the group is transitioning between the states. This should also include the "implicit" state of the new group which is determined by the page the user is creating the group from.

Alan s. recommends to ping someone on the UX team re the 0 member group?
There's clearly confusion for users, different opinions and the UX team isn't familiar with groups (so this will bring them up-to-speed)

jkremser and lkrejci point out that it would be nice if the UI redirected to the mixed group view if no resources were added to the group - that could be something they can discuss with UXD about

has been fixed in master by b54ce46 and it needs to be cherry-picked once the release branch is ready for accepting the 3.1.2 commits

> Alan s. recommends to ping someone on the UX team re the 0 member group?
> There's clearly confusion for users, different opinions and the UX team
> isn't familiar with groups (so this will bring them up-to-speed)
> 
Jirka, can you add a comment describing the conversation with UX and what the ultimate conclusion was.

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=9a1f79fe2

branch:  release/jon3.1.x
time:    Wed Sep 12 13:52:08 2012 +0200
commit:  9a1f79fe28c4da127b36864bbd7e3a1a9f38adde
author:  Jirka Kremser - jkremser
message: [BZ 708929 - Creating a compatible group with no members will create a mixed group] If the other type of a group is created the user is navigated to the right list and there is also notification if an empty compatible group (=mixed) is created. (cherry picked from commit b54ce46d2f1bcfbb8e7f5e996521592f008e3f24)

changing status to MODIFIED

Moving this to ON_QA as available for testing in https://brewweb.devel.redhat.com//buildinfo?buildID=243389.

Verified on 3.1.2.ER1