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

Deleting an organization that has a disabled project fails and leaves it without owners

Abierto
  • ¿Algo no está bien?
#1,978 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
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
62/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
authorization, backend

Línea de trabajo

Start in core/deleter/service.go at DeleteOrganization and CheckOrganizationDelete, then read the notDisabledProjectExp filter in internal/store/postgres/project_repository.go to see why disabled projects are missed by projectService.List. Groups hit the same path through groupService.List. Done means deleting an organization that has a disabled project or group either removes it fully or refuses before any policy is deleted, so owners keep access. Check that behaviour with a test in the deleter package.

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

Descripción

What happens

DeleteOrganization deletes the organization's projects one by one before it removes the organization row. It lists them with projectService.List(project.Filter{OrgID: id}) (core/deleter/service.go, DeleteOrganization), and that list leaves out disabled projects unless a state is asked for (internal/store/postgres/project_repository.go, the notDisabledProjectExp filter). A disabled project is therefore never deleted. The organization row delete then fails on the foreign key from projects.org_id:

foreign key violation [Key (id)=(<org id>) is still referenced from table "projects"]

By that point the deleter has already removed every policy on the organization, including the owners'. The steps are not in one transaction, so nothing is rolled back. The organization is left with no owner. The person who ran the delete gets permission denied on every call for that organization afterwards, including GetOrganization, EnableProject and a second DeleteOrganization. Only a platform superuser can recover it.

Groups have the same shape: groupService.List skips disabled groups and groups.org_id has the same foreign key.

Steps to reproduce

  1. As an organization owner, create an organization and a project in it.
  2. Disable the project with DisableProject.
  3. Call DeleteOrganization. The call answers internal error.
  4. Call GetOrganization as the same owner. The call answers permission denied.

Why it matters

The comment on DeleteOrganization says the org policies go near the end so that a failure at any step leaves the organization owned and the delete can simply be run again. The row delete is the one step after the policies, and this is a plain way to make it fail.

Proposed fix

List projects and groups including disabled ones in the delete cascade, so they are deleted with the organization. As a guard for other causes, CheckOrganizationDelete and the delete itself could refuse up front when a disabled project or group exists, before any policy is removed.

Lenguaje dominante
Go
Estrellas
344
Forks
48
Merge medio
1 d 22 h
PR fusionados (30 d)
38

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

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 raystack/frontier

Todos los issues de raystack/frontier

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.