You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Preference Manifest is a old file format, originally used to describe actual Preferences (as stored in NSUsersDefault) for an app.
This description was then used in Workgroup Manager to generate a dynamic tableview based UI to help IT people to manage app preferences.
Managed preferences was able to be set using one of those 3 behaviors:
ONCE, the initial preference in NSUserDefaults, with capabilities for the user to change it
OFTEN, the preferences in NSUserDefaults reset at each login time, user was able to change it when using the app but at next login, everything was back to the IT choice
ALWAYS, the preferences was forced in NSUserDefaults and the app has to be specifically written to check for the managed state and so disable preferences changes in its own settings
Something important to keep in mind, MCX has never disappeared and are still supported and used. MCX distribution via LDAP is gone. And now MCX are distributed via a configuration profile using the following payload format:
With this move from MCX over LDAP to MCX over Profile, we are now restricted to two behaviors, Forced and Set-Once.
Here, on this repository, we use pfm file format to represent a Profile, which is not the same things, and so pfm standard initially described by Apple have evolved to match the new needs.
That's great but that does not allow the pfm reader to know what we are reading now.
Are we reading an actual MCX or a modern Profile? There is no key to give us a clue on that.
This is why I request the introduction of two new keys.
The first one is pfm_manifest_type as a mandatory fixed string value with the following state:
mcx, this is MCX preference that will need to be wrapped in a MCX Profile Payload, the pfm does not describe the wrapper itself, it simply request it
profile, this is a Profile payload that will be directly usable in a Profile envelope
not set, this manifest hasn't been reviewed recently and should be considered carefully
This let us room for extension in the future.
The second one is pfm_mcx_behavior as a mandatory fixed string when pfm_manifest_type is set to mcx, with the following state:
once, the described preferences and app support the set once behavior
forced, the described preferences and app support the forced behavior
When not set, once should be assumed.
The text was updated successfully, but these errors were encountered:
Preference Manifest is a old file format, originally used to describe actual Preferences (as stored in NSUsersDefault) for an app.
This description was then used in Workgroup Manager to generate a dynamic tableview based UI to help IT people to manage app preferences.
Managed preferences was able to be set using one of those 3 behaviors:
Something important to keep in mind, MCX has never disappeared and are still supported and used. MCX distribution via LDAP is gone. And now MCX are distributed via a configuration profile using the following payload format:
https://developer.apple.com/documentation/devicemanagement/managedpreferences
With this move from MCX over LDAP to MCX over Profile, we are now restricted to two behaviors, Forced and Set-Once.
Here, on this repository, we use pfm file format to represent a Profile, which is not the same things, and so pfm standard initially described by Apple have evolved to match the new needs.
That's great but that does not allow the pfm reader to know what we are reading now.
Are we reading an actual MCX or a modern Profile? There is no key to give us a clue on that.
This is why I request the introduction of two new keys.
The first one is
pfm_manifest_type
as a mandatory fixed string value with the following state:mcx
, this is MCX preference that will need to be wrapped in a MCX Profile Payload, the pfm does not describe the wrapper itself, it simply request itprofile
, this is a Profile payload that will be directly usable in a Profile envelopeThis let us room for extension in the future.
The second one is
pfm_mcx_behavior
as a mandatory fixed string whenpfm_manifest_type
is set tomcx
, with the following state:once
, the described preferences and app support the set once behaviorforced
, the described preferences and app support the forced behaviorWhen not set, once should be assumed.
The text was updated successfully, but these errors were encountered: