Skip to content

Seeker "My Profile" cannot deep-link to the own ats_candidate record: nav recordId resolves only {current_user_id} / {current_org_id} #34

Description

@claude

Observation from #3 (card 08), where the seeker navigation gained its My Profile entry.

What the shell offers

An object nav item opens a record directly only through recordId, and the shell substitutes exactly two template variables — {current_user_id} and {current_org_id} (@objectstack/spec ObjectNavItemSchema, objectui resolveHref). A candidate row's id is not the user's id (ats_candidate.user is a lookup to sys_user), so recordId: '{current_user_id}' would 404.

What #3 shipped instead

filters: { user: '{current_user_id}' } — a one-row slice on the bare data surface; the record (and the profile form) is one click further. Measured: resolves to ?filter[user]=THE_USER_ID, 1 row when the signed-in user owns a candidate row, 0 rows otherwise (docs/evidence/issue-3/13-seeker-my-profile-slice.png).

What would close the gap

Either an upstream nav feature (a predicate-resolved record target, e.g. recordId by a field match, or a me sentinel the shell resolves through the object's user field), or — cheaper and local — a stored link from the user to their candidate row so a template variable can address it. Both are product decisions beyond a views card; recording the gap so it is not mistaken for a missing view.


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions