[jcombs-pointblue]

Phase 2 of docs/MCP.md: the change tools, with approval in the console.

Stacked on #5: the base is feature/mcp-phase1, so the diff shows phase 2 only. Merge #4, then #5, then this; GitHub retargets this PR to main when #5's branch is deleted.

Change tools

Each tool is listed only when the key has the role it needs, and refuses at once when that role's scope doesn't reach the object:

Tool	Role	API call
enable_account, disable_account	editor	PATCH objects/{guid}/account {disabled}
unlock_account	editor	POST objects/{guid}/unlock
add_to_group, remove_from_group	editor	POST objects/{guid}/memberships (both sides)
start_driver, stop_driver	operator	POST idm/drivers/{guid}/start|stop
run_job, abort_job	operator	POST idm/jobs/{guid}/start|abort
resync_driver	operator	POST idm/drivers/{guid}/resync {since?}
migrate_object_to_app	operator	POST idm/drivers/{guid}/migrate/to-app with the object as base
migrate_from_app	operator	POST idm/drivers/{guid}/migrate/from-app
change_status	any	the state of a change the key asked for

The design note listed "resynchronize an object". The API resynchronizes a driver (all of it, or since a time), so that's the tool; the note now says so.

Approval (approveChanges, per directory, on by default)

• Asking: the tool answers 202 with a pending change (AgentChanges): its id, a summary and the link /agent-keys?change=<id>.
• Approving or declining: on the Agent keys page, Changes agents asked for lists them. The link opens the review dialog. The person approves, typing the directory's name on production, or declines; an admin can also decline.
• What approval does: the call is made then, in-process, as the key: Agents.check checks the key and the account again, and eDirectory decides with the person's rights.
• When it can't be approved: after an hour the change expires; a change from a key revoked since can't be approved.
• Storage: pending changes are kept in memory, so a restart drops them (documented).
• With approval off: the change is made at once. On production the agent passes confirm = the directory's name, which the engine's operations require.
• Audit: agent-change.request, agent-change.approve and agent-change.decline, plus the change's own entry with via = agent and the key.

Also

Account changes and unlock now report eDirectory's "no such attribute" answer, which it gives under proxied authorization for a write the person has no right to, as insufficient-rights, as object edits already did. This affects single sign-on sessions too.

Tests

• AgentsTest:
  • a read-only key gets no change tools;
  • out-of-scope changes are refused;
  • pending → approve, then the change is in the directory;
  • only the key's owner can approve;
  • decline;
  • a revoked key's change can't be approved;
  • approval off: the driver starts at once, and on production confirm is required;
  • approving on production needs the directory's name.
• All 165 server tests and 53 UI tests pass; npm run build passes.
• On the DemoServer: pat's agent asked to disable a Sales user; the link opened the review dialog; Approve disabled the account; the list showed it approved.
• Live on idm254 with LiveAgentsCheck, all steps passing:
  • the test user's key asked to disable a second scratch user, and the change waited for approval;
  • the user approved it, and eDirectory refused it with insufficient-rights: the user has no rights over that account, which shows the change runs with the person's rights;
  • change_status reported the outcome, a second change was declined, and with approval off the change ran at once (refused by eDirectory the same way);
  • the phase 1 steps still pass, and the scratch container was deleted.

Not in this phase: setting passwords (design: generated, then applied by an operator in the console), and Identity Applications (phase 3).

🤖 Generated with Claude Code