Projects list: show organization name per project

[yustme]

Feature request

The Projects page lists all registered projects with columns: ALIAS, PROJECT, ID, STACK, STATUS, TOKEN. There is no indication of which organization each project belongs to.

When multiple organizations are registered (e.g. a consulting setup with several customer orgs, or a company with separate prod/dev orgs), there is no way to tell them apart in the UI — all projects look the same regardless of which org they come from.

Current state

ProjectConfig (models.py) stores stack_url, token, project_name, project_id, but no org info. The Manage API client already has get_project() which returns a response that includes an organization field ('id', 'name'), but this is never persisted into the config.

Proposed fix

1. Persist org name at project registration time — when kbagent project add or kbagent org setup registers a project, fetch and store org_id + org_name into ProjectConfig.
2. Show ORG column in the Projects table — add an ORGANIZATION column between ALIAS and PROJECT (or after PROJECT). For projects registered without a Manage API token (org info unavailable), show —.
3. Group by org (optional enhancement) — if multiple orgs are present, group the project rows under collapsible org headers for easier scanning.

UX sketch

ALIAS              ORG              PROJECT          ID     STACK    STATUS
case-study-1       Acme Corp        Case Study 1     2570   gcp/eu   387ms
case-study-2       Acme Corp        Case Study 2     2571   gcp/eu   389ms
b2b                Keboola Demo     b2b              8276   gcp/eu   189ms
__l10-common-data  Keboola Demo     L10 – Common     659    gcp/eu    34ms

This makes it immediately obvious when you're looking at projects from different organizations, which is critical for anyone managing multiple customers or environments.

[padak]

Update after implementation analysis

Three rounds of automatic org-name backfill failed because the Storage API never returns the org name — only the id. Empirically verified against a real stack (connection.us-east4.gcp.keboola.com):

curl -H "X-StorageApi-Token: $TOKEN" /v2/storage/tokens/verify

returns organization at the top level (not nested under owner as I had originally assumed), and the payload is minimal:

{
  "organization": { "id": "73" }
}

The org name only lives in the Manage API (/manage/organizations/{id}), which requires a Manage API token. kbagent serve typically does not have one — it uses a Storage token per project, and the Manage token is default-deny (it must be explicitly opted in via --allow-env-manage-token).

What was implemented

1. Backend correctly parses the top-level organization.id from the Storage verify response and normalises the string "73" to int 73.
2. ProjectConfig persists org_id (int) and org_name (str | None) → config.json carries both fields, backward-compatible with legacy configs that lack them.
3. Org backfill during org setup (via Manage API): org setup calls get_organization(org_id) and populates the name too. Projects registered through org setup after this change get the full name.
4. UI fallback in the Projects table + project picker:
   • When org_name is known → renders Keboola Demo.
   • When only org_id is known → renders #73 (a tooltip explains how to populate the name).
   • When neither is known (legacy stacks) → renders —.

What did not work, and why

Auto-backfill of the org name for projects registered via plain kbagent project add (Storage token only, no Manage token) is not possible — the Storage API does not return it. Those projects keep #73 until the user runs kbagent org setup for that organization (or a future kbagent project refresh-org with a Manage token).

Decision

We accept the #73 fallback as a pragmatic compromise. Multi-org setups stay distinguishable by id. #73 is a stable identifier in Keboola — users coming from the console already know their org ids.

Closing this issue once the PR lands. If a "Refresh org names" UI button (with a one-shot Manage-token prompt) becomes valuable later, I will open a follow-up issue for it.

[padak]

Shipped in v0.40.3 (PR #299) — with the documented compromise (#73 fallback when Manage API is out of reach).

Thank you @yustme for the patient three rounds of testing on this one — surfacing that I was reading owner.organization instead of top-level data.organization was the actual root cause. The empirical curl against the real stack made all the difference. 🙏