feat(view-settings): seed client view defaults for new clients (OUT-3851 soft default)

[priosshrsth]

What & why

PR3 of OUT-3851 — the soft default behavior. Builds on the foundation PR (#1308) and targets that branch.

When a client user gets their first ViewSettings row, seed viewMode / showSubtasks from the workspace-level client defaults (when set), instead of the hardcoded board / showSubtasks: true. The client keeps full control afterward.

How

viewSettings.service.ts only:

• New getClientViewDefaults() — for a client user, returns the workspace clientDefaultViewMode / clientShowSubtasks; null for IUs.
• createInitialViewSettings uses those values with fallback to the existing hardcoded defaults.

Scope notes

• Seeding runs only when no row exists for the user → new client users only. Existing clients (already have a row) and IUs are unaffected.
• Lock flags are irrelevant here — only the default values matter for seeding. Enforcement against existing clients is PR2's job.

Testing

• yarn tsc clean for the changed file, eslint 0 errors, prettier clean.

🤖 Generated with Claude Code

[linear-code]

OUT-3851

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
tasks-app	Ready	Preview, Comment	Jun 10, 2026 11:22am

[greptile-apps]

Greptile Summary

This PR adds workspace-level client default seeding for new client users' first ViewSettings row, pulling clientDefaultViewMode and clientShowSubtasks from the workspace settings when available, and falling back to the existing hardcoded defaults via null-coalescing.

• New getClientViewDefaults() fetches workspace settings once per initial-creation call; returns null for IUs and when no workspace setting row exists, so IU behavior and existing client behavior are unchanged.
• createInitialViewSettings now uses clientDefaults?.viewMode ?? DEFAULT_VIEW_MODE and clientDefaults?.showSubtasks ?? true, correctly handling both the case where workspace defaults are absent and the case where individual fields are null.
• Pre-existing: createOrUpdateViewSettings discards the caller's submitted data on the first-creation path (comment on line 62 says "with provided data" but it never passes through), which becomes more noticeable now that seeded values replace hardcoded ones.

Confidence Score: 4/5

Safe to merge — the seeding logic is self-contained and only fires for new client users with no existing row.

The new getClientViewDefaults method is small and well-scoped: the IU short-circuit is consistent with the rest of the service, null-coalescing fallbacks are correct for both absent workspace settings and unset individual fields, and the extra DB query is bounded to first-time creation only. The one concern is a pre-existing quirk in createOrUpdateViewSettings where submitted data is silently dropped on the initial-creation path — now that seeded values fill that path instead of hardcoded ones, this discrepancy between the comment and the implementation is more visible to future readers.

Only viewSettings.service.ts changed; the createOrUpdateViewSettings initial-creation path is worth a second look.

Important Files Changed

Filename	Overview
src/app/api/view-settings/viewSettings.service.ts	Adds getClientViewDefaults() to seed new client view settings from workspace-level defaults; seeding logic and null-coalescing fallbacks are correct. Pre-existing issue: createOrUpdateViewSettings discards the caller's data on the initial-creation path, which the new seeding makes more visible.

Sequence Diagram

sequenceDiagram
    participant Client as Client User
    participant SVC as ViewSettingsService
    participant DB as Database

    Client->>SVC: getViewSettingsForUser()
    SVC->>DB: viewSetting.findFirst(userIds)
    DB-->>SVC: null (no row yet)
    SVC->>SVC: createInitialViewSettings(userIds)
    SVC->>SVC: getClientViewDefaults()
    SVC->>DB: workspaceSetting.findUnique(workspaceId)
    DB-->>SVC: workspaceSetting (or null)
    Note over SVC: clientDefaultViewMode ?? DEFAULT_VIEW_MODE
    Note over SVC: clientShowSubtasks ?? true
    SVC->>DB: viewSetting.create(data)
    DB-->>SVC: new ViewSetting (seeded)
    SVC-->>Client: ViewSetting

    Note over SVC: IU path: getClientViewDefaults() returns null immediately
    Note over SVC: hardcoded defaults used (internalUserId check short-circuits)

Loading

Comments Outside Diff (1)

1. src/app/api/view-settings/viewSettings.service.ts, line 62-68 (link)

   Initial data silently dropped on first createOrUpdate call

   When a client user's first interaction is a PATCH/PUT to the view-settings endpoint (rather than a GET), createOrUpdateViewSettings creates the initial record via createInitialViewSettings(parsedUserIds) and completely discards the data the user submitted. The inline comment on line 62 even says "with provided data", but the implementation never passes it through. With this PR the user's explicit choice is now overwritten by the workspace-seeded defaults instead of hardcoded defaults — the impact is the same, but the mismatch between comment and code is now more visible. If this code path is reachable from the frontend's first save action, the user's explicit selection will silently be reset to the seeded value.

_{Reviews (1): Last reviewed commit: "feat(view-settings): seed client view de..." | Re-trigger Greptile}

[vercel]

Deployment failed with the following error:

Deploying Serverless Functions to multiple regions is restricted to the Pro and Enterprise plans.

Learn More: https://vercel.link/multiple-function-regions