Content
View differences
Updated by Jonas Jabari 13 days ago
Part 3 2 of 5 of the text transform API for the description assistant, in review order dev → AI-133 → AI-135 → AI-134. Exposes assistant. Answers "which actions may run here" to the editor as API v3 endpoints. Pure API ticket on top of AI-135, which owns the availability rules this work package" and exposes the gateway port; nothing later in answer to the stack depends editor. No code dependency on this ticket. part 1, stacked only for a linear review order.
Branch `implementation/ai-134-resolve-available-text-transform-actions-an`, PR #25169 (base: the AI-135 branch).
## Scope
* Three API v3 `GET` endpoints returning the available actions as - Availability service for an `AI::TextTransformAction` against a HAL collection of `AITextTransformAction` (`id`, `label`, `position`, `injectsTypeTemplate`), ordered by position:
* `/api/v3/ai_text_transform_actions`: no context, logged-in user, `everywhere` actions only.
* `/api/v3/work_packages/:id/ai_text_transform_actions`: existing work package, requires `edit_work_packages`.
* `/api/v3/projects/:id/ai_text_transform_actions?typeId=`: new, package or, for unsaved work package of packages, a type: action `active`, `usage_scope` matches the type, actions with `injects_type_template` require a non-blank `default_work_package_description` on the type enabled in the project, requires `add_work_packages`. variant, assistant setting and feature flag on, LLM available.
* Filtering - LLM availability is done entirely by `AI::TextTransforms::Availability#actions_for` from AI-135 (active, usage scope vs. type, template present for `injects_type_template`, feature flag, setting, asked through a small gateway readiness). The client applies no logic. port (`available?`). This part ships a null implementation that always answers "not available"; the real one comes in part 5.
* - API v3 `GET` endpoint for a work package or a type returning `[{ id, label, position }]` ordered by position. Empty collection, list, not an error, when the assistant is unavailable. Until AI-137 replaces off. Requires the null gateway this is always edit permission on the case. work package or the add permission for new ones.
* Representer and collection representer, path helpers, OpenAPI docs with a new `AI` tag, - Unit specs for the availability matrix, request specs for all three endpoints and a representer spec. the endpoint.
## Notes
* AI-98 is merged: - Reuse the `ai_text_transform_actions` feature flag and the `ai_text_transform_actions_enabled` setting exist on dev and are only read here. from AI-98. Whichever PR lands second rebases the setting definition.
* No services, models or workers - Keep type vs. variant scoping in this ticket; `Context`, `Availability`, `Gateway`, `NullGateway`, `Errors`, `Cancelled` and one method: the `FakeGateway` spec double come action is scoped by type, the template comes from AI-135.
* Repo deviations from the hand-off: anonymous access answers 401, a missing `typeId` answers 400. variant.
Branch `implementation/ai-134-resolve-available-text-transform-actions-an`, PR #25169 (base: the AI-135 branch).
## Scope
* Three API v3 `GET` endpoints returning the available actions as
* `/api/v3/ai_text_transform_actions`: no context, logged-in user, `everywhere` actions only.
* `/api/v3/work_packages/:id/ai_text_transform_actions`: existing work package, requires `edit_work_packages`.
* `/api/v3/projects/:id/ai_text_transform_actions?typeId=`: new,
* Filtering
*
* Representer and collection representer, path helpers, OpenAPI docs with a new `AI` tag,
## Notes
* AI-98 is merged:
* No services, models or workers
* Repo deviations from the hand-off: anonymous access answers 401, a missing `typeId` answers 400.