Resolves a semantic conflict the merge introduces without a textual one:
main added Preferences.GetRemoteJobsAllowed to the Android and iOS SDKs,
reading through profilemanager.ReadConfig, while this branch renamed that
function to ReadOrGenerateConfig. Neither side is broken alone, so only the
merge CI builds for a pull request caught it:
client/android/preferences.go:334:29: undefined: profilemanager.ReadConfig
Both new call sites now use ReadOrGenerateConfig, which is what the getters
around them already do.
Remote jobs (debug bundle requests from management) are gated behind
Config.RemoteJobsAllowed, which defaults to false and could only be
enabled through the CLI flag or an MDM policy. The mobile SDKs had no
way to set it, so the mobile clients always refused the job.
Add GetRemoteJobsAllowed/SetRemoteJobsAllowed to both mobile
Preferences types, following the existing ServerSSHAllowed accessors,
so the apps can offer a settings toggle for it.
ReadConfig and GetConfig differed in one thing — what happens when the file is
absent — and neither name said which was which:
- ReadConfig -> ReadOrGenerateConfig (reads it, or generates one in memory)
- GetConfig -> GetExistingConfig (reads it, or fails)
Three comments went with them:
- GetConfig's said "return with Config and if it was created. Errors out if it
does not exist", which described a bool it does not return and a creation it
never performs.
- ReadConfig's explained that it does not write, which is what a reader is
supposed to do anyway.
- Server.getConfig's said it "errors out if it does not exist", which it does
not — it resolves a default config, and now provisions the identity too.
riccardom