docs: correct the automation step for enable_user and disable_user - #147
docs: correct the automation step for enable_user and disable_user#147carolinaroncaglia wants to merge 1 commit into
Conversation
Both actions are account-lifecycle actions and are reached from the Account lifecycle action step. The page named the Perform connector action step, where they do not appear -- that step lists actions scoped to a resource type. Also corrects the privilege note: Snowflake requires MODIFY on the target user, not OWNERSHIP, and MODIFY can be granted without transferring ownership. Adds the condition under which the restriction surfaces at all, since a service account on the default DEFAULT_SECONDARY_ROLES = ALL never hits it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Connector PR Review: docs: correct the automation step for enable_user and disable_userBlocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0 Review SummaryThis is a docs-only change to the Connector actions section of Security IssuesNone found. Correctness IssuesNone found. SuggestionsNone. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
1 participant
Summary
The Connector actions section named the Perform connector action automation step.
enable_useranddisable_userare not offered there — both are account-lifecycle actions and are reached from the Account lifecycle action step. A reader following the page selected the connector in a Perform connector action step and found an empty action list, with nothing on the page pointing anywhere else.This rewrites the section on the pattern
baton-okta's page already uses: name the step that offers each action, and state that the routing is not selectable.Findings addressed
1. Wrong automation step named — measured. In the Perform connector action step with the connector selected, the Action name dropdown returns zero options; typing
user,able,a,eeach return zero. The control is in the same panel: Select a connector populates without typing, so the empty list is not the autocomplete awaiting input. Both actions execute from the Account lifecycle action step, with the effect verified in Snowflake by SQL. A stale action-schema ingest is excluded — that fails withdynamo: no item found, and both executions succeeded.Which step offers an action is determined by the action's
ActionType, not by registration scope.pkg/connector/actions.go:40,51declares[ACCOUNT, ACCOUNT_DISABLE]and[ACCOUNT, ACCOUNT_ENABLE].baton-ldapregisterscreate_ouglobally withRESOURCE_CREATEand it does appear in the generic step, so global-vs-resource-scoped is not the discriminator. Inbaton-sdkv0.24.6,pkg/actions/actions.go:274-286keeps the two kinds in separate maps and the resource-type-filteredListActionSchemasat:514-545reads only the resource-scoped one.2. Required privilege overstated — measured. The note asked for
OWNERSHIP. Snowflake's error asks forMODIFY:Insufficient privileges to operate on user '<name>'. Your primary role USERADMIN must have MODIFY granted on USER <name>.MODIFYcan be granted without transferring ownership, so the documented remedy was stricter than required.3. Missing condition on that restriction — measured. It does not surface when the service account keeps Snowflake's default
DEFAULT_SECONDARY_ROLES = ALL: a higher secondary role such asACCOUNTADMINstays active alongside the forcedUSERADMINprimary role and supplies the privilege. Reproducing the documented failure requiredALTER USER <svc> SET DEFAULT_SECONDARY_ROLES = ().The
enable_userlockout note was already accurate and is unchanged.Why it mattered
The page was added with the actions themselves, so the first readers of the feature would have been the ones to hit it. The published page has no Connector actions section yet, so the correction lands before it reaches customers.
Not changed
README.mddocuments no actions at all. That is a separate gap and is out of scope here.Measured on a live tenant against v0.1.24 on channel
latest.