decision(workspaces): choose where project profile data belongs

Đang mở
  • Có gì không ổn?
#412 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
12/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
nextjs, postgresql, supabase, typescript
Lĩnh vực
backend, database

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
TypeScript
Star
1
Fork
1
Merge trung bình
6 giờ 56 phút
Pull request đã merge (30 ngày)
136

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của eddiejaoude/StackDash

Tất cả issue của eddiejaoude/StackDash

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.