limit user deployments by device collection
It would be nice to have content/policy deployed to a user collection to be able to consider membership of a device collection...resulting in a test on if the device to which the user policy is executing is a member of the associated device collection before execution.
The possible device collections should be enumerated considering what is visible by the individual creating the deployment (if so desired to be changed). While it is possible that an administrative user is delegated the ability to deploy policy to users and not devices (thus cannot see any device collections), in this scenario perhaps the administrative user can have a default device collection assigned to it by infrastructure admin or SMS00001 so that it is transparent if they wish not to or cannot change it.
I've considered scenarios where this could be applied retroactively during a feature upgrade and it should be possible to enumerate device collections scoped to the administrative user and choose the one closest to SMS00001 (or default to it). This should be fine since the current behavior would be equivalent to it being SMS00001 to replicate current behavior as a starting point. Normally RBAC would check collection membership and not allow policy (such as the proposed deployment policy) to be modified if it includes bits the person cannot see, but if the value is statically set by the infrastructure admin for the administrative user the check on the device collection would be ignored in that case to allow the modification to the policy to go through using the greyed out default value.
For my employer, this problem of limiting the reach of user policy is a challenge in Config Man currently, and will be a bigger issue for modern management in the future.
Use case is most notably being able to restrict the sphere of influence that user targeted policy has. As it stands now, if a user/group is targeted with a deployment, that policy will apply potentially anywhere that user or group members log in. It is an issue when membership of said group is unrestricted or there is no ownership of said user. There are mitigations that can be crafted using global conditions and requirements, but that means a great deal of trust has to be placed in the authoring of the GC or implementation of the requirement in the deployment type. It would be much preferred to impose controls from the top using our trusty RBAC toolset.
I imagine the UI change would be an additional drop-down in the deployment wizard that requires a device collection be defined for a deployment restriction (like I mentioned, a default could be static or deterministic per some logic).
Policy provider would just have to consider the additional piece of deployment metadata when processing the deployment policy, requiring not much if any modification on the client (perhaps something indicating that it has the policy but not acting due to device restrictions).