WIP: User Group creation / removal and Group->Group membership creation about issues

[barnson]

1. Prefer a new Wix6Group table name.
2. Prefer Wix6GroupGroup table name.
3. Prefer ParentGroup and ChildGroup column names and ParentGroup should come first (a la FeatureComponent table, not the Wix4UserGroup table).
4. Need a bit on rollback---because groups have SIDs, they can't just be re-created on rollback. Users have the same problem: They're handled in a commit custom action. Membership could be rolled back, however.

Overall looks good! Please think about sending in multiple draft pull requests so we can review and provide feedback in manageable chunks.

[bevanweiss]

1. Prefer a new Wix6Group table name.

To replace the entire WixGroup current table name, or as an additional table, with a reference back to the original?
So the CA view would be:

vcsGroupQuery = L"SELECT `Group`, `Component_`, `Name`, `Domain` FROM `Wix4Group` WHERE `Group`=?";
or
vcsGroupQuery = L"SELECT `Group`, `Component_`, `Name`, `Domain`, `Comment`, `Attributes` FROM `Wix4Group`,`Wix6Group` ON `Group` = `Group_` WHERE `Group`=?";

4. Need a bit on rollback---because groups have SIDs, they can't just be re-created on rollback. Users have the same problem: They're handled in a commit custom action. Membership could be rolled back, however.

I haven't tried it, but the GROUP_INFO_3 structure captures SID, so potentially it might be possible to 're-create' if the SID was stored away for rollback.
I suspect the Win32API ignores this SID on create though (even if it doesn't explicitly document that).. seems like a possible security vulnerability otherwise.

There's almost certainly going to be a merge conflict against any fix for #8576.
I've got something in my current code for that already, but will rebase around whatever is put in by Rob for that.
I'll tidy up what I've got (to align with updated table names), and will put in the first draft PR tonight (AEST).

[barnson]

1. All-new table is fine. We did that in WiX v5. WiX extensions are version-specific so the prefixes exist just to allow mixing of merge modules built with a different version of WiX.
2. Yeah, the doc in that space isn't great, but I don't know that I'd trust that it's supported if it's not explicitly documented.
3. Feel free to include it; Rob took the issue in part to look for other potential leaks in code that old---it's WiX v2-era old.

[bevanweiss]

1. Apologies, I must be slow on the pick-up today... So with an 'all-new table'.. is this saying that overall in the WiX table space there would be BOTH a Wix4Group AND a Wix6Group table (i.e. a whole new table for Wix6). Which is what I think might be the right way moving forward..

   I'd like to think that the existing Wix4Group references (both internal to WiX and 3rd party) could remain untouched, certainly the likes of the IIS and the COM extensions appear to reference Wix4Group already. My thoughts are 'Create / Modify Group' Functionality is a bit of a (Wix v6) extension to the current Wix v4 functionality. So existing extensions that only expect Wix4Group stuff should work without any needed knowledge (or changes) due to the extra Wix6 'group stuff'.

[barnson]

1. We want to avoid adding columns to the existing table. (It should be fine, but let's not tempt fate with WiX v4/v5.)
2. Replacing the old table with a new table combining the old table with the new columns makes a lot of sense...
3. ...but then you point out advantages of keeping the old table around. Makes sense to avoid unnecessary changes in other extensions.

So I've changed my mind and agree on two tables. @robmen, do you have any concerns?

[bevanweiss]

@barnson I've got the basic Group Addition / Removal working. However I'm struggling a little on the best way to do the Group Membership modifications.
Because Groups can be Parent / Child to other Groups, there needs to be a split between Creating / Removing Groups, and modifying Group Memberships (between groups)...

I've got a couple of challenges:

1. I'd like to decouple the Group-Group membership CA from the Create/Remove Group. But I'd want to reference the Group's Component state (Installed vs Action) to determine what action should occur for the Group-Group membership, if either component is being uninstalled then the relationship should be removed, else if either component is being installed, then the relationship should be added. The GroupGroup table definition is just [('Parent_'=>Group), ('Child_'=>Group)], ideally I'd like a query that returns Parent_, Parent_.Component_, Child_, Child_.Component_ so that I can easily get the states for each side of the relationship. But my Windows Installer SQL-foo is weak... and I only know the classic SQL table alias method to do a join to get these in, which installer says 'No' to. Any query magic? (or should I just do the individual parameterised query lookups to the Group table in code?)
2. Scheduling of the ConfigureGroups should be BEFORE InstallFiles (like ConfigureUsers), but if there are any Users to create, then ConfigureGroups should ALSO be BEFORE ConfigureUsers (so that the Groups exist by the time ConfigureUsers occurs). Any way to do this 'conditional' sequencing (i.e. BEFORE="InstallFiles" unless ConfigureUsers CA will be present, in which case it should be BEFORE="Wix4ConfigureUsers_??"
3. Ditto for ConfigureGroupGroupMemberships which should be AFTER="ConfigureGroups" (so that all the groups exist for the memberships). To nicely tidy things up, it's probably desirable to have a ConfigureRemoveGroupGroupMemberships which should be BEFORE="ConfigureGroups" to remove group memberships for groups that will be removed.