[educalleja]

Stacked on #702.

Makes the service account operations in Tower CLI commands on 26.2 work end to end. No other operations from that page are included.

What was broken

The tw service-accounts add|list|view|update|delete commands from #702 already match the page (options, output, and the not-found error). Workspace assignment didn't work:

$ tw participants add -w my-org/my-workspace -t MEMBER -n ci-bot

failed with Service accounts cannot be added as workspace collaborators. The platform's organization members list (GET /orgs/{orgId}/members) leaves out service accounts, because the service_account org role isn't assignable. So the CLI fell back to adding by userNameOrEmail, and the platform rejects service accounts on that path.

Fix

• When -t MEMBER doesn't match an organization member, participants add looks the name up among the organization's service accounts and adds it by memberId. The platform then assigns the service account to the workspace with the VIEW role by default.
• If the name contains @, or the caller can't list service accounts (feature disabled or not an org admin), the command falls back to the old add-by-user-name behavior. Existing invite flows are unaffected.
• The by-name service account lookup moves from AbstractServiceAccountsCmd to AbstractApiCmd so both commands share it.
• USAGE.md now mentions the default VIEW role and how to change it.

tw participants update and tw participants delete already work with no changes: the participants list returns service accounts as MEMBER and matches them by user name (which is the service account name), and the platform routes role updates for service accounts through its service account service.

Tests

• New ParticipantsCmdTest.testAddServiceAccountParticipant.
• ./gradlew test: 774 tests, 0 failures.

🤖 Generated with Claude Code