Content
View differences
Updated by Jonas Jabari 26 days ago
<br>
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/923243/content"> src="/api/v3/attachments/923082/content">
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/923244/content"> <br>
As an OpenProject admin
I want to manage the text-transform actions of the description assistant
so that I can tailor the assistant to my organization's templates and writing standards.
## Acceptance criteria
* In the admin section "Artificial Intelligence (AI)" a new menu entry "Description assistant" is available (sibling of "LLM settings").
* The page contains a boolean **"Enable description assistant"** (feature toggle, independent of but dependent on the global AI/LLM toggle from AI-3). When disabled, the actions list below is still editable, but no actions are offered to end users.
* If no LLM connection is configured/enabled, a callout is shown linking to the LLM settings page. The actions remain editable (prompts are plain configuration data).
* **Actions list** shows all actions in `position` order with: label, "Default"-badge for builtin actions, active toggle, type restriction summary ("All types" / "3 types"), and reorder controls.
* **Create/Edit form** with:
* Label (required, max length)
* Prompt (required textarea; for builtin actions pre-filled with the effective prompt text)
* Model (optional dropdown fed from the models list of the LLM connection; first option "Default (from LLM settings)")
* Work package types: radio "All types" (default) / "Selected types" with a checkbox list (same interaction pattern as custom field → type activation)
* Active checkbox
* Builtin actions additionally offer **"Reset to default"** (with confirmation): restores the shipped prompt text (and shows it immediately in the form).
* Builtin actions cannot be deleted — only deactivated. Custom actions can be deleted (with confirmation).
* The builtin action "Sort into template" shows an informational hint that its availability additionally depends on the work package type having a default description template, with a link to the types administration.
* Changes are effective immediately for subsequent action listings (no caching requirements).
## Technical notes
* Modern admin stack: `layout "admin"`, Primer ViewComponents, `ApplicationForm` (see `app/forms/admin/settings/color_form.rb` as reference), Turbo where useful (`OpTurbo::ComponentStream`).
* Menu registration in `config/initializers/menus.rb` under the AI parent introduced by AI-3 (coordinate the parent menu key and route namespace, e.g. `/admin/ai/description_assistant`).
* Feature toggle as a Setting (`Settings::Definition`), name coordinated with AI-3 (e.g. `ai_description_assistant_enabled`).
## Permissions and visibility considerations
* Admins only (`before_action :require_admin`).
* Whether the feature is Enterprise-gated is an open product decision tracked on the epic; the implementation should make gating trivial to add (single guard).
## Translation considerations
* All UI strings translatable. Seeded action labels are translated via the seeder mechanism; admin-entered labels and prompts are not translated.
* "LLM" is not translated (consistent with AI-3).
## Out of scope
* Testing sandbox (separate feature)
* Grouping, icons, drag & drop beyond simple reordering
* Import/export of actions
* Per-project actions
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/923243/content">
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/923244/content">
As an OpenProject admin
I want to manage the text-transform actions of the description assistant
so that I can tailor the assistant to my organization's templates and writing standards.
## Acceptance criteria
* In the admin section "Artificial Intelligence (AI)" a new menu entry "Description assistant" is available (sibling of "LLM settings").
* The page contains a boolean **"Enable description assistant"** (feature toggle, independent of but dependent on the global AI/LLM toggle from AI-3). When disabled, the actions list below is still editable, but no actions are offered to end users.
* If no LLM connection is configured/enabled, a callout is shown linking to the LLM settings page. The actions remain editable (prompts are plain configuration data).
* **Actions list** shows all actions in `position` order with: label, "Default"-badge for builtin actions, active toggle, type restriction summary ("All types" / "3 types"), and reorder controls.
* **Create/Edit form** with:
* Label (required, max length)
* Prompt (required textarea; for builtin actions pre-filled with the effective prompt text)
* Model (optional dropdown fed from the models list of the LLM connection; first option "Default (from LLM settings)")
* Work package types: radio "All types" (default) / "Selected types" with a checkbox list (same interaction pattern as custom field → type activation)
* Active checkbox
* Builtin actions additionally offer **"Reset to default"** (with confirmation): restores the shipped prompt text (and shows it immediately in the form).
* Builtin actions cannot be deleted — only deactivated. Custom actions can be deleted (with confirmation).
* The builtin action "Sort into template" shows an informational hint that its availability additionally depends on the work package type having a default description template, with a link to the types administration.
* Changes are effective immediately for subsequent action listings (no caching requirements).
## Technical notes
* Modern admin stack: `layout "admin"`, Primer ViewComponents, `ApplicationForm` (see `app/forms/admin/settings/color_form.rb` as reference), Turbo where useful (`OpTurbo::ComponentStream`).
* Menu registration in `config/initializers/menus.rb` under the AI parent introduced by AI-3 (coordinate the parent menu key and route namespace, e.g. `/admin/ai/description_assistant`).
* Feature toggle as a Setting (`Settings::Definition`), name coordinated with AI-3 (e.g. `ai_description_assistant_enabled`).
## Permissions and visibility considerations
* Admins only (`before_action :require_admin`).
* Whether the feature is Enterprise-gated is an open product decision tracked on the epic; the implementation should make gating trivial to add (single guard).
## Translation considerations
* All UI strings translatable. Seeded action labels are translated via the seeder mechanism; admin-entered labels and prompts are not translated.
* "LLM" is not translated (consistent with AI-3).
## Out of scope
* Testing sandbox (separate feature)
* Grouping, icons, drag & drop beyond simple reordering
* Import/export of actions
* Per-project actions