decision(workspaces): choose where project profile data belongs

Abierto
  • ¿Algo no está bien?
#412 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
12/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
nextjs, postgresql, supabase, typescript
Área
backend, database

Línea de trabajo

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.

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

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
1
Forks
1
Merge medio
6 h 56 min
PR fusionados (30 d)
136

Preparar el entorno

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 eddiejaoude/StackDash

Todos los issues de eddiejaoude/StackDash

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.