decision(workspaces): choose where project profile data belongs

未关闭
  • 哪里不对？
#412 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
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 分钟
30 天内合并 PR
136

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

eddiejaoude/StackDash 的其他 Issue

查看 eddiejaoude/StackDash 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。