decision(workspaces): choose where project profile data belongs

Aperta
  • Qualcosa non va?
#412 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
nextjs, postgresql, supabase, typescript
Ambito
backend, database

Direzione di ricerca

Start by reading docs/architecture/concepts.md:54-65 to see how project, workspace and provider accounts are defined, then the migration files named in the body (supabase/migrations/20261031090100_integrations.sql, 20261105120500_project_pages.sql, 20261111090000_workspace_handles.sql) to see what each table currently owns. Follow the public exposure path through src/lib/data/projects.ts and src/app/p/[workspace]/[slug]/page.tsx and confirm how public_project_page() gates visibility, since any logo route must reuse that predicate. Done means a recorded decision with rationale in the architecture docs; the upload, Storage policies and UI are separate follow-up work and out of scope here.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: workspaces decision enhancement priority: P2 size: XS

Context

A DevMacro project is a user-created grouping of external accounts, usually one product (docs/architecture/concepts.md:54-65). It currently owns only name plus audit timestamps (supabase/migrations/20261031090100_integrations.sql:13-24). Its public page exposes that name and generated metric copy only (supabase/migrations/20261111090000_workspace_handles.sql:129-156, src/app/p/[workspace]/[slug]/page.tsx:59-105).

The request is to add a description and logo without confusing three different identities:

  • the DevMacro project or product
  • the workspace that owns the public @handle
  • provider-owned external accounts, including GitLab namespaces

BackTalk's current HEAD contains no tenancy migrations or workspace, organization, team, or profile implementation, so it has no current pattern to reuse for this choice.

Options

Option Pros Cons Effort Impact
Keep the status quo No new upload, storage, authorization, or cleanup path. project_pages remains publication settings only. Public pages still have only the project name and generated metric copy. The Projects list still shows only name and account count (src/lib/data/projects.ts:19-80). XS Project owners cannot explain or visually identify a product. No data or privacy risk is added.
Store profile fields on projects, with the image object in private Storage The description and logo belong to the product represented by the project. One canonical profile works in the Projects list and public page. Existing project_pages.enabled remains the publication boundary. Requires upload validation, private Storage policy, object replacement cleanup, and expansion of the public page function. M Owners get one profile everywhere. A faulty public image route could reveal a private project's identity, so it must use the existing public page predicate.
Store profile fields on project_pages Keeps all public presentation fields beside slug, enabled, and indexable (supabase/migrations/20261105120500_project_pages.sql:17-32). Makes the profile unavailable to internal project surfaces and treats product identity as page configuration. A page row can exist while disabled, so it does not itself guarantee publication. M Public visitors get richer pages, but members still see sparse projects and later internal use would duplicate fields.
Store branding on workspaces One upload can identify the owner of every @handle. It fits a future workspace profile. A workspace can own several projects. Reusing one workspace logo as every product logo misidentifies them. It also risks calling provider namespaces a DevMacro namespace. S Every public project page gets the same owner branding, even when products have distinct identities. No product description is modeled.
Add a polymorphic profiles or assets table Can attach future profiles and multiple assets to projects and workspaces. Adds entity type checks, joins, RLS, and shared UI before there is a second proven profile shape. It duplicates a simple one-to-one relation. L Flexible for hypothetical branding. More authorization and consistency paths can fail for every current project owner.

Files by option

Option Expected files and objects
Keep the status quo None
projects fields New migration for projects, a private Storage bucket and policies; src/app/w/[workspace]/projects/actions.ts; project forms and list; src/lib/data/projects.ts; public page SQL/data/rendering; generated database types; architecture docs; focused database, action, and e2e coverage
project_pages fields New migration for project_pages and Storage; public metrics page settings actions/forms; public page SQL/data/rendering; generated database types; public metrics docs and focused coverage
workspaces fields New migration for workspaces and Storage; workspace settings actions/forms; public page SQL/data/rendering; generated database types; workspace docs and focused coverage
Polymorphic table New profile/assets tables, RLS and Storage policies; shared data and mutation layer; project and workspace UI; public page SQL/data/rendering; generated database types; architecture docs and broader coverage

Recommendation

Choose projects fields. The deciding fact is that DevMacro defines a project as the product-level grouping across providers, while the workspace is the tenant and project_pages controls publication. Keep those responsibilities separate.

Store plain text on the project and store only a versioned object path in Postgres, for example:

projects.description       nullable bounded plain text
projects.logo_object_path  nullable Storage object path
project-assets/<workspace_id>/<project_id>/logo/<version>.<ext>

Use a private bucket. Uploads must validate content type by bytes, dimensions, and size. The public logo route must return an image only when the existing public project page predicate succeeds. Do not store image bytes, base64, or an arbitrary external URL in projects. Do not copy provider avatars into this field.

A workspace logo ranks second, but only as a separate owner identity for a future workspace profile or namespace landing page. It must not be the fallback project logo. Use a generated project initial or neutral placeholder when a project has no logo.

Plan

  1. Record the ownership decision.
  2. If approved, open a separate implementation issue with exact limits, image formats, Storage policies, UI surfaces, and migration steps.

Acceptance criteria

  • The chosen owner of project description and logo data is recorded with rationale.
  • Public exposure remains controlled by the existing project page predicate.
  • Implementation is tracked separately after the decision.
  • No Playwright coverage is needed for this decision-only issue.

Files and areas

In scope: project, workspace, public page, and Storage ownership boundaries.

Non-goals: implementing uploads, adding a workspace profile, copying provider metadata, or changing public page behavior in this issue.

Verification

Review the chosen model against docs/architecture/concepts.md, projects, project_pages, and public_project_page() before implementation begins.

Branch: not applicable for a decision-only issue.
Implementation work closes its own issue with a Closes #<issue-number> footer.

Model: openai-codex/gpt-5.6-sol | Reasoning effort: high

Lingua principale
TypeScript
Stelle
1
Fork
1
Merge medio
6h 56m
PR unite (30g)
136

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eddiejaoude/StackDash

Tutte le issue di eddiejaoude/StackDash

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.