Skip to content

Record the approving principal on draft-chunk decisions #3837

Description

@MohamadKhalilYossif

User Story

As a workspace admin, I need to know later who approved or rejected each draft chunk.

Problem Statement

On main (9cb72ba), the approve, reject, approve-all and undo handlers extract the caller Principal (crates/openshell-server/src/grpc/policy.rs:5349, 5495, 5596, 5967) and use it only for authorization. It is not persisted on the chunk (policy.rs:5437, 5571, 5833), the resulting revision (policy.rs:7115), the OCSF line (policy.rs:326), or DraftHistoryEntry (proto/openshell.proto:3458).

Impact / Why This Matters

#2109 treats prior approvals as evidence. An approval record without the approving principal cannot be attributed later.

Proposed Design

Record provider, issuer (when known) and subject of the deciding principal on the decision, the audit line, and GetDraftHistory. Existing records load unchanged.
Scope: attribution only. This does not change who may approve.

Open questions:

  • Optional fields under the frozen storage v1 fingerprint, a versioned migration path, or gateway-owned object metadata annotations instead of extending the frozen message?
  • Reuse a public message in storage, or a storage-only message?
  • Where should the actor go in OCSF, given Actor holds only a process?

I have a tested patch and can open a PR once the approach is agreed.

Acceptance Criteria

  • Two users' decisions are recorded as two distinct principals.
  • Approve-all records the approver on every chunk.
  • GetDraftHistory returns the principal for decided entries.
  • Chunks stored before the change still load.

Alternatives Considered

Logging the principal from a gateway interceptor keeps it outside OpenShell's own history and revisions.

Checklist

  • I've reviewed existing issues and the architecture docs
  • This is a design proposal, not a "please build this" request

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

    state:triage-neededOpened without agent diagnostics and needs triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions