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

Geschlossen
  • Stimmt etwas nicht?
#769 1 Kommentar 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@lavaman131 arbeitet bereits daran.

Seit 05.11.2026.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
full-stack

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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?
Vorherrschende Sprache
TypeScript
Sterne
591
Forks
33
Ø Merge
4 Std. 13 Min.
Gemergte PRs (30 T.)
412

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus githubnext/chopin

Alle Issues in githubnext/chopin

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.