ldraney/palinks
1
0
Fork 0
Code Issues 12 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Spike: Define link visibility tiers and assign current links #17

New issue
Closed
opened 2026-06-07 15:23:50 +00:00 by ldraney · 2 comments
ldraney commented 2026-06-07 15:23:50 +00:00
Owner
Copy link

Type

Spike

Lineage

Related to ldraney/palinks #16 (Keycloak integration spike). Need to define what each audience tier sees before implementing role-based filtering.

Repo

ldraney/palinks

Question

Which links should be visible at each access tier, and how do we model the public (unauthenticated) tier?

  • Role model: The canonical model is superadmin + member (Keycloak roles) + anonymous (unauthenticated). This is confirmed in docs/visibility.md, docs/architecture.md, and project-palinks.
  • Public (anonymous): What does a stranger see when they land on palinks.app? Portfolio pieces? Contact info? Or just a login wall?
  • Member (authenticated): Which links are member-visible vs superadmin-only? What's the criteria for the split?
  • Superadmin (Lucas): Everything — but are there links that are only useful to Lucas (internal infra, dev tools) that members should never see?
  • Modeling "public": Public isn't a Keycloak role — it's the absence of auth. The Rails schema uses a visibility enum on links (public, member, superadmin) with hierarchical access. Confirm this approach.
  • Current inventory: Audit all current links on production palinks and assign each a proposed visibility tier.
  • Future link categories: As palinks becomes a portfolio, what new link types emerge? (case studies, project demos, contact, resume)

Deliverables

Required outputs:

  • docs/visibility.md completed — the file already exists with tier definitions, mermaid diagrams, and schema approach. Complete the "Current Link Inventory" table by auditing production links and assigning proposed visibility tiers.
  • Follow-up ticket for adding visibility column to links schema (if not already covered by #16)

Time-box

2 hours

Related

  • palinks — the service
  • ldraney/palinks #16 — Keycloak integration (depends on visibility model)
  • ldraney/palinks #19 — seed data (consumes tier definitions)
  • story:auth-roles — parent story
### Type Spike ### Lineage Related to `ldraney/palinks #16` (Keycloak integration spike). Need to define what each audience tier sees before implementing role-based filtering. ### Repo `ldraney/palinks` ### Question Which links should be visible at each access tier, and how do we model the public (unauthenticated) tier? - **Role model**: The canonical model is superadmin + member (Keycloak roles) + anonymous (unauthenticated). This is confirmed in `docs/visibility.md`, `docs/architecture.md`, and `project-palinks`. - **Public (anonymous)**: What does a stranger see when they land on palinks.app? Portfolio pieces? Contact info? Or just a login wall? - **Member (authenticated)**: Which links are member-visible vs superadmin-only? What's the criteria for the split? - **Superadmin (Lucas)**: Everything — but are there links that are *only* useful to Lucas (internal infra, dev tools) that members should never see? - **Modeling "public"**: Public isn't a Keycloak role — it's the absence of auth. The Rails schema uses a `visibility` enum on links (`public`, `member`, `superadmin`) with hierarchical access. Confirm this approach. - **Current inventory**: Audit all current links on production palinks and assign each a proposed visibility tier. - **Future link categories**: As palinks becomes a portfolio, what new link types emerge? (case studies, project demos, contact, resume) ### Deliverables Required outputs: - [ ] `docs/visibility.md` completed — the file already exists with tier definitions, mermaid diagrams, and schema approach. Complete the "Current Link Inventory" table by auditing production links and assigning proposed visibility tiers. - [ ] Follow-up ticket for adding `visibility` column to links schema (if not already covered by #16) ### Time-box 2 hours ### Related - `palinks` — the service - `ldraney/palinks #16` — Keycloak integration (depends on visibility model) - `ldraney/palinks #19` — seed data (consumes tier definitions) - `story:auth-roles` — parent story
ldraney commented 2026-06-07 15:32:11 +00:00
Author
Owner
Copy link

Scope Review: NEEDS_REFINEMENT

Review note: review-1379-2026-06-07

Template is complete and well-structured, but two categories of issues need attention before this moves to next_up.

Body fixes needed:

  • docs/visibility.md already exists with tiers and diagrams done -- issue should frame work as "complete the existing doc" (inventory is TODO), not "create from scratch"
  • Codebase has conflicting role models: docs/visibility.md uses 3 tiers (public/member/superadmin) while docs/architecture.md and docs/user-stories.md use 4 roles (public/lead/collaborator/admin). Add a sub-question to reconcile these.

Scope items (need human decision):

  • No project-palinks project page exists in pal-e-docs (user stories live in docs/user-stories.md in-repo)
  • No arch-palinks architecture note exists in pal-e-docs (architecture lives in docs/architecture.md in-repo)
## Scope Review: NEEDS_REFINEMENT Review note: `review-1379-2026-06-07` Template is complete and well-structured, but two categories of issues need attention before this moves to next_up. **Body fixes needed:** - `docs/visibility.md` already exists with tiers and diagrams done -- issue should frame work as "complete the existing doc" (inventory is TODO), not "create from scratch" - Codebase has conflicting role models: `docs/visibility.md` uses 3 tiers (public/member/superadmin) while `docs/architecture.md` and `docs/user-stories.md` use 4 roles (public/lead/collaborator/admin). Add a sub-question to reconcile these. **Scope items (need human decision):** - No `project-palinks` project page exists in pal-e-docs (user stories live in `docs/user-stories.md` in-repo) - No `arch-palinks` architecture note exists in pal-e-docs (architecture lives in `docs/architecture.md` in-repo)
ldraney commented 2026-06-07 15:47:29 +00:00
Author
Owner
Copy link

Scope Review: APPROVED

Review note: review-1379-2026-06-07-b

Re-review of all 4 previous findings — all resolved:

  • Role model consistent across canonical docs (architecture.md, visibility.md, project-palinks, arch-palinks)
  • Deliverable correctly reframed as "complete existing doc"
  • project-palinks and arch-palinks notes created in pal-e-docs with full traceability

Minor note: docs/user-stories.md still has descriptive "lead"/"collaborator" references in US-1 and US-9 prose — not role definitions, acceptable for now.

## Scope Review: APPROVED Review note: `review-1379-2026-06-07-b` Re-review of all 4 previous findings — all resolved: - Role model consistent across canonical docs (architecture.md, visibility.md, project-palinks, arch-palinks) - Deliverable correctly reframed as "complete existing doc" - `project-palinks` and `arch-palinks` notes created in pal-e-docs with full traceability Minor note: `docs/user-stories.md` still has descriptive "lead"/"collaborator" references in US-1 and US-9 prose — not role definitions, acceptable for now.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
40-canvas-view-activity-sizing
28-custom-domain-reverse-proxy
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ldraney/palinks#17
No description provided.