UN-3853 [FIX] Attribute platform-key-created resources to the API key's creator

[kirtimanmishrazipstack]

What

• A resource created through a platform API key — a Prompt Studio project, workflow, ETL pipeline, API deployment, connector or adapter — now belongs to the person who created that API key, instead of belonging to nobody.
• In the rare case where that person has since been deleted from Unstract, the "Owned By" column reads Platform key rather than showing a made-up email address.

Why

• When a script drives Unstract with a platform API key, Unstract signs in as an invisible robot account belonging to that key, and everything the script created was recorded as owned by the robot.
• Unstract deliberately hides robots wherever a person's name belongs. So those resources had no human owner at all: they did not appear in anyone's list, and only an org admin could open, share or delete them. The "Owned By" column had nothing real to show — it used to print Unknown, and since UN-3770 [MISC] Make list pagination consistent across shared resource endpoints #2208 prints the robot's synthetic @platform.internal address with an avatar, which reads as a colleague who does not exist.
• Reported by Chandrasekharan M: a project named "PlatformKey Share Test" showing UN / Unknown in Owned By.
• Today the damage is limited because only org admins can mint platform keys, and admins can manage everything anyway. But if that admin is demoted or leaves the org, the resource is left with nobody attached to it.

How

• New helper owner_user_for(user) in backend/platform_api/services.py: if the acting user is a platform key's service account, return the key's created_by; otherwise return the user unchanged. It short-circuits before any query for a normal session, so the UI path is unaffected.
• This is not a new rule. delete_api_user_for_key in the same module already hands everything a key created over to platform_api_key.created_by when the key is deleted. The change applies that same successor at creation time instead of only at deletion time.
• The helper is routed into all seven places an OWNER membership row is granted: Prompt Studio create + import, workflow, pipeline, API deployment, connector, adapter.
• The service account no longer receives a membership row and needs none — every permission class and every for_user() manager already short-circuits on is_service_account.
• created_by is untouched everywhere. It is an audit field, and "the robot did it" is the truthful answer.
• renderOwner in ResourceTable.jsx recognises the reserved platform.internal domain and renders Platform key instead of dressing a machine identity up as a person. This is what makes a data migration unnecessary — rows created before this change still read correctly.

Can this PR break any existing features. If yes, please list possible items. If no, please explain why.

• No. For a normal signed-in session owner_user_for() returns the user unchanged before touching the database, so every UI-driven create behaves exactly as before — bit for bit.
• The only behaviour that changes is the platform-key path, which today produces an ownerless resource. The service account keeps full access to everything in its org: IsOwner, IsOwnerOrSharedUser, IsParentWorkflowOwner and friends all return True for a service account before ownership is consulted, and for_user() returns the unfiltered queryset for one.
• delete_api_user_for_key still works. Its membership transfer simply finds nothing left to move, and its created_by/modified_by re-pointing is unchanged and still required.
• Existing co-owner tests build membership rows directly rather than going through the create endpoints, so none of them exercise the changed line.

Database Migrations

• None. Resources created before this change keep pointing at a robot, but they read correctly in the UI thanks to the Platform key label, and they are exactly as reachable as they are today (org admins). If we later decide to repair them, the shipped _transfer_membership_rows(key.api_user, key.created_by) does it from a shell — no new code, and no irreversible migration running against production for a handful of rows.

Env Config

• None.

Relevant Docs

• None.

Related Issues or PRs

