docs: list allowRemoteJobs among the keys iOS enforces without a control

The key is enforced on iOS like the other engine-applied ones: a peer
whose policy withholds it refuses management-requested jobs. What is not
there yet is the lock on the Troubleshoot toggle, which arrives with the
iOS client PR that introduces that toggle — so promising it in the table
of what the user sees would describe a screen that does not exist.

Moved to the group of keys the engine applies with nothing on screen to
mark, next to blockInbound, wireguardPort, lazyConnection and
debugBundleUploadURL. It moves back to the table once the toggle ships.
This commit is contained in:
riccardom
2026-09-17 09:17:25 +02:00
parent 54aa32788e
commit 6565b8368e
+5 -4
View File
@@ -453,13 +453,14 @@ to the connection — `managementURL`, `preSharedKey`, `rosenpassEnabled`,
| `disableNetworks` | Removes the Resources tab |
| `disableAdvancedView` | Hides Advanced (on tvOS, the whole section) |
| `disableUpdateSettings` | Read-only mode: nothing is hidden, every configuration control is locked |
| `allowRemoteJobs` | Locks the remote debug bundle toggle |
The table above is what the user sees. A second group of keys has no
control to lock, because the engine applies them straight to the
connection: `blockInbound`, `wireguardPort`, `lazyConnection`, and
`debugBundleUploadURL` when a remote job produces a bundle. They are
enforced just the same — there is simply nothing on screen to mark.
connection: `blockInbound`, `wireguardPort`, `lazyConnection`,
`allowRemoteJobs`, and `debugBundleUploadURL` when a remote job produces
a bundle. They are enforced just the same — a peer whose policy withholds
`allowRemoteJobs` refuses those jobs — there is simply nothing on screen
to mark yet.
The rest do not apply to the platform and are parsed and ignored:
`allowServerSSH` (no SSH server on iOS), `disableServerRoutes` (an iOS