Show teammates' shared machines, read-only, on the Machines page and in the document's machine menu

Cerrado
  • ¿Algo no está bien?
#769 1 comentario 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@lavaman131 ya está trabajando en esto.

Desde el 5/11/2026.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
full-stack

Línea de trabajo

Start with sharedPlannerMachine and readyFor in apps/server/src/experiments/routes.ts, which already decide when a teammate's shared machine can run a Planner, and with GET /api/connector/machines, which calls auth.machines.list(session.user.id) and so returns only the viewer's own machines. Settle the open question about who may choose a teammate's machine before changing code. Done means the Machines page shows a read-only 'Shared with you' group, the document machine menu lists eligible machines, the owner-only routes still refuse non-owners, and server and web tests cover all three.

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

Descripción

Summary

Show teammates' shared machines, read-only, wherever a person sees machines: the Machines page and a document's machine menu (the cloud icon next to Build).

Today

  • A machine its owner marks shared can already run a teammate's Planner. Default machine picks it when the document's creator has no machine of their own and the machine's owner can push to the repository (sharedPlannerMachine and readyFor in apps/server/src/experiments/routes.ts).
  • GET /api/connector/machines returns only the signed-in person's machines (auth.machines.list(session.user.id)). So the Machines page and the document's machine menu never list a teammate's shared machine, even while it runs that person's Planner.
  • From the other side, a person whose document runs on a teammate's machine can't see that machine, whether it is online, or pick it. A document that says "Planner: starting on " names a machine they have no way to look at.

Proposal

  1. Machines page: a "Shared with you" group listing teammates' shared machines that serve repositories the viewer can push to. Each row shows the name, the owner, online or offline, version, and the repositories it has checkouts for. They are read-only: no rename, favorite, share toggle, disconnect or setup actions.
  2. Document machine menu: list the same machines, under the owner's name, when they serve the document's repository and their owner can push to it, the same check Default machine uses. Choosing one sets the document's machine as choosing your own does. Offline ones are disabled, as for your own machines.
  3. API: GET /api/connector/machines returns those machines with an owner field and a flag that marks them as not the viewer's, and leaves out owner-only fields (autoRun, reauthorize, finishing). The owner-only routes (/label, /favorite, /shared, /revoke) keep refusing anyone but the owner.
  4. Unsharing: when the owner stops sharing, the machine leaves teammates' lists, and the work it is finishing keeps today's behavior.

Acceptance

  • A teammate's shared machine appears on the Machines page under "Shared with you", with its owner and online state, and no management actions.
  • It appears in the document's machine menu (Local or Cloud) when it serves the repository and its owner can push there. Choosing it runs that document's Planner and builds there.
  • A machine that is not shared, or whose owner can't push to the repository, never appears to anyone but its owner.
  • The owner-only routes refuse a non-owner; server and web tests cover the listing, the menu and the refusals.

Open question

  • Should choosing a teammate's machine be limited to documents whose creator has no machine of their own, as Default machine is today, or open to any document the viewer can edit?
Lenguaje dominante
TypeScript
Estrellas
591
Forks
33
Merge medio
4 h 13 min
PR fusionados (30 d)
412

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 githubnext/chopin

Todos los issues de githubnext/chopin

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.