• Jira: UN-3853
• Builds on the co-owners model from UN-2202 (UN-2202 [FEAT] Add co-owner management for shared resources #1797).
• The created_by_email fallback added in UN-3770 [MISC] Make list pagination consistent across shared resource endpoints #2208 is what changed the symptom from Unknown to a synthetic address; this PR removes the need for it on the platform-key path.
• Cloud counterpart: Zipstack/unstract-cloud#1753 — must merge together, it applies the same fix to agentic projects, agentic connectors and lookup definitions.

Dependencies Versions

• None.

Notes on Testing

#	Acceptance criterion	How to verify	Verdict
1	A resource created via a platform API key never renders Unknown in Owned By	Create a Prompt Studio project with POST /api/v1/unstract/{org}/prompt-studio/ using a Bearer platform key, then open the Prompt Studio list	Met — the column shows the key creator's real email
2	It is reachable by a human owner	Sign in as the key's creator (non-admin is the interesting case) and confirm the project appears in the list and can be shared and deleted	Met — the creator holds a real OWNER row
3	The fix covers every resource type, not just Prompt Studio	Repeat via the workflow, pipeline, API deployment, connector and adapter create endpoints with the same key	Met — all seven grant sites route through the helper
4	A genuinely ownerless resource is labelled, not faked	Null the key's created_by, then reload the list	Met — the cell reads Platform key
5	The UI path is unchanged	Create each resource type normally through the UI	Met — helper returns early for non-service-account users
6	Existing platform-key resources still behave	Load the list as an org admin with a pre-change row present	Met — reads Platform key, same access as before

No automated tests added, per the repo convention of not adding tests unless asked. Happy to add coverage for owner_user_for if reviewers want it.

Screenshots

Checklist

I have read and understood the Contribution Guidelines.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JHnDZZWGhsevUdwgMyR2ai

[greptile-apps]

via Greptile

Confidence Score: 5/5

The PR appears safe to merge.

Summary

• Adds a centralized service-account-to-key-creator ownership resolver and applies it across seven resource-creation paths.
• Exposes owner email data for pipelines and API deployments and unifies owner rendering across table and card views.
• Labels ownerless legacy platform-key resources as “Platform key” and adds endpoint-level ownership coverage.

Diagram

sequenceDiagram
    participant Client
    participant Auth as Platform Key Authentication
    participant API as Resource Create Endpoint
    participant Resolver as owner_user_for
    participant Key as PlatformApiKey
    participant Membership as OWNER Membership

    Client->>Auth: Create resource with platform key
    Auth->>API: "request.user = service account"
    API->>Resolver: Resolve ownership user
    Resolver->>Key: Find key by api_user
    alt Key creator exists
        Key-->>Resolver: created_by
        Resolver-->>API: Human key creator
    else Creator was deleted
        Resolver-->>API: Service account
    end
    API->>Membership: Grant OWNER membership

Loading

_{Reviews (5) · Last reviewed commit: "UN-3853 [FIX] Cover platform-key resourc..."}

[kirtimanmishrazipstack]

Merge this before the cloud PR

Zipstack/unstract-cloud#1753 imports owner_user_for from platform_api.services, and cloud CI pins the OSS tree to refs/heads/main with no override — so its test (integration) and e2e stay red until this merges. Once this lands, a re-run there goes green on its own.

[github-actions]

Frontend Lint Report (Biome)

✅ All checks passed! No linting or formatting issues found.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Unstract test results

Per-group results

Status	Group	Tier	Passed	Failed	Errors	Skipped	Duration (s)
✅	e2e-api-deployment	e2e	3	0	0	0	24.8
✅	e2e-coowners	e2e	1	0	0	0	1.5
✅	e2e-etl	e2e	1	0	0	0	8.2
✅	e2e-login	e2e	2	0	0	0	1.2
✅	e2e-prompt-studio	e2e	1	0	0	0	9.5
✅	e2e-smoke	e2e	2	0	0	0	1.3
✅	e2e-workflow	e2e	1	0	0	0	24.2
❌	frontend	unit	0	1	0	0	0.0
✅	integration-backend	integration	546	0	0	26	53.7
✅	integration-connectors	integration	1	0	0	7	8.4
✅	integration-workers	integration	157	0	0	1	49.4
❌	ui	e2e	0	1	0	0	0.0
✅	unit-backend	unit	1276	0	0	1	44.6
✅	unit-connectors	unit	63	0	0	0	9.9
✅	unit-core	unit	115	0	0	0	2.0
✅	unit-platform-service	unit	15	0	0	0	2.7
✅	unit-rig	unit	120	0	0	0	4.8
✅	unit-runner	unit	5	0	0	0	2.9
✅	unit-sdk1	unit	563	0	0	0	28.9
✅	unit-workers	unit	1425	0	0	1	126.1
	TOTAL		4297	2	0	36	404.1

Critical paths

⚠️ Critical paths not yet covered

• workflow-execution-fan-out — Multi-file workflow execution fans out to file-processing workers and rejoins. (declared coverage: no groups declared)

✅ Covered critical paths

• auth-login — covered by e2e-login
• adapter-register-llm — covered by integration-backend
• workflow-author — covered by integration-backend
• co-owner-manage — covered by integration-backend, e2e-coowners
• workflow-create-execute — covered by e2e-workflow
• api-deployment-provision — covered by integration-backend
• api-deployment-auth — covered by integration-backend
• api-deployment-run — covered by e2e-api-deployment
• mcp-server-auth — covered by integration-backend
• mcp-platform-auth — covered by integration-backend
• platform-key-whoami — covered by integration-backend
• prompt-studio-author — covered by integration-backend
• prompt-studio-fetch-response — covered by e2e-prompt-studio
• connector-register-test — covered by integration-backend
• pipeline-etl-execute — covered by e2e-etl
• usage-aggregate-read — covered by integration-backend
• usage-token-tracking — covered by e2e-api-deployment
• callback-result-delivery — covered by e2e-api-deployment