Connected to Huly®: UBERF-15850

Follow-up: REST API should apply sensible defaults for TxCreateDoc

While testing the token management flow end-to-end (mint token → create issues via REST), I discovered that POST /api/v1/tx/{workspace} passes TxCreateDoc transactions through with zero default-filling. Issues created this way are missing fields that the UI auto-populates, causing them to not appear in project views (only in all-issues).

Missing fields for tracker:class:Issue

When the UI creates an issue, it uses addCollection() which wraps the TxCreateDoc in a TxCollectionCUD, setting:

• attachedTo: tracker:ids:NoParent
• attachedToClass: tracker:class:Issue
• collection: "subIssues"

Plus these attributes that get no server-side defaults:

• kind → must be tracker:taskTypes:Issue (not tracker:ids:ClassingProjectType)
• childInfo: [], parents: [], subIssues: 0, comments: 0, reports: 0
• assignee: null, component: null, dueDate: null
• estimation: 0, remainingTime: 0, reportedTime: 0

Impact

Issues created via bare TxCreateDoc (the natural REST usage) are invisible in project views because the Svelte live query filters on attachedTo/collection. They show up in the all-issues aggregated view only.

Possible approaches

1. Document it — update REST API docs to show the required TxCollectionCUD wrapper pattern for issue creation
2. Server-side defaults middleware — a new middleware in the tx pipeline that merges missing fields from the model schema for known classes (significant arch change)
3. Higher-level REST endpoints — add POST /api/v1/create-issue/{workspace} that accepts a simplified payload and constructs the full TxCollectionCUD server-side, like the importer does

Option 3 seems most API-friendly without changing the platform's "caller provides everything" philosophy. Happy to contribute this if there's interest.

Hi @dnplkndll
Thank you for your contribution.
Could you please check formatting for server/account/src/operations.ts?
The corresponding CI step is failed: https://github.com/hcengineering/platform/actions/runs/23164707679/job/67348370400?pr=10624
You can use rush format to format all project files or rushx format for a specific package.

@ArtyomSavchenko Thanks for the review! Formatting has been fixed — the issue was a prettier version mismatch (local 3.8.1 vs project's 3.6.2). New code now matches the existing codebase style with no formatting noise on existing lines.

Changes in this update

3 commits:

1. feat: API token management — core feature (create/list/revoke tokens, UI, DB, i18n)
2. docs: token scope roadmap — roadmap comments for future scope-based access control
3. feat: enforce API token revocation — addresses a gap where revoked tokens remained usable until JWT expiry

What's new since last push

• Token revocation enforcement — the transactor now checks a per-token revocation cache (60s TTL) before granting API access. Revoked tokens are rejected within ~60 seconds instead of remaining valid until expiry.
• Owner-level workspace token visibility — workspace owners can list and revoke any member's API tokens via listWorkspaceApiTokens / revokeWorkspaceApiToken (OWNER role required).
• Ledo instance URL removed — openapi.yaml now uses a generic https://{host} server variable.

Suggestions for future consideration

1. Token scopes — the roadmap commit documents a proposed extra.scopes JWT field for fine-grained access control (read-only tokens, class-restricted access). This would enable safe MCP/AI agent integrations without MCP-layer changes.

2. Higher-level REST endpoints — as noted in my earlier comment, POST /api/v1/tx requires the caller to construct full TxCollectionCUD wrappers. A POST /api/v1/create-issue style endpoint would make the API much more accessible for integrations.

3. Revocation cache scaling — the current per-token cache works well for moderate usage. For high-traffic deployments, a Redis-backed revocation set or short-lived tokens (< 1 hour) with refresh would be more robust.