MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-418

6.12.10 E2E (playwright) — anyone reads a public project LOGGED OUT (+ SEO surface), then signs in to submit (dedupe → upvote) + comment; a non-public project is not viewable

Done
Description

Estimate: 55m · Depends on: 6.12.4, 6.12.7, 6.12.8, 6.12.11, 6.12.12

Type: e2e (playwright) — the full cross-org public-project loop in a browser, proving the access exception + the portal set end to end with a SECOND Motir account in a DIFFERENT org.

The flow:

  1. As the motir project admin, set the project public in project settings (6.12.8) and copy the shareable public link.
  2. LOGGED OUT (no session), open the public link → the read-only board / work item list + the public roadmap render with NO sign-in; assert there are NO edit affordances, that assignees / estimates / internal comments are absent, that the page exposes the SEO surface (a single <h1> + a JSON-LD application/ld+json script), and that a write control (upvote / submit / comment) shows a sign-in-to-act prompt.
  3. Sign in as a SECOND, seeded Motir account in a DIFFERENT org with NO membership in the public project’s org/workspace (proving cross-org act works once signed in). Submit a feature request whose title matches an EXISTING public request → the duplicate-detection surfaces the existing one → choose "upvote this instead" → the vote count increments and NO duplicate is created. Then add a comment on that public request → it appears.
  4. Submit a genuinely-NEW request → it lands in the project’s triage queue (verify as the admin it appears there, attributed to the second account, and is absent from the normal tree until promoted).
  5. Confirm the cross-org EXCLUSION: the same second account navigating to a NON-public project of that org is NOT able to view it (404-not-403) — proving public is the only cross-org read exception.

Mind the prodect e2e selector + harness gotchas (combobox option = label + secondary; exact/level on heading selectors; the empty-state headings; run the dev server yourself + reuse it). Drive the real UI, not API shortcuts; use a second browser context for the second account.

Acceptance criteria

  • A LOGGED-OUT visitor opens the public project read-only: board / work items / roadmap render with no sign-in, no edit affordances, internal fields (assignee / estimate / internal comments) absent, the SEO surface (single <h1> + JSON-LD) present, and the write controls show a sign-in-to-act prompt.
  • Submitting a matching-title request surfaces the dedupe and the "upvote this instead" path (vote increments, no duplicate); a comment on the request appears; a genuinely-new request lands in the admin’s triage queue attributed to the second account, absent from the tree.
  • The second account CANNOT view a non-public project of that org (404-not-403) — public is the only cross-org read exception.
  • The test drives the real UI (no API-only shortcuts), uses a second browser context, and follows the prodect E2E selector + run-harness conventions.

Context refs

  • 6.12.4 (the public view) + 6.12.8 (the make-public toggle + share link) — the surfaces driven; 6.12.5/6.12.6/6.12.7 (submit/dedupe/upvote/comment/roadmap) exercised through them.
  • scripts/plan-seed/data/story-6.11.ts § 6.11.9 — the triage e2e whose harness + the promote-from-queue step this builds on.
  • motir-core/e2e/ — the existing Playwright specs + the run-harness + selector conventions to mirror.