Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,348 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, python
Área
authentication, authorization, backend-api-design, documentation, frontend, security

Línea de trabajo

Comienza con la auditoría de capacidades en #1347 y, después, lee application/single_app/functions_simplechat_operations.py, functions_authentication.py, functions_governance.py y route_backend_agents.py para identificar el registro, la autorización y los listados de acciones. Rastrea luego los archivos de modal y plugin relacionados para el feedback de autoría, y actualiza functional_tests/route_tests/ y las páginas de documentación indicadas. Se considera terminado cuando la acción de admin y sus agentes están filtrados, la ejecución está protegida de forma independiente, la gobernanza no puede debilitar el umbral mínimo de admin y el feedback de la UI de admin está presente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Python
Estrellas
157
Forks
117
Merge medio
4 h 3 min
PR fusionados (30 d)
217

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/simplechat

Todos los issues de microsoft/simplechat

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.