Related user story
#38869
Task
Implement backend endpoint described in the parent story. Note that the actual profile itself is optional - if it is not provided, only the labels should be updated. If it is, the profile's contents and checksum should be updated.
The operation to do this should be atomic at the datastore level, similar to what happens with Gitops today.
The endpoint should apply the constraints described in the parent story, namely the uploaded profile must be the same type and have the same identifier as the existing profile. Stated differently: If you look at Gitops today, when you edit just the contents of a profile but its identifier and overall type stays the same, an UPDATE is done rather than a new profile row being created in the DB. This endpoint should only allow that type of update. It should not be possible for instance to upload a profile with a completely different identifier or platform
Activities should be generated appropriately for the type of profile edited upon edit
Condition of satisfaction
Profile contents, or labels, or both, can be updated for:
- Android
- Windows
- macOS .mobileconfig Profile and DDM JSON
Profile checksums properly update if contents change and don't update if contents stay the same
Variable-tracking logic functions for all profile types as today when new endpoint is used
Profile is properly delivered to hosts when its applicability changes, or alternatively removed from hosts
No changes are made to the actual profile applicability logic
Endpoint gates profile uploads so that profiles with a different identifier or platform cannot be updated over top of an existing one
Endpoint properly gates label updates similar to net-new profile upload
Endpoint properly creates activities on edit
Related user story
#38869
Task
Implement backend endpoint described in the parent story. Note that the actual profile itself is optional - if it is not provided, only the labels should be updated. If it is, the profile's contents and checksum should be updated.
The operation to do this should be atomic at the datastore level, similar to what happens with Gitops today.
The endpoint should apply the constraints described in the parent story, namely the uploaded profile must be the same type and have the same identifier as the existing profile. Stated differently: If you look at Gitops today, when you edit just the contents of a profile but its identifier and overall type stays the same, an UPDATE is done rather than a new profile row being created in the DB. This endpoint should only allow that type of update. It should not be possible for instance to upload a profile with a completely different identifier or platform
Activities should be generated appropriately for the type of profile edited upon edit
Condition of satisfaction
Profile contents, or labels, or both, can be updated for:
Profile checksums properly update if contents change and don't update if contents stay the same
Variable-tracking logic functions for all profile types as today when new endpoint is used
Profile is properly delivered to hosts when its applicability changes, or alternatively removed from hosts
No changes are made to the actual profile applicability logic
Endpoint gates profile uploads so that profiles with a different identifier or platform cannot be updated over top of an existing one
Endpoint properly gates label updates similar to net-new profile upload
Endpoint properly creates activities on edit