Assistant field permissions (feature 090)

Assistant field permissions (feature 090)

Ajutant feature 090 (assistant-field-permissions) controls which assistant fields are editable in the admin panel, based on whether the assistant is distributed or local.

What this feature does

• Distributed assistants: fields set by the assistant developer are locked (read-only) for client admins.
• Local assistants: all fields are editable.
• The edit form shows a clear visual separation between:
  • a read-only assistant design section (developer fields)
  • an editable operations section (admin fields)

How Ajutant determines distributed vs local

To reliably identify whether an assistant is distributed, Ajutant checks:

• client_module_entitlements for the assistant’s module
  • If an entitlement exists, the assistant is distributed, and developer fields are locked.
  • If no entitlement exists, the assistant is local, and all fields are editable.

Which fields are locked vs editable

The feature overview describes two groups of fields:

Developer fields (locked for distributed assistants)

These define the assistant’s behaviour and design, for example:

• system prompt
• guardrails
• capability requirements

For distributed assistants, these fields are:

• displayed as read-only
• shown with a lock icon
• accompanied by a tooltip text: “Set by the assistant developer”

Admin fields (editable)

These are operational settings controlled by the client admin, for example:

• which model deployment to use
• whether the assistant is active or inactive

For distributed assistants, these fields are:

• displayed in an editable operations or configuration section
• persisted when the admin saves changes

What the admin edit form should look like

For distributed assistants, the edit form should clearly separate the two field groups:

• A read-only section labelled “Assistant Design”
  • muted background
  • lock icons
• An editable section labelled “Operations”
  • normal editable styling

When hovering over a locked field, the tooltip should explain:

• “This setting is managed by the assistant developer and cannot be changed locally”

For local assistants, there is no locked section and all fields are editable.

Expected save behaviour

When a distributed assistant is edited and saved:

• Admin fields (for example, deployment selection, active toggle) should be saved.
• Developer fields (for example, system prompt, guardrails, capabilities) should remain unchanged.

Testing and acceptance checks (what to verify)

Use the following checks when validating the feature:

Distributed assistant checks (from a .ajutant module)

1. Open the assistant in the admin panel.
   • Developer fields are read-only (lock icon, tooltip “Set by the assistant developer”).
   • Admin fields are editable.
2. Verify a locked field (example: system prompt):
   • no edit cursor
   • no save button for that field
3. Change an admin field (example: chat deployment) and save:
   • deployment change is saved
   • developer fields remain unchanged
4. Toggle active/inactive and save:
   • toggle works normally (admin field)

Local assistant checks (not distributed)

1. Open a locally created assistant in the admin panel.
2. Verify all fields are editable:
   • no locked sections

Notes for reviewers

• The feature status is partial, so there may be additional behaviour beyond what is included in the provided spec overview.
• If you need the exact list of field names that are treated as “developer fields” vs “admin fields” in your UI, this is not enumerated in the provided source. Review the implementation to confirm the mapping matches the described categories (design vs operations).