A draft's link tells visitors to ask for an updated link, and tells its own organizer the same
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 56/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- next.js, typescript
- Lĩnh vực
- authentication, backend-api-design, frontend
Hướng nghiên cứu
Start with the draft branch in src/app/s/[slug]/page.tsx, then read getOrganizerSession in src/auth/session.ts and the workspace access checks in src/services/signups.ts. Trace the existing SignupStateMessage and draft Build link patterns before adding the guarded lookup. Verify visitor, workspace member, and other workspace views, add the requested DB cases, and run the listed checks; pnpm build should still show /s/[slug] as dynamic.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Needs your OK: this changes what a draft's public link says. Visitors get new words, and a signed-in organizer who can open the draft gets a note and a link back to it. Swap pipeline:proposed for pipeline:ready to have it built.
What happens
Opening a draft's public link shows the received === 'draft' branch of PublicSignupPage in src/app/s/[slug]/page.tsx:
This signup isn’t ready yet
The organizer hasn’t published this signup yet. Check back soon or ask them for an updated link.
- "Ask them for an updated link" is wrong.
createSignupsets the slug once, and publishing changes only the status. The same link works as soon as the signup is published. A visitor who asks for a new link gets the same one back. An organizer who is asked may think the link they sent is broken. - The organizer gets the visitor's message too. The page never reads the organizer's session. An organizer who opens their own draft's link sees "ask them for an updated link", with nothing to say it's their draft, that people can't see it yet, or where to publish it.
#578 takes the public link out of a draft's header, so organizers will reach this page less often. They still get the link in other ways: as links.public from the AI connector tools, from Magic Compose and from the API, or as a link they copied earlier.
To see it: on a fresh local instance, create a signup by hand and don't publish it. Open /s/<its slug> in a private window, then in the window where you're signed in. Both show the visitor message.
Fix, in outline
- Visitors: keep the title. Change the body to say the link will work once the signup is published (wording under "Choices this makes").
- Organizers: in the draft branch only, read the session with
getOrganizerSession(src/auth/session.ts). If there is one, call a new guarded read insrc/services/signups.ts, sayfindDraftForOrganizer(db, actor, slug). It finds the live draft by slug, callsrequireWorkspaceAccess(actor, row.workspaceId), and returns only the id. Treat aforbiddenas not found. - When it finds the draft, render
SignupStateMessagewith the organizer's words and anactionlink to/app/signups/<id>/build. - Otherwise, show the visitor message.
Watch for
- Read the session only in the draft branch. An open or closed signup's page must not call
auth()or depend on an organizer session. Participants aren't users, and that page is their hot path. - Don't put the id in
getPublicSignup's error.GET /api/public/signups/[slug]sends that error back unchanged, so an id in itsdetailswould reach anyone who asks. Keep the organizer lookup as its own guarded read. - Policy. The new read calls
requireWorkspaceAccessbefore it returns anything. A signed-in organizer from another workspace sees the visitor message. - Caching. The page already reads cookies for returning participants and renders per request. Check that
pnpm buildstill lists/s/[slug]as dynamic (ƒ). - No new cookie or stored data. The cookies page already says the Auth.js session cookie "keeps organizers signed in". Check that it still reads true. The privacy and terms pages need no change.
- Overlap with #578. It removes the help article's "Until you publish, it only says the signup isn't ready." and the draft-link check in
tests/e2e/help/create-and-publish-a-signup.spec.ts, which matches/isn.t ready yet/. Whichever lands second merges. - The AI connector texts.
src/mcp/instructions.tsand thecreate_signupdescription insrc/mcp/tools/signups-write.tssaylinks.public"only says the signup is not ready yet". That stays true for visitors. - The archived message ("ask for a new link") is a separate case and stays as it is.
- CHANGELOG entry.
Choices this makes
- The visitor's words: "The organizer hasn’t published it yet. This link will work once they do, so check back later." Default: these words. They drop the request for a new link and say what's true.
- The organizer's words: title "Only you can see this draft". Body: "People who open this link see “This signup isn’t ready yet” until you publish it. The link stays the same." Link: "Open your draft". Default: these words. The title matches the draft header's line in #578.
- Who gets the organizer note: any member of the signup's workspace, viewers included. Default: any member (
requireWorkspaceAccess, notrequireWorkspaceWrite). A viewer can still open the draft, and Publish already tells a viewer "You don’t have edit access." - Where the link goes: the Build tab, where Publish is. Default: Build. The preview page has no Publish button.
- A line for everyone instead of reading the session ("Made this signup? Sign in to publish it."): Default: no. It shows organizer instructions to every visitor, and still doesn't tell the organizer that this is their draft.
Done when
- A signed-out visitor who opens a draft's link sees the new words, with no request for an updated link.
- A signed-in member of the signup's workspace sees the organizer note, with a link to the draft's Build tab.
- A signed-in organizer from another workspace sees the visitor message.
- An open signup's page reads no session: the session is read only in the draft branch.
- A DB test covers the new read for a member, a non-member, a published signup and a deleted draft.
pnpm lint && pnpm typecheck && pnpm knip && pnpm testandpnpm test:dbpass.
Found by the UX walkthrough (scenario O1) on 2026-10-24, and checked against the code on main at 4ed27a9.
Generated by Claude Code
- Ngôn ngữ chính
- TypeScript
- Star
- 19
- Fork
- 4
- Merge trung bình
- 19 giờ 34 phút
- Pull request đã merge (30 ngày)
- 165
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của richshaw/OpenSignup
-
enhancement pipeline:proposed pipeline:ux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
richshaw/OpenSignup#654 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
The help pages never say "pause", so organizers looking for it miss Close or reopen a signupĐang mởenhancement pipeline:proposed pipeline:ux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
richshaw/OpenSignup#653 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement pipeline:proposed pipeline:ux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
richshaw/OpenSignup#652 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
SMTP timeout notes in smtp.ts and the changelog describe nodemailer 10.0, not 10.1Có thể đã có người làm @agammann đã nhận 1 ngày trước. Đang mởenhancement good first issue pipeline:ready
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
richshaw/OpenSignup#645 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
A signup page's first Tab skips the header and lands on the next tabCó thể đã có người làm @richshaw đã nhận hôm nay. Đang mởbug good first issue pipeline:building pipeline:ux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
richshaw/OpenSignup#644 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của richshaw/OpenSignup
Issue tương tự
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
ajv-validator/ajv#2689 ·
-
[Bug]: IME confirmation Enter can submit the SSH port-forward dialogCó thể đã có người làm @seijikohara đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
home-assistant/frontend#55323 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
lingdojo/kana-dojo#33188 · 1 bình luận · 5 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
self-driving
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày