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

Use computed permissions for group membership instead of direct relations

Abierto
  • ¿Algo no está bien?
#1,479 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
go
Área
authorization, backend

Línea de trabajo

Comienza con base_schema.zed y core/group/service.go:168-221, y luego busca referencias a group#member. Verifica cómo las políticas de organización y proyecto exponen la pertenencia antes de cambiar el esquema del grupo y eliminar la creación directa de relaciones de AddMember y addOwner. El trabajo está terminado cuando la pertenencia a grupos utiliza las políticas de forma coherente y todas las referencias a group#member utilizan el permiso calculado.

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

Descripción

Problem

Group membership currently uses direct group#member@user relations, while organization and project membership use policies (role bindings). This inconsistency means groups require special handling.

Current State

Resource How membership works
Organization Policies (role bindings)
Project Policies (role bindings)
Group Direct group#member@user relation

When a user is added to a group, we create both a policy AND a direct relation.

Source: core/group/service.go:168-191

// AddMember adds a subject(user) to group as member
func (s Service) AddMember(ctx context.Context, groupID string, principal authenticate.Principal) error {
    // first create a policy for the user as member of the group
    if err := s.addMemberPolicy(ctx, groupID, principal); err != nil {
        return err
    }

    // then create a relation between group and user as member
    rel := relation.Relation{
        Object: relation.Object{
            ID:        groupID,
            Namespace: schema.GroupNamespace,
        },
        Subject: relation.Subject{
            ID:        principal.ID,
            Namespace: principal.Type,
        },
        RelationName: schema.MemberRelationName,
    }
    if _, err := s.relationService.Create(ctx, rel); err != nil {
        return err
    }
    return nil
}

Same pattern exists for addOwner at lines 193-221.

Proposed State

Resource How membership works
Organization Policies (role bindings)
Project Policies (role bindings)
Group Policies (role bindings)

Group membership becomes computed from policies, just like org and project.

How it works

Schema change:

// Before
definition group {
    relation member: app/user  // direct relation
    permission get = ... + member
}

// After
definition group {
    relation granted: app/rolebinding
    permission members = granted->app_group_member  // computed from policies
    permission get = ...
}

SpiceDB resolves group members by:

  1. Find all role bindings granted to the group
  2. Filter to those with "Group Member" role
  3. Return their bearers

Tested in AuthZed Playground - this approach works.

Benefits

Benefit Description
Consistency All resources (org, project, group) use the same pattern
Single source of truth Membership determined by policies only, no sync issues
Simpler code Remove direct relation management for groups
SDK simplicity Same role-based API for all resources

Potential Downsides

Concern Impact Mitigation
Query complexity Membership is computed, not direct lookup SpiceDB optimizes and caches these
Schema migration Need to update SpiceDB schema Can be done incrementally
Breaking change External systems using group#member relation Document in release notes

Code Changes

  1. Update base_schema.zed - change group#member from relation to computed permission
  2. core/group/service.go - AddMember: remove relationService.Create call, keep only policy
  3. core/group/service.go - addOwner: remove relationService.Create call, keep only policy
  4. Update references from group#member to group#members (the computed permission)
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.