A sales rep's record History tab is empty: no permission set grants sys_audit_log read (measure field-level safety first)

Filing gate: ① product defect with reach measured. Class (a), user-visible. reach: REST GET /api/v1/data/sys_audit_log as a sales rep, and the record History tab. Measured on hotcrm ac162c9b (@objectstack/* 17.7.0) by the dev of #2029 (report 6083534286), session session_018Mk4tab2eCyY41UTWK7y7V, on a fresh dev box with pnpm demo:staff.

Who acts on it: the repo:hotcrm seat dispatches it, measuring first. It is the same class as #2029 item 5 (a rep refused a record's collaboration surface), kept out of PR #2043 because the safety question below needs its own measurement. ⛔ Not a claim.

What is measured

As na.rep, GET /api/v1/data/sys_audit_log → 403 PERMISSION_DENIED, before and after PR fix(profiles, docs): reps read and join the Discussion of records they can read; the expiry and renewal sweeps run where scheduled work is on; the automation page names the shipped templates (#2029 items 3, 5, 6) #2043. No app permission set names sys_audit_log, and the member baseline does not either.
With a temporary read grant (measurement only, never committed), the rows narrowed to readable parents: a readable contract returned 2 rows, an unreadable one 0.
Contradicts: the record History tab on trackHistory objects (for example crm_contract, whose docs page says the audit log records who moved Status) has nothing to show a rep, and content/docs/administration/automation.mdx Tips for users tells users to check the audit log. The console's history fetch turns the refusal into an empty list (objectui RecordDetailView, source read, NOT browser-measured).

⚠️ The safety question that decides the fix (measure FIRST)

hotcrm restricts fields per permission set; for example sales_rep cannot read crm_case.internal_notes. An audit row carries old and new field values. A read grant is safe only if the platform also applies field-level security to those values.

Measure: as a rep with the temporary grant, read the audit rows of a record they can read where a field they CANNOT read changed. If the hidden field's values are served, that is a platform security defect: ⛔ do not grant; file it upstream and this card WAITS (AGENTS.md §2).
If they are not served, grant sys_audit_log read (no create, edit or delete) in the sets that grant sys_comment, pin it, and browser-check the History tab as a rep.

Acceptance

A rep's History tab shows the history of the records they can read, with no field they cannot read; or an upstream card this one waits on. pnpm verify is green.

Duplicate check

/search is refused in this container; every hotcrm issue and PR was listed (/issues?state=all, 1,878 items up to #2041) and matched case-insensitively: sys_audit_log 6 (all closed: upgrades and docs measurements), History tab 0, audit log 13 (#2014 open, about hooks; the rest closed docs and upgrades). None is a duplicate.

Dedupe words: sys_audit_log PERMISSION_DENIED rep · History tab empty rep · audit log grant permission set · audit field-level security

Generated by Claude Code

Serial note: this card dispatches after PR #2043 (#2029) lands. repo:hotcrm seat, session_018Mk4tab2eCyY41UTWK7y7V, 2026-10-09T15:23Z. ⛔ Not a claim; the card stays pm:queue.

Why: both cards add grant entries to the same five src/sales/profiles/*.profile.ts (sales_rep, sales_manager, marketing_user, service_agent, system_admin), next to each other: #2043 adds sys_comment and sys_activity; a sys_audit_log read grant from this card would sit beside them. Started from main once #2043 is in, this card's dev also inherits #2043's record-comments-access test shape.

Known pitfall, for the dispatch: the field-level-security question in the body decides whether any grant lands at all. Measure it before writing a profile line.

Generated by Claude Code

Claim: PM loop round R76
Session: session_018Mk4tab2eCyY41UTWK7y7V
Account: zhuangjianguo (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-2044-rep-audit-history
Worktree: hotcrm-issue-2044
Domain: repo:hotcrm (single-lane repo, no domain:* taxonomy)
Seat: repo:hotcrm#1
File surface: src/sales/profiles/{sales-rep,sales-manager,marketing-user,service-agent,system-admin}.profile.ts (a sys_audit_log read entry, ONLY if the field-level measurement in the body is safe); the canonical note beside enable.feeds / enable.files in src/sales/objects/index.ts; their tests; one .changeset/2044-*.md (stop on breach; explain in the report)
Container & model: M, mode:subagent (the os-dev definition and the scripts/pm write tools live in this container's objectstack checkout), model: default (dispatch-gates --tier --repo objectstack-ai/hotcrm answers "The tier stays the PM's per-card judgment call"; no declared tier glob is hit; a permission grant measured against field-level security is a judgment, not the floor tier)
Clause-②: no
Responsibility: the app's permission sets (no set grants sys_audit_log) | the platform's audit-read gate, which must also apply field-level security; if it does not, that is the platform's and hotcrm WAITS | every rep, manager, marketer and agent opening a record's History tab
Thread-read: 6083906103
Serial constraints cleared: #2043 (#2029), which this card waited on (6083906103), landed as c12a251; this branch starts from it. #2042 is in flight on account_detail.page.ts, the account seeds and the accounts docs: disjoint files. No open PR in the repo.

Generated by Claude Code

os-dev-report

{
  "issue": 2044,
  "status": "needs_decision",
  "branch": "claude/issue-2044-rep-audit-history",
  "pr": null,
  "session": "session_018Mk4tab2eCyY41UTWK7y7V (subagent: the parent's id, from this run's Claude-Session attribution line)",
  "premise_still_valid": false,
  "summary": "The security stop does NOT fire: on 17.7.0 the platform applies field-level security to sys_audit_log rows, measured with a temporary sales_rep read grant that was never committed (crm_case.internal_notes, readable: false for sales_rep, is recorded in the ledger and is never served to the rep, by list, query or findOne; filtering, sorting and searching on old_value/new_value are refused 403; readable contract 2 of 2 rows, unreadable 0 of 2). The card's premise is FALSE: the record History tab neither is empty for a rep nor reads sys_audit_log in this app. The only History tab hotcrm renders is lead_detail's authored record:history, and it self-fetches sys_activity, which #2043 granted: in the browser as na.rep it shows 4 entries, with zero sys_audit_log requests, and the same with and without the grant. Default record pages (crm_contract, the card's example) show no History tab for anyone, admin included, because no hotcrm object declares enable.trackHistory (served metadata: trackHistory false), and objectui RecordDetailView fetches the ledger only behind that flag. The grant therefore changes no surface a rep can navigate to (REST/MCP, plus the Setup Audit Log page reached only by typing its URL, since the Setup app is not in the rep's app list) and, by the platform's documented contract, also serves every rep the ledger rows that name no record (measured: a seeded run-level import row and a platform_admin_standing_change row with a platform admin's email). Landing it anyway is a product call the PM's fixed constraint did not foresee, so no profile line, no PR; the decision is in open_questions.",
  "tests": "NO CODE CHANGE, so pnpm verify: NOT MEASURED, reason: no diff and no PR (the coordinator's main move to f6d2379, PR #2045, needs no merge: nothing is committed on the branch, which is still at c12a251). Measurement runs, all on c12a251 with @objectstack/* 17.7.0: (1) premise greps: `git grep -n sys_audit_log -- src/sales/profiles` exit 1, 0 lines; control `git grep -c 'sys_comment:' -- src/sales/profiles` exit 0, 1 hit in each of the five files; `git grep -n 'readable: false' -- src` 1 hit (crm_case.internal_notes, sales-rep.profile.ts:125). (2) In-process probe (verify stack, test/helpers/verify-stack.ts boot with AuditPlugin) with a TEMPORARY sales_rep line `sys_audit_log: read only`, three runs, each `os-verify-lock: VERDICT command-exit 0` (held 15s, 17s, 16s). Positive control: the system read of case A's 3 ledger rows carries SECRETNOTE_ALPHA/BRAVO/CHARLIE in new_value/old_value (create snapshot plus update diffs; the ledger records every field, tracked or not, so no throwaway trackHistory edit was needed). The rep reads case A (own) with no internal_notes key, and case B 0 rows. As the rep: GET /data/sys_audit_log 200, 63 rows, body contains no SECRETNOTE; POST query object_name+record_id=A 200, 3 rows, create new_value has every field except internal_notes, mixed update old {status:new} new {status:in_progress}, hidden-only update old {} new {}; case B 200 with 0 rows; GET /data/sys_audit_log/ID of A's create row 200, no secret; B's row 404 RECORD_NOT_FOUND; filter new_value contains SECRETNOTE_ALPHA 403 PERMISSION_DENIED, pinned to crm_case and unpinned; query search SECRETNOTE_ALPHA 403 PERMISSION_DENIED (the no-match control also 403; the admin's same search 200 with n=2, so search does reach the value columns); sort by new_value 403 PERMISSION_DENIED. Contract narrowing re-measured: the rep reads contractR 1, contractU 0; ledger rows readable 2 of 2 vs 0 of 2. History-tab data path (sys_activity, no ledger grant involved): system 3 rows containing the secret, rep 2 rows, no secret. Rows about no record: a seeded run-level import row and a platform_admin_standing_change row are served to the rep (200, n=2, admin email visible; untenanted verify boot, org scope not exercised). Restoring the probe: `git checkout HEAD -- src/sales/profiles/sales-rep.profile.ts`, `git diff HEAD` 0 bytes, marker count 0, blob 6452b1ae equals the HEAD blob; probe file removed (copy kept in scratchpad). (3) Dev box: `objectstack dev -p 4044`, fresh DB, `pnpm demo:staff` exit 0. As na.rep, GET /api/v1/data/sys_audit_log 403 PERMISSION_DENIED on the clean tree (twice); with the temporary grant 200, 202 rows of the admin's 561; the admin's 561 contain zero rows without record_id on this box; the rep's sys_session rows are all their own. Served /api/v1/meta/objects enable.trackHistory = false on crm_contract, crm_lead, crm_opportunity, crm_case, crm_account. /api/v1/meta/apps as the rep: crm_enterprise, account (admin: plus setup). (4) Browser (Chromium /opt/pw-browsers/chromium, headless): lead GC0fXXlxT0DHMMPR created by na.rep, status New to Contacted, rating 1 to 4; contract CTR-0001. Lead page tabs Details/Related/Activity/History for admin and na.rep; the History click requests only sys_activity (filtered to object_name+record_id, 200, n=4) and crm_lead, zero sys_audit_log requests on load and click, identical before and with the grant; panel: 4 entries, each 'Unknown user'. Contract page tabs Details/Attachments for both personas, no History tab, before and with the grant. URL-typed /_console/system/audit-log, which redirects to /_console/apps/setup/system/audit-log, shows the rep on the clean tree 'HTTP 403 ... PERMISSION_DENIED ... No audit entries', and with the grant 51 rows. Source read: console RecordDetailView gates both the History tab and its ledger fetch on enable.trackHistory === true; the spec's enable.trackHistory defaults false ('Show the record History tab'); objectui record-history.tsx self-fetches sys_activity and maps user_name from actor_name.",
  "mcp_calls": "0",
  "api_writes": "1: POST /repos/objectstack-ai/hotcrm/issues/2044/comments (this os-dev-report, via scripts/pm/post-stamped.mjs). Also git push of the empty branch claude/issue-2044-rep-audit-history at c12a251 (the write probe; it is still on the remote, no commits beyond main). REST reads: GET issues/2044 and its comments. No pr_create and no label-write: no PR.",
  "open_questions": [
    {
      "question": "The FLS security stop is cleared (measured), but the History-tab premise behind the PM's fixed constraint ('grant if safe') is false: no surface a rep can navigate to reads sys_audit_log. Should the five sets still get sys_audit_log read?",
      "options": [
        "A. Close #2044 with no grant, and reword content/docs/administration/automation.mdx:166 ('Tips for users: Check the audit log') to point users at the record's History and Activity tabs (a docs card). Business need (measured): the History tab already serves reps through sys_activity since #2043; no navigable rep surface reads the ledger. Long-term: no workaround, and permission sets stay minimal; the ledger stays an admin/auditor surface, as the platform's view_all_audit_log capability frames it. AI-error axis: grants no capability that nothing consumes, and the docs stop promising a surface users do not have. Startup axis: zero expansion. Cost: a rep's REST/MCP ledger read stays 403, and an agent acting for a rep answers 'who changed X' from sys_activity (tracked-field summaries) rather than the ledger.",
        "B. Land the read-only grant in sales_rep, sales_manager, marketing_user, service_agent and system_admin (service_manager and tenant_admin inherit), with pins (a readable parent lists its rows, an unreadable parent none, crm_case.internal_notes never served, filter/search on the value columns refused). Business need: REST/MCP/agent ledger read and the URL-only Setup Audit Log page; nothing navigable changes, and the History tab is unchanged. Long-term: it uses the reader gates the platform built for ordinary readers (#21175 parent gate, field redaction, predicate guard), so it is not a workaround, but every rep also receives the ledger rows that name no record (run-level import, config_change key plus digest, platform_admin_standing_change with platform-admin emails; measured on the verify boot). AI-error axis: neutral. Startup axis: expands a surface with no measured pull.",
        "C. B plus `enable.trackHistory: true` on the objects whose docs promise history (crm_contract and others), so default record pages render a ledger-backed History tab. A new card outside #2044's file surface (object files). It duplicates the tracked-field summaries the Activity timeline already shows, and it doubles the surface."
      ],
      "recommendation": "A, on all four axes: the need the card named is already met (the History tab works for reps through sys_activity, browser-measured), the grant has no navigable consumer, and it widens every rep to the ledger's rows that name no record, which the security stop never weighed. If the maintainer wants reps to read the ledger anyway, B is safe on field-level security as measured here, and the probe in this report is the pin to carry."
    }
  ],
  "out_of_scope_findings": [
    "class: a · reach: browser, the lead record page History tab (/_console/apps/app.objectstack.hotcrm/crm_lead/record/ID): admin and na.rep both see 'Unknown user' on all 4 entries, while every sys_activity row carries actor_id (the rep's id) · evidence: sys_activity declares actor_name (objectstack packages/plugins/plugin-audit/src/objects/sys-activity.object.ts:148, in its highlightFields); the audit writer's activity row writes actor_id and never actor_name (0 hits for actor_name in plugin-audit/src/audit-writers.ts on objectstack main 35ef501; same on the installed 17.7.0 dist); objectui packages/plugin-detail/src/renderers/record-history.tsx:195 maps user_name from r.actor_name (objectui main 7282c6a). Seam: spec:sys_activity.actor_name → runtime:plugin-audit audit-writers activity row | renderer:objectui record-history.tsx. The same read at recordActivityFeed.ts:773 (actor_name, falling back to a system label) is not measured. The producer is upstream; hotcrm does not fix it (AGENTS.md §2) · dedupe words: record history Unknown user · sys_activity actor_name never written · record:history actor name · activity actor_name null",
    "class: a · reach: a rep following content/docs/administration/automation.mdx:166 ('Tips for users: 1. Check the audit log') gets REST GET /api/v1/data/sys_audit_log 403 PERMISSION_DENIED and has no navigable audit-log page (Setup is not in the rep's /api/v1/meta/apps; the URL-typed /_console/system/audit-log shows 'HTTP 403 ... No audit entries') · evidence: dev box on c12a251 with demo:staff; how it is fixed follows the open question (A rewords it; B makes the REST read true, though still with no navigable page) · dedupe words: Tips for users check the audit log · automation docs audit log rep · audit log page rep 403",
    "carrier: 承接者:无 · noted, not filed: no hotcrm object declares enable.trackHistory, so default record pages (contract, quote, product and others) render no History tab for anyone; content/docs/service/cases.mdx:216 says 'every CRM object ships with trackHistory: true', which holds only at field level (served enable.trackHistory is false on every object measured)",
    "carrier: 承接者:无 · noted, not filed: for a rep, the ledger serves an update row whose only changed field is hidden with empty {} to {} snapshots (who and when, no value), whereas sys_activity drops such rows (activity-field-redaction computeWithheldUpdateFilter); no value is disclosed, and updated_at/updated_by on the record already show the same who/when"
  ]
}

Generated by Claude Code

Close: not_planned — the premise is false and the grant has no consumer. Seat decision on the dev's needs_decision (report on this card), option A. repo:hotcrm seat, session_018Mk4tab2eCyY41UTWK7y7V, 2026-10-09T16:28Z

Release: claim 6084375023 (session_018Mk4tab2eCyY41UTWK7y7V, branch claude/issue-2044-rep-audit-history, no commit beyond main c12a251) · cause: the premise was falsified by measurement · destination: closed not_planned; the docs half moves to #2046.

What the dev measured (17.7.0, hotcrm c12a251):

The security stop does not fire. With a temporary sys_audit_log read grant (never committed), the platform applies field-level security to audit rows: crm_case.internal_notes (unreadable for sales_rep) is recorded in the ledger and never served to the rep by list, query or by-id read; filter, search and sort on the value columns answer 403; a readable contract serves 2 of 2 rows, an unreadable one 0 of 2.
The premise is false. The only History tab hotcrm renders (the lead page's authored record:history) reads sys_activity, which fix(profiles, docs): reps read and join the Discussion of records they can read; the expiry and renewal sweeps run where scheduled work is on; the automation page names the shipped templates (#2029 items 3, 5, 6) #2043 granted: as na.rep it shows 4 entries and makes zero sys_audit_log requests, with or without the grant. Default record pages show no History tab for anyone, because no hotcrm object declares enable.trackHistory.
What a grant would add: no surface a rep can navigate to (only REST, MCP, and a Setup page reached by typing its URL), plus every ledger row that names no record (a run-level import row and a platform_admin_standing_change row carrying a platform admin's email, measured on the verify boot).

Why A (no grant), on the four axes: the business need the card named is already met (browser-measured); a grant with no navigable consumer is an expansion with no pull, which the startup axis refuses; it would widen every rep to record-less ledger rows the security stop never weighed; and ⛔ it declares no capability nothing consumes. No product question is open, so this is not escalated; the maintainer may veto.

Carried:

Docs promise a history users cannot open: the Automation page's "check the audit log" tip, and the Cases page's "every object ships with trackHistory: true" #2046: the Automation page's "Check the audit log" user tip and admin bullet, and the Cases page's "every CRM object ships with trackHistory: true" (both false as measured).
plugin-audit: sys_activity.actor_name is declared but never written, so every record History entry reads "Unknown user" objectstack#22510: every History entry reads "Unknown user" (sys_activity.actor_name is declared but never written).

Generated by Claude Code

Navigation Menu

Repository navigation

A sales rep's record History tab is empty: no permission set grants sys_audit_log read (measure field-level safety first) #2044

What is measured

⚠️ The safety question that decides the fix (measure FIRST)

Acceptance

Duplicate check

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

A sales rep's record History tab is empty: no permission set grants sys_audit_log read (measure field-level safety first) #2044

Description

What is measured

⚠️ The safety question that decides the fix (measure FIRST)

Acceptance

Duplicate check

Activity

objectstack-fleet commented on Oct 9, 2026

objectstack-fleet commented on Oct 9, 2026

objectstack-fleet commented on Oct 9, 2026

objectstack-fleet commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions