Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add an admin-only SimpleChat Admin action that restricts any agent using it to admins

Aperta
  • Qualcosa non va?
#1,348 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript, python
Ambito
authentication, authorization, backend-api-design, documentation, frontend, security

Direzione di ricerca

Inizia con l’audit delle capability in #1347, poi leggi application/single_app/functions_simplechat_operations.py, functions_authentication.py, functions_governance.py e route_backend_agents.py per mappare la registrazione, l’autorizzazione e gli elenchi delle azioni. Traccia quindi i file modal e plugin correlati per il feedback di authoring, poi aggiorna functional_tests/route_tests/ e le pagine di documentazione indicate. Il lavoro è completato quando l’azione admin e i relativi agent sono filtrati, l’esecuzione è protetta in modo indipendente, la governance non può indebolire il livello minimo admin e il feedback nella UI admin è presente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Add a second, separate action type — SimpleChat Admin — for SimpleChat operations that only an application admin should be able to perform. The action is invisible to non-admins, and any agent that references it becomes admin-only. That restriction is enforced in code as a floor, not left to governance policy.

User Value

Admin-capable operations are currently mixed into the general SimpleChat action. make_group_inactive is the clearest example: it already requires Control Center admin access, so a normal user can enable it on an action, attach it to an agent, and only discover the problem as a runtime permission failure. That is a late and confusing way to learn about a permission boundary.

A dedicated admin action makes the boundary explicit at design time, keeps privileged operations out of the capability list that ordinary authors browse, and gives admins one obvious place to look when auditing who can do what.

Proposed Behavior

Visibility
  • Non-admin users never see the SimpleChat Admin action type in the action picker, the action type list, or any action listing API.
  • Non-admin users never see an agent that references the admin action — in any agent list, catalog, picker, popular-agents surface, or template listing.
  • If an admin attaches the action to an otherwise ordinary agent, that agent disappears for non-admins rather than failing later.
Enforcement
  • Visibility filtering is a convenience, not the control. Server-side execution must independently refuse to run an agent carrying the admin action for a non-admin caller, with a clear error.
  • The same refusal applies to workflows bound to such an agent.
Admin authoring experience
  • When an admin adds the SimpleChat Admin action to an agent, show a confirmation notice in the agent modal explaining that the agent becomes admin-only from that point on.
  • Show a persistent badge on any agent carrying the action so the restriction is visible at a glance, not only at the moment it was added.
  • Show the same notice when a workflow is bound to an agent carrying the action.
Relationship to governance

This is a hard, built-in restriction that sits underneath governance rather than inside it. Governance can narrow access further; it can never widen it.

Governance already supports item-level policies for global_agent, global_action, and action types including global_action_type (application/single_app/functions_governance.py:39-56). The admin action should register as a governed action type so an admin can restrict it further — for example to a subset of admins in a multi-admin tenant — but the admin-only floor must hold even when no policy is configured.

Capabilities

The capability set needs its own audit as part of this work. Starting points to evaluate:

  • Move make_group_inactive out of the general SimpleChat action, since it already requires Control Center admin access.
  • Identify which other existing SimpleChat capabilities are really admin operations wearing a user-permission costume.
  • Decide which genuinely new admin operations are worth exposing at launch, keeping the initial set small and defensible.

Acceptance Criteria

  • A simplechat_admin action type exists with its own capability definitions, separate from the general SimpleChat action.
  • The action type is filtered out of every non-admin-facing action listing and action picker.
  • Agents referencing the action are filtered out of every non-admin-facing agent listing, catalog, and picker.
  • Server-side execution refuses non-admin invocation with a clear error, verified independently of any UI filtering.
  • An admin sees a clear warning when attaching the action to an agent, and a persistent badge on the agent afterwards.
  • The action type is visible in the governance portal so admins can restrict it further, and governance cannot grant access below the built-in admin floor.
  • Existing agents that do not use the action are completely unaffected.
  • Route tests updated under functional_tests/route_tests/ for any new or changed endpoint and its auth policy.
  • Functional tests cover: non-admin cannot list the action, cannot see an agent using it, and cannot execute it; admin can do all three.
  • Documentation updated: feature doc under docs/explanation/features/, an action reference page under docs/reference/actions/, the governance admin doc, and docs/explanation/release_notes.md.

Open Questions

  • Which capabilities ship in the admin action at launch?
  • Should "admin" mean the application Admin role (admin_required), Control Center admin access (control_center_required), or either? These are distinct today in functions_authentication.py.
  • What should happen to an agent carrying the action when a user's admin role is revoked while a session or scheduled workflow is active?
  • Should group-scoped privileged operations key off group admin role rather than application admin?
  • Does the restriction need to propagate to agent templates and any export/import path?

Notes

Depends on the capability audit in #1347, since at least one capability is expected to move between the two actions.

Primary files:

  • application/single_app/functions_simplechat_operations.py
  • application/single_app/semantic_kernel_plugins/simplechat_plugin.py
  • application/single_app/semantic_kernel_loader.py
  • application/single_app/functions_governance.py
  • application/single_app/functions_authentication.py
  • application/single_app/route_backend_agents.py
  • application/single_app/static/js/plugin_modal_stepper.js
  • application/single_app/static/js/agent_modal_stepper.js
Lingua principale
Python
Stelle
153
Fork
116
Merge medio
6h 49m
PR unite (30g)
158

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/simplechat

Tutte le issue di microsoft/simplechat

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.