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

Add support for Team level authorization in Atlas/WebAPI

Abierto
  • ¿Algo no está bien?
#2,369 2 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
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
java
Área
authorization, backend-api-design

Línea de trabajo

Comienza con la configuración vinculada con acceso de lectura restringido y sigue el flujo del servicio de autorización, las actualizaciones de la tabla sec_user_role y la recuperación de la definición de cohorte. Determina cómo deben interactuar la selección del equipo, las comprobaciones de pertenencia, el reemplazo de roles y el filtrado de artefactos. Se considera terminado cuando los artefactos propiedad de un equipo son visibles para sus miembros, pero están restringidos para otros equipos, y se conserva el comportamiento existente del acceso personal.

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

Descripción

Expected behavior

New feature request: Following-up on the recent "read restricted" feature introduced in https://github.com/OHDSI/WebAPI/issues/2222 and documented at https://github.com/OHDSI/WebAPI/wiki/Read-restricted-Configuration, it would be nice to have a way to assign permissions on artifacts (like concept sets and cohort definitions) to a group/team of users, so members of the same team can see and use each others artifacts, while at the same time hiding them/restricting their access for other teams.

Actual behavior

Currently any user sees all artifacts created by all other users. With the recent "read restricted" feature referenced above, it is also possible to let the user see only the artifacts he has personally authored.

Background info

Below are some figures and diagrams clarifying the requirements (taken from slides recently presented in one of our dev calls).

Screenshot 2024-05-07 at 17 55 25

Screenshot 2024-05-07 at 17 58 29

Screenshot 2024-05-07 at 17 59 20
Diagram steps explained:

  1. user X selects "team A" (during or after login)
  2. authorization service is queried to check if user X is really part of "team A"
  3. if authorization is successful, the sec_user_role table is updated for user X, assigning the corresponding "team A" role to user X and removing any other user roles assigned to this user (e.g. "team B" from a previous session by this same user)
  4. and 5. subsequent requests done by user X, like a call to retrieve the list of cohort definitions, will automatically result in a filter being applied in the backend, narrowing down the result set to just the items owned by "team A" role
Lenguaje dominante
Java
Estrellas
153
Forks
186
Merge medio
2 d 12 h
PR fusionados (30 d)
13

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin 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 OHDSI/WebAPI

Todos los issues de OHDSI/WebAPI

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.