Class WritePermit

java.lang.Object
org.apache.juneau.console.views.WritePermit

public final class WritePermit extends Object
The views-toolkit's own structural gate token for BulkMutateDef: proof that the caller's own write-gate was consulted before a bulk-mutating affordance is configured (the opt-in separability guarantee).
Why this exists, and why it is NOT the console's own WritePermit

A consuming application (e.g. the Sandbox Support Console) may already have its own, much richer write-gate token — one bound to a journal, a box Mode, an idempotency key, and a target validator (see that application's own write.WritePermit/WriteGuard). That type is deliberately not reused here: its constructor is package-private to its own write package, it is defined in a console-ui artifact this framework module must not depend on, and its shape carries concerns (journal binding, SAFE/LIVE mode) that are that application's business, not this framework's. Reaching into it would be a layering violation in the wrong direction (framework depending on a specific consumer).

This type is therefore this module's own, minimal, independent token — the same discipline (a required-parameter capability proof), a deliberately smaller shape (no journal/mode/idempotency concerns, which belong to the consumer's own gate). A consuming application's own write-gate is expected to mint one (typically by wrapping/adapting its own gate result) only after ITS OWN checks have passed, then hand it to BulkMutateDef.create(WritePermit, SelectionDef). This module does not, and cannot, verify that the caller's gate logic is correct — that is out of scope for a UI-rendering toolkit — but it does guarantee, by construction, that BulkMutateDef cannot be reached at all without a permit in hand: there is no zero-argument overload, so omitting one is a compile failure, not a missed javadoc sentence (mirroring the discipline of the console's own WriteGuard).

Example:

// After the consumer's OWN write-gate has already approved this capability: WritePermit permit = WritePermit.forCapability("incident:bulk-ack"); BulkMutateDef bulk = BulkMutateDef.create(permit, selection) .actions(RowAction.create("ack").endpoint("servlet:/incidents/{id}/ack").method(RowAction.Method.POST));

See Also:
Since:
10.0.0
  • Method Details

    • forCapability

      public static WritePermit forCapability(String capability)
      Mints a permit for the named capability.

      This is a bare proof-of-authorization token, not an enforcement seam: minting one asserts that the CALLER's own write-gate has already approved capability. This module trusts that assertion — it has no journal, arming, or idempotency logic of its own to check it against — its only job is to make the bulk-mutate opt-in unreachable without one.

      Parameters:
      capability - A stable, human-readable identifier for the capability this permit authorizes (e.g. "incident:bulk-ack"). Must not be null or blank.
      Returns:
      A new WritePermit.
      Throws:
      IllegalArgumentException - If capability is null or blank.
    • capability

      public String capability()
      The capability this permit authorizes.
      Returns:
      The capability identifier passed to forCapability(String).
    • toString

      public String toString()
      Overrides:
      toString in class Object