Skip to content

Register Signature Rejection in Policy Workbench and add flow tests #8689

Open

Description

@vitormattos

Part of #8685. Blocked by #8688.

Goal

Register the completed Signature Rejection policy module in Policy Workbench and verify that it works through the existing Workbench flow.

Do not add Signature Rejection rules to the shared engine.

Registration

Add only the parent definition to:

src/views/Settings/PolicyWorkbench/settings/realDefinitions.ts

Parent key:

rejection_enabled

The four helper policies must not appear as separate catalog entries.

Use the existing registration pattern.

Workbench integration

Use the engine completed by #8687 and the policy module completed by #8688.

Do not modify useRealPolicyWorkbench.ts or policyWorkbenchCompoundPolicies.ts just to register Signature Rejection. If registration requires Signature Rejection-specific engine logic, stop: that means #8687 is incomplete.

Use the engine that already exists.

Verify that the registered policy can be:

  • loaded;
  • edited;
  • saved;
  • reloaded;
  • reset/removed.

Do not add separate inheritance, delegation or authorization logic.

Backend validation errors must stay visible through the existing Workbench error flow.

Do not mock frontend-only permission rules. For a validation-error test, mock the backend request failure in the same way existing Workbench save-error tests do.

Focused integration tests

Cover:

  • Signature Rejection appears once in the catalog;
  • helper policies stay hidden;
  • a saved system rule restores all five values after reload;
  • one group or user rule uses the same generic flow;
  • a backend validation error is displayed and is not reported as a successful save.

Do not reproduce the backend validation matrix in frontend code or tests.

Playwright

Add one focused Policy Workbench scenario:

  1. open Signature Rejection;
  2. configure a system rule;
  3. save;
  4. reload;
  5. verify the five values are restored.

Reuse existing Policy Workbench helpers.

A second Playwright scenario is not required unless an existing helper makes a group/inherited case small and stable.

Done when

  • Signature Rejection appears once in the catalog.
  • Helper policies stay hidden.
  • Save + reload restores all five values.
  • One non-system rule is covered by focused integration tests.
  • Backend save errors remain visible.
  • The focused Playwright scenario passes.
  • npm run lint passes.
  • npm run ts:check passes.

Good first issue

The policy module and generic compound support are complete before this issue starts. This task only registers the module and verifies the existing Workbench behavior.

Activity

  1. added theissue type on Sep 24, 2026
  2. maia-andre commented on Oct 2, 2026

    @maia-andre
    Contributor

    I'd like to take this one right after #8688 (see my comment there). It is the registration and flow-test step on top of that module, so doing both in sequence keeps the context.

    As described: only the parent rejection_enabled in realDefinitions.ts, no Signature Rejection logic in the shared engine (if anything is missing there I'll report it on #8687 instead of working around it), the focused integration tests listed in the issue, and the Playwright scenario for system rule → save → reload → five values restored.

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

    Type

    Fields

    Priority

    None yet

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions