decision(workspaces): choose where project profile data belongs

オープン
  • 何か問題がありますか？
#412 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
12/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
nextjs, postgresql, supabase, typescript
領域
backend, database

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
TypeScript
スター
1
フォーク
1
平均マージ
6時間 56分
マージ済み PR（30日）
136

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

eddiejaoude/StackDash のほかの issue

eddiejaoude/StackDash の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。