Closed mitchelbaker-cisa closed 2 months ago
@mitchelbaker-cisa I disagree with this as the implementation steps are in completely different areas.
Combining these policies could create unnecessary confusion.
@mitchelbaker-cisa I disagree with this as the implementation steps are in completely different areas.
* Policy 6.1 refers to the setting where admins can choose whether to allow group owners to hide the group * Policy 7.1 states that new groups have to be created with certain access settings.
Combining these policies could create unnecessary confusion.
Good point. In that case we can close this issue. I'll create a separate issue to handle the step 5 case, which is to handle the "GroupsSharingSettingsProto new_groups_are_unlisted" setting for Groups 6.1.
💡 Summary
Groups 6.1 and 7.1 can be combined into one policy. 6.1 covers the ability to hide groups (presumably existing) from the directory, whereas 7.1 only covers new groups and the type of access type settings that are required.
Proposed revision would be a policy that covers if group owners have the ability to hide new and existing groups from the directory. New Groups should be created with an Access type of Restricted
This issue would require baseline and code changes.
Motivation and context
This would be useful because #245 is open which resolves a dependency issue between Groups 6.1 and 7.1.
Additionally, for Groups 6.1 we determine a pass/fail result based on the log event for step 4, which is "GroupsSharingSettingsProto allow_unlisted_groups". However, we do not account for step 5 at all, which is "GroupsSharingSettingsProto new_groups_are_unlisted".
Below are the implementation steps for GWS.GROUPS.6.1v0.1:
Implementation notes
Please provide details for implementation, such as:
Acceptance criteria
How do we know when this work is done?