cap-feature-control

A singleton entity whose two flags drive what a Fiori elements page offers: the restriction, action-availability and button-visibility annotations all reach it by $edmJson $Path.

FeatureControl is an @odata.singleton holding operationHidden and operationEnabled, computed in its READ handler from whether the caller is('Admin'), and the annotations reach it over /CatalogService.EntityContainer/FeatureControl/...: Deletable inside Capabilities.DeleteRestrictions and, as the file writes it, Updatable inside Capabilities.InsertRestrictions; Core.OperationAvailable on the bound updateStock and the unbound autoFillStock; and UI.Hidden on both action buttons in the UI.LineItem. Beside those the file keeps variants that were tried and commented out, among them two that wrap the path in $Not to read the opposite flag, both marked //this does not work, and a UI.CreateHidden block marked //this works. fiori-dynamic-feature-controlfiori-dynamic-feature-controlsampleMaking one object page field non-editable from the value of another, implemented twice — through a default-value entity with side effects, and through a virtual element with a CAP Java handler.independent, cap answers the field-level half of the same question in CAP Java; this one is operation-level, in TypeScript, with cds-plugin-ui5cds-plugin-ui5cds-pluginA CDS plugin that runs the UI5 CLI express middlewares inside the CDS server, so a UI5 CLI project is served from the same port as the services, mounted under a path from its ui5.yaml.community org, cap in devDependencies and app/listreport as an npm workspace under sapux.

Who is behind it

Mio YasutakeMio YasutakePersonMaintains this
In the atlas: maintains 47, contributes to 47, wrote 10@miyasutamaintainer