Skip to content

View Visibility ​

Per-element UI visibility — hiding a button, tab, or section from actors who lack a role — is declared in the app's manifest.json using the SAP-standardsap.ui5/extends/extensions/sap.ui.viewModifications block, and applied server-side when the manifest is served. There is no client-side can("see/…") check and no bespoke ability map. For the user this means the screen shows only what they may operate: a control they may not use is not greyed out, it simply isn't there.

Opt-in: suite membership. View gating is a suite capability. The app's manifest object must extend AbstractSdkManifest (the suite base). A standalone app on Core's AbstractManifest is never gated — that base-class choice is the opt-in. See The Core Seam.

Declaring a gated control ​

In your app's manifest.json, under sap.ui5:

json
"extends": {
  "extensions": {
    "sap.ui.viewModifications": {
      "com.acme.app.view.Main": {
        "exportButton": { "visible": false, "role": "Accounting" }
      }
    }
  }
}
  • The key path is {FQViewName}.{controlId} — the fully-qualified XML view name and the control's id.
  • "visible": false is the authored default — fail-closed: hidden unless granted.
  • "role" names the role that reveals it.

Add the matching i18n, keyed by the same {FQViewName}.{controlId}:

properties
com.acme.app.view.Main.exportButton.title=Export
com.acme.app.view.Main.exportButton.description=Export the current timesheet

What happens ​

  • At ui5:sync — ManifestAbilityExtractor reads the block and writes a See ability keyed {FQViewName}.{controlId} with its role into sdk_abilities + sdk_ability_role — the same RBAC tables as Access/Act. A modification without a role is a static change, not a gate, and is ignored.
  • At request time — when Core serves the manifest, the suite manifest's extend() (the GatesViewVisibility trait) rewrites each control's visible from the actor's resolved See grants — true if granted, false otherwise — and strips the role key. Manifests are served Cache-Control: no-store (they are per-actor).
  • In the browser — UI5 applies the viewModifications natively. No client check.

Still not the security boundary ​

See hides a control; it is not enforcement. The control's data and actions must still be protected by Access (the app) and Act (the operation) — a hidden button whose action isn't Act-gated remains reachable. See Permission Levels.

See also ​