**TITLE**: Fiori Elements — Editing Status (List Report / Draft Administrative Data)

**INTRODUCTION**: This document explains how Fiori elements list reports render and expose the draft editing status of entries, where the status data comes from (draft administrative data on the back end), how users access related user/time details, and how the static "Editing Status" filter behaves. Use these instructions when implementing or customizing list report UIs that are draft-enabled.

**TAGS**: fiori-elements-framework, editing-status, draft, list-report, responsive-table, grid-table, tree-table, analytical-table, filter

**STEP**: Rendering editing status in list report tables

**DESCRIPTION**: Implement and verify visual placement of the editing-status indicator for list report table types. The editing status is calculated from the draft administrative data returned by the back end (draft-enabled OData). Placement rules:
- Responsive table: show editing status in the key column (the first column shown with the semantic key).
- Grid table, Tree table, Analytical table: show editing status in a separate column placed in the second position; this column has no column label.
Include the provided visualization assets in design references or automated tests to validate expected UI. Keep draft administrative data mapping intact between backend and UI.

**LANGUAGE**: text

**CODE**:
```text
Image assets (use as visual references):
- images/Draft_Administrative_Data_Visualization_in_List_Report_Page_with_Responsive_Table_f66fced.png
- images/Draft_Administrative_Data_Visualization_in_List_Report_Page_with_Grid_Table_4b053c1.png

Data source:
- Draft administrative data must be provided by the OData service (backend).
- Map the draft status fields from the backend to the list report's row-level editing-status UI control.
```

**STEP**: Display user/time access for specific statuses (Own Draft / Unsaved Changes by Another User / Locked by Another User)

**DESCRIPTION**: For statuses Own Draft, Unsaved Changes by Another User, and Locked by Another User:
- Display the name of the user who last changed the object directly in the line item (if available).
- Provide a link in the line item that opens a popover showing the full user name (if available) and the time of the change.
- Fallback rules:
  - If the user's full name is not present in backend master data, display the technical user name.
  - If the technical user name is also not available, display "another user" for the user reference.
Ensure the popover control is reachable via keyboard and meets accessibility requirements.

**LANGUAGE**: text

**CODE**:
```text
Behavior:
- Line item text: show lastChangedUser (fullName || technicalUserName || "another user")
- Popover: show lastChangedUserFullName (if available), technicalUserName (if available), lastChangedTimestamp

Backend fields to use (example fields from Draft Administrative Data; confirm exact field names in your OData service):
- DraftAdministrativeData/InProcessByUser
- DraftAdministrativeData/LastChangedByUser
- DraftAdministrativeData/LastChangedAt
```

**STEP**: Editing Status filter (static filter added to the filter bar)

**DESCRIPTION**: All draft-enabled list-report applications include a static "Editing Status" filter that is added to the filter bar by default. Use this filter to allow users to search for entities by draft status. The filter's default selection is All (even if the user clears the filter). Implement the following dropdown values and semantics exactly as listed.

**LANGUAGE**: JSON

**CODE**:
```json
{
  "editingStatusFilter": {
    "default": "All",
    "values": [
      { "key": "All", "description": "Displays all entities" },
      { "key": "Own Draft", "description": "Displays a user's own draft only" },
      { "key": "Locked by Another User", "description": "Displays all entities that are currently in progress by someone" },
      { "key": "Unsaved Changes by Another User", "description": "Displays all entities with unsaved changes (lock expired, draft of someone is still available)" },
      { "key": "Unchanged", "description": "Displays all entities that have no draft" }
    ],
    "note": "Default search filter is 'All' even when the user clears the value"
  }
}
```

**STEP**: Disabling the Editing Status filter after app generation

**DESCRIPTION**: If you need to remove the static Editing Status filter from the filter bar after the app is generated, follow the platform-specific procedure documented by SAP. Use the referenced documentation to modify the generated app configuration safely (do not remove backend draft behavior unless intended).

**LANGUAGE**: text

**CODE**:
```text
See documentation for details:
- disabling-the-editing-status-filter-8eb695a.md
Related doc links for context:
- handling-semantic-key-fields-aa2793c.md
- settings-for-list-report-tables-4c2d17a.md
```

**RELATED INFORMATION**:
- handling-semantic-key-fields-aa2793c.md — Semantic key fields in tables are displayed with a special logic.
- settings-for-list-report-tables-4c2d17a.md — Configure list report table aspects via annotations and manifest.json.
- disabling-the-editing-status-filter-8eb695a.md — Steps to disable the editing status filter after generation.

fiori-elements-framework editing-status draft list-report responsive-table grid-table tree-table analytical-table filter


**TITLE**: Enabling Actions Added Using Extension Points (List Report & Object Page)

**INTRODUCTION**: Configure enablement and visibility of actions added using extension points by editing manifest.json. Supports SAP Fiori elements for OData V2 (requiresSelection, applicablePath) and OData V4 (enabled binding or handler). Use extensionAPI only for integrations; prefer manifest settings or annotations before extensions.

**TAGS**: fiori-elements-framework, manifest.json, extension-points, actions, enablement, OData V2, OData V4, object-page, list-report, extensionAPI

**STEP**: 1 — OData V2: Enable actions in List Report (action in table header)

**DESCRIPTION**: In manifest.json, add requiresSelection to require a row selection before enabling. Use applicablePath to query the backend for per-row applicability; if any selected row has applicablePath true the action is enabled. If applicablePath absent, action is always enabled. Place the code inside sap.ui5 -> extends -> extensions -> sap.ui.controllerExtensions -> ListReport controller extension info and sap.ui.generic.app -> <entity set> -> Actions.

**LANGUAGE**: XML

**CODE**:
```xml
"sap.ui5": {
   "extends": {
      "extensions": {
         "sap.ui.controllerExtensions": {
            "sap.suite.ui.generic.template.ListReport.view.ListReport": {
               "controllerName": "my_app.ext.controller.ListReportExtension",
               "sap.ui.generic.app": {
                  "<entity set>": {
                     "EntitySet": "<entity set>",
                     "Actions": {
                        "<Action 1>": {
                           "id": "<id>",
                           "text": "<button text>",
                           "press": "<handler function>",
                           "requiresSelection": true,
                           "applicablePath": "<entity type property>"
                        },
                        "<Action 2>": {
                           "id": "<id>",
                           "text": "<button text>",
                           "press": "<handler function>",
                           "requiresSelection": true
                        }
                     }
                  }
               }
            }
         }
      }
   }
}
```

**STEP**: 2 — OData V2: Enable actions in Object Page (header and table in section)

**DESCRIPTION**: Configure actions for the object page header (applies to the whole object) and for SmartTable facets in sections. Header actions use only applicablePath (object itself is the selection) and will be hidden when applicablePath evaluates to false. Section/table actions can use requiresSelection plus applicablePath to control enablement per selected row.

**LANGUAGE**: XML

**CODE**:
```xml
"sap.ui5": {
   "extends": {
      "extensions": {
         "sap.ui.controllerExtensions": {
            "sap.suite.ui.generic.template.ObjectPage.view.Details#my_app::sap.suite.ui.generic.template.ObjectPage.view.Details:: <entity set>":  {
               "controllerName": "my_app.ext.controller.DetailsExtension",
               "sap.ui.generic.app": {
                  "<entity set>": {
                     "EntitySet": "<entity set>",
                     "Header": {
                        "Actions": {
                           "<Action 1>": {
                              "id": "<id>",
                              "text": "<button text>",
                              "press": "<handler function>",
                              "applicablePath": "<entity type property>"
                           }
                        }
                     },
                     "Sections": {
                        "<entity type association>::com.sap.vocabularies.UI.v1.LineItem": {
                        "id": "<SmartTable Facet ID>",
                           "Actions": {
                              "<Action 2>": {
                                 "id": "<id>",
                                 "text": "<button text>",
                                 "press": "<handler function>",
                                 "requiresSelection": true,
                                 "applicablePath": "<entity type property>"
                              }
                           }
                        }
                     }
                  }
               }
            }
         }
      }
   }
}
```

**STEP**: 3 — OData V2: Show/hide custom action depending on Draft mode (use DraftAdministrativeData)

**DESCRIPTION**: In controller/view extension, bind the custom action to the DraftAdministrativeData navigation property to read draft status (for example, to only show a button in edit mode). Use getElementById and bindElement/bindProperty to connect visibility to DraftIsCreatedByMe (example below is the provided sample).

**LANGUAGE**: JavaScript

**CODE**:
```
 // "Element" required from module "sap/ui/core/Element"
> onAfterRendering: function(oEvent) {
>     var oButton = Element.getElementbyId("STTA_MP::sap.suite.ui.generic.template.ObjectPage.view.Details::STTA_C_MP_Product--action::ObjectPageCustomAction");
>     oButton.bindElement("DraftAdministrativeData");
>     oButton.bindProperty("visible", {
>         path: "DraftIsCreatedByMe"
```

**STEP**: 4 — OData V4: Use enabled property in manifest.json to control action enablement using a handler function

**DESCRIPTION**: For OData V4, set the enabled property of the action in manifest.json to the path of a handler function (Application function). The handler receives binding context and selected contexts and returns true/false or a Promise resolving to boolean. The example below shows reference string and handler skeleton that enables only when exactly one row is selected.

**LANGUAGE**: JSON / JavaScript

**CODE**:
```
"enabled": "SalesOrder.ext.CustomActions.enabledForCompletedOnly"
```

```
enabledForCompletedOnly: function(oBindingContext, aSelectedContexts) {
   if (aSelectedContexts && aSelectedContexts.length === 1) {
      return true;
   }

    return false;
}
```

**STEP**: 5 — OData V4: Manifest sample — List Report (action in table header)

**DESCRIPTION**: Place actions inside sap.ui5 -> routing -> targets -> <ListReportTargetName> -> options -> settings -> content -> header -> actions. Set press (Application method), visible, enabled, and text. visible/enabled accept boolean or handler function paths or binding expressions.

**LANGUAGE**: JSON

**CODE**:
```json
{
    "sap.ui5": {
        "routing": {
            "targets": {
                "<ListReportTargetName>": {
                    "options": {
                        "settings": {
                            "content": {
                                "header": {
                                    "actions": {
                                        "<ActionName>": {
                                            "press": "<ApplicationId.FolderName.ScriptFilename.methodName>",
                                            "visible": <true|false|handler function>,
                                            "enabled": <true|false|handler function>,
                                            "text": "{i18n>key}"
                                        }
                                    }
                                }
                            }
                         }
                    }
                }
```

**STEP**: 6 — OData V4: Manifest sample — Object Page (action in header/footer)

**DESCRIPTION**: Same pattern as List Report: place actions inside the target options settings content header or footer. enabled can be static, binding expression, or handler function path.

**LANGUAGE**: JSON

**CODE**:
```json
{
    "sap.ui5": {
        "routing": {
            "targets": {
                "<ObjectPageTargetName>": {
                    "options": {
                        "settings": {
                            "content": {
                                "header": {
                                    "actions": {
                                        "<ActionName>": {
                                            "press": "<ApplicationId.FolderName.ScriptFilename.methodName>",
                                            "visible": <true|false|handler function>,
                                            "enabled": <true|false|handler function>,
                                            "text": "{i18n>key}"
                                        }
                                    }
                                }
                            }
                         }
                    }
                }
```

**STEP**: 7 — OData V4: Enable action only in edit mode using ui model binding

**DESCRIPTION**: Use a binding expression on the ui model to enable only when ui>/editMode equals 'Editable'. Place this expression as the enabled property for the action in manifest.json.

**LANGUAGE**: JSON / Binding Expression

**CODE**:
```
enabled:"{= ${ui>/editMode} === 'Editable'}"
```

```json
{
    "sap.ui5": {
        "routing": {
            "targets": {
                "<ObjectPageTargetName>": {
                    "options": {
                        "settings": {
                            "content": {
                                "header": {
                                    "actions": {
                                        "<ActionName>": {
                                            "press": "<ApplicationId.FolderName.ScriptFilename.methodName>",
                                            "visible": <true|false|handler function>,
                                            "enabled": "{= ${ui>/editMode} === 'Editable'}",
                                            "text": "{i18n>key}"
                                        }
                                    }
                                }
                            }
                         }
                    }
                }
            }
        }
    }
}
```

**STEP**: 8 — OData V4: Control action visibility using a custom handler (manifest + implementation)

**DESCRIPTION**: Configure a handler path in manifest.json to evaluate visibility dynamically (for example, based on backend property via requestObject). Implement the handler to return boolean or Promise<boolean>. Use caution when toggling visibility dynamically as it affects UX.

**LANGUAGE**: JSON / JavaScript

**CODE**:
```json
{
    "sap.ui5": {
        "routing": {
            "targets": {
                "<ObjectPageTargetName>": {
                    "options": {
                        "settings": {
                            "content": {
                                "header": {
                                    "actions": {
                                        "<ActionName>": {
                                            "DataFieldForAction::com.c_salesordermanage_sd.ArchiveSalesOrder": {
                                            "visible": "SalesOrder.ext.CustomActions.visibleForCompletedOnly"
                                            }
                                        }
                                    }
                                }
                             }
                        }
                    }
                }
            }
        }
    }
}
```

```
visibleForCompletedOnly: function (oBindingContext) {
  if (oBindingContext) {
    return oBindingContext.requestObject("OverallSDProcessStatus").then(function (sStatus) {
      return sStatus === "C";
    });
  } else {
    return false;
  }
}
```

**STEP**: 9 — Caution and Best Practices

**DESCRIPTION**: Use app extensions only when necessary. Integrate using SAP Fiori elements extensionAPI exclusively. After adding app extensions, your code owns display and behavior (controls, bindings, busy handling). Prefer manifest settings and annotations where possible. Follow SAP Design guidelines when showing/hiding actions dynamically.

fiori-elements-framework
manifest.json
extension-points
actions
enablement
OData V2
OData V4
object-page
list-report
extensionAPI


**TITLE**: Enable Header Actions on the Object Page (UI.Identification / DataFieldForAction)

**INTRODUCTION**: This guide shows how to enable and control header actions (Edit, Delete, Copy, and custom actions) on SAP Fiori Elements Object Pages using annotations. It includes exact XML, ABAP CDS, and CAP CDS code examples for OData V2 and V4, plus rules for visibility and enablement (updatable-path, deletable, UI.Hidden, OperationAvailable, NavigationAvailable, IsCopyAction).

**TAGS**: fiori-elements-framework, annotations, UI.Identification, DataFieldForAction, ODataV2, ODataV4, CAP, ABAP-CDS, XML, CDS, actions, copy-action

STEP: 1 - Enable Generic Header Actions (DataFieldForAction in UI.Identification)

DESCRIPTION: Add DataFieldForAction records under the unqualified UI.Identification annotation collection. Each DataFieldForAction renders a header button showing the Label. Use these examples to add a "Copy with new supplier" action. Note: In OData V2 the object page context is always passed to header actions. In OData V4 context is passed only for bound actions; unbound actions receive no context.

LANGUAGE: XML

CODE:
```xml
<Annotation Term="UI.Identification">
      <Collection>
            <Record Type="UI.DataFieldForAction">
                  <PropertyValue Property="Label" String="Copy with new supplier" />
                  <PropertyValue Property="Action"
                        String="STTA_PROD_MAN.STTA_PROD_MAN_Entities/STTA_C_MP_ProductCopy_new_supplier" />
                  <Annotation Term="UI.Importance" EnumMember="UI.ImportanceType/High" />
            </Record>
            ...
      </Collection>
</Annotation>
```

LANGUAGE: ABAP

CODE:
```
@UI.identification: [
  {
    importance: #HIGH,
    label: 'Copy with new supplier',
    dataAction: 'PUSHDOWN:STTA_C_MP_ProductCopy_new_supplier',
    type: #FOR_ACTION,
    position: 1
  }
]
product;
```

LANGUAGE: CDS

CODE:
```
UI.Identification : [
    {
        $Type : 'UI.DataFieldForAction',
        Label : 'Copy with new supplier',
        Action : 'STTA_PROD_MAN.STTA_PROD_MAN_Entities/STTA_C_MP_ProductCopy_new_supplier',
        ![@UI.Importance] : #High
    }
]
```

STEP: 2 - Edit Action Behavior on Subobject Pages

DESCRIPTION: Rules for displaying/enabling the Edit button on subobject pages:
- Visible on subobject page only if visible on object page AND not hidden on subobject entity.
- Enabled on subobject page only if enabled on object page AND not disabled on subobject entity.
- Selecting Edit on a subobject page enables editing for the entire object page (affects whole object page, not only subobject).

LANGUAGE: Text

CODE:
```
Rules:
- Show Edit on subobject: visible_on_object_page == true AND subobject_not_annotated_hide == true
- Enable Edit on subobject: enabled_on_object_page == true AND subobject_not_annotated_disable == true
- NOTE: Edit action toggles edit mode for the entire object page, not just the subobject.
```

STEP: 3 - Add a Standard Copy Action (isCopyAction)

DESCRIPTION: Define a Copy action by annotating a DataFieldForAction with UI.IsCopyAction = true. The Copy button appears after Delete. If no Label is provided, "Copy" is used by default. Copy action is available only on the object page (not subobject pages).

LANGUAGE: XML

CODE:
```xml
<Annotation Term="UI.Identification">
  <Collection>
      <Record Type="UI.DataFieldForAction">
          <PropertyValue Property="Label" String="Copy" />
          <PropertyValue Property="Action" String="STTA_PROD_MAN.STTA_PROD_MAN_Entities/STTA_C_MP_ProductCopy" />
          <Annotation Term="UI.IsCopyAction" Bool="true" />
     </Record>
```

LANGUAGE: CDS

CODE:
```
UI.Identification : [
    {
        $Type : 'UI.DataFieldForAction',
        Label : 'Copy',
        Action : 'STTA_PROD_MAN.STTA_PROD_MAN_Entities/STTA_C_MP_ProductCopy',
        ![@UI.IsCopyAction] : true,
    },
],
```

STEP: 4 - OData V2: Control Edit/Delete Visibility and updatable-path Example

DESCRIPTION: For OData V2:
- Edit button is shown if sap:updatable != "false".
- Delete button is shown if sap:deletable != "false".
To hide/show Edit based on runtime property, use Org.OData.Capabilities.V1.UpdateRestrictions with Updatable Path.

LANGUAGE: XML

CODE:
```xml
<Annotations Target="STTA_PROD_MAN.STTA_PROD_MAN_Entities/STTA_C_MP_Product">
    <Annotation Term="Org.OData.Capabilities.V1.UpdateRestrictions">
        <Record>
            <PropertyValue Property="Updatable" Path="Updatable_mc"/>
        </Record>
    </Annotation>
</Annotations>
```

NOTE: If you use updatable-path/deletable-path you must not have sap:updatable or sap:deletable statically overriding it.

STEP: 5 - OData V4: Draft, UpdateHidden, and Edit Enablement (EditAction and OperationAvailable)

DESCRIPTION:
- Draft apps often define a DraftRoot EditAction; when EditAction exists, UpdateRestrictions are ignored. Example of DraftRoot EditAction:
- Control visibility of Edit via UI.UpdateHidden at entity set level (static Bool or Path).
- Edit enablement when EditAction exists is controlled by OperationAvailable (static true/false or path). Behavior:
  - OperationAvailable = true or not defined => Edit visible (if updateHidden != true) and enabled.
  - OperationAvailable = false => Edit not visible.
  - OperationAvailable = <path> => If path returns true => enabled; false => not visible; null => visible but disabled.

LANGUAGE: XML

CODE:
```xml
<Annotation Term="com.sap.vocabularies.Common.v1.DraftRoot">
    <Record>
        <PropertyValue Property="EditAction" String="com.sap.gateway.srvd.sadl_gw_appmusicdr_definition.v0001.EditAction"/>
    </Record>
</Annotation>
```

LANGUAGE: XML

CODE:
```
<Annotations Target="com.c_salesordermanage_sd.EntityContainer/HeaderPartner">
   <Annotation Term="UI.UpdateHidden" Bool="true"/>
</Annotations>

OR

<Annotations Target="com.c_salesordermanage_sd.EntityContainer/SalesOrderManage">
   <Annotation Term="UI.UpdateHidden" Path="isUpdateHidden"/>
</Annotations>
```

LANGUAGE: ABAP

CODE:
```
@UI.updateHidden:true

OR

@UI.updateHidden: #('isUpdateHidden')
```

LANGUAGE: CDS

CODE:
```
annotate com.c_salesordermanage_sd.SalesOrderManage with @( UI.UpdateHidden: true);

OR

annotate com.c_salesordermanage_sd.SalesOrderManage with @( UI.UpdateHidden: isUpdateHidden);
```

STEP: 6 - Define Custom Global Header Actions (DataFieldForAction, DataFieldForIntentBasedNavigation)

DESCRIPTION: Place global actions under UI.Identification (unqualified). Actions not marked determining=true render next to standard actions. Bound actions or DataFieldForIBN receive object context; unbound actions do not. Use UI.Hidden to hide actions (static or path-based). Use OperationAvailable to control enablement for DataFieldForAction. For intent-based navigation, control enablement using NavigationAvailable.

LANGUAGE: XML

CODE:
```xml
<Annotation Term="UI.Identification">
    <Collection>
        ...
        <Record Type="UI.DataFieldForAction">
            <PropertyValue Property="Label" String="Break Up" />
            <PropertyValue Property="Action" String="com.sap.gateway.srvd.sadl_gw_appmusicdr_definition.v0001.BREAK_UP" />
        </Record>
        <Record Type="UI.DataFieldForIntentBasedNavigation">
            <PropertyValue Property="Label" String="SampleIBN"/>
            <PropertyValue Property="SemanticObject" String="MySemanticObject"/>
            <PropertyValue Property="Action" String="manage"/>
            <PropertyValue Property="RequiresContext" Bool="false"/> // For header IBN buttons, this should only be false or not specified!
        </Record>
        ...
    </Collection>
</Annotation>
```

LANGUAGE: ABAP

CODE:
```
@UI.identification: [
  {
    label: 'Break Up',
    dataAction: 'com.sap.gateway.srvd.sadl_gw_appmusicdr_definition.v0001.BREAK_UP',
    type: #FOR_ACTION,
    position: 1
  },
  {
    label: 'SampleIBN',
    semanticObjectAction: 'manage',
    type: #FOR_INTENT_BASED_NAVIGATION,
    position: 2
  }
]
TEST;
@Consumption.semanticObject: 'MySemanticObject'
%ENTITY;
```

LANGUAGE: CDS

CODE:
```
UI : {
    Identification: [
        {
            $Type  : 'UI.DataFieldForAction',
            Label   : 'Break Up',
            Action : ' com.sap.gateway.srvd.sadl_gw_appmusicdr_definition.v0001.BREAK_UP'
        },
        {
            $Type              : ' UI.DataFieldForIntentBasedNavigation',
            Label              : ' SampleIBN ',
            SemanticObject     : 'MySemanticObject',
            Action             : 'manage',
            RequiresContext    : false
        }
    ]
}
```

STEP: 7 - Visibility and Enablement Controls Summary

DESCRIPTION: Quick mapping of annotations to behavior:
- UI.Hidden (static true or path => hidden) — controls visibility of custom actions.
- OperationAvailable (static true/false or path) — controls enablement/visibility for DataFieldForAction when EditAction/operation model used.
- NavigationAvailable / RequiresContext / Intent-based navigation — enablement for IBN buttons.
- UI.IsCopyAction = true — identifies the standard Copy button; appears after Delete on object page.
- sap:updatable / sap:deletable — OData V2 static controls (avoid combining with path-based annotations).
- Org.OData.Capabilities.V1.UpdateRestrictions / Updatable Path — path-based control for Edit visibility on OData V2 (use instead of static sap:updatable).

LANGUAGE: Text

CODE:
```
Controls:
- UI.Hidden        -> hide action (static or path)
- OperationAvailable -> enable/disable (true=enabled, false=not visible, path: null=visible disabled)
- NavigationAvailable -> enable/disable IBN
- UI.IsCopyAction -> makes DataFieldForAction behave as Copy (placed after Delete)
- sap:updatable / sap:deletable (OData V2) -> static show/hide (do not combine with path-based)
- UpdateRestrictions.Updatable (OData V2) -> use Path="..." for dynamic control
```

STEP: 8 - References (Related Topics & Links)

DESCRIPTION: Consult these related docs to expand action behavior and criticality:
- Displaying Actions on the Object Page: displaying-actions-on-the-object-page-f65e8b1.md
- Actions (general): actions-cbf16c5.md
- Setting the Criticality for Actions: setting-the-criticality-for-actions-12f2ba2.md
- Navigation from an App (Outbound): navigation-from-an-app-outbound-navigation-d782acf.md
- Adding Actions to Tables (Delete button details): adding-actions-to-tables-b623e0b.md

LANGUAGE: Text

CODE:
```
Related docs:
- displaying-actions-on-the-object-page-f65e8b1.md
- actions-cbf16c5.md
- setting-the-criticality-for-actions-12f2ba2.md
- navigation-from-an-app-outbound-navigation-d782acf.md
- adding-actions-to-tables-b623e0b.md
```

fiori-elements-framework annotations UI.Identification DataFieldForAction ODataV2 ODataV4 CAP ABAP-CDS XML CDS actions copy-action


**TITLE**: Enabling Key User Adaptation for SAP Fiori elements (OData V4)

**INTRODUCTION**: Step-by-step, code-focused instructions to enable SAPUI5 flexibility (key user adaptation) for SAP Fiori elements apps (OData V4). Includes required manifest.json settings, annotation samples to prepare header facets, manifest entries to stash or restrict header facets, and annotation guidance for enabling form personalization.

**TAGS**: fiori-elements-framework, sapui5, flexibility, key-user-adaptation, manifest.json, annotations, object-page, forms

STEP: 1 — Enable SAPUI5 Flexibility for the App

DESCRIPTION: Turn on SAPUI5 flexibility in your app manifest so key users can adapt the UI (required for all further personalization). This setting belongs under the top-level "sap.ui5" section of manifest.json.

LANGUAGE: JSON

CODE:
```json
// manifest.json (top-level)
{
  "sap.ui5": {
    "flexEnabled": true
    // other sap.ui5 settings...
  }
}
```

STEP: 2 — Prepare Header Facets via Annotations (UI.HeaderFacets)

DESCRIPTION: Provide annotations that define header facets (ReferenceFacet entries). These annotations prepare facets so they can be added by key users to the object page header. Include IDs when you want a stable reference; otherwise an ID is generated from the AnnotationPath and qualifier.

LANGUAGE: XML

CODE:
```xml
<Annotation Term="UI.HeaderFacets">
  <Collection>
    ...
    <Record Type="UI.ReferenceFacet">
      <PropertyValue Property="Label" String="Column MicroChart"/>
      <PropertyValue Property="ID" String="ColumnMicroChart"/>
      <PropertyValue Property="Target" AnnotationPath="_Item/@UI.Chart#ColumnMaxPath"/>
      <Annotation Term="UI.Importance" EnumMember="UI.ImportanceType/High"/>
    </Record>
    <Record Type="UI.ReferenceFacet">
      <PropertyValue Property="Label" String="Progress Indicator"/>
      <PropertyValue Property="ID" String="ProgressIndicator"/>
      <PropertyValue Property="Target" AnnotationPath="@UI.DataPoint#Progress"/>
      <Annotation Term="UI.Importance" EnumMember="UI.ImportanceType/High"/>
    </Record>
    ...
  </Collection>
</Annotation>
```

STEP: 3 — Configure Object Page Settings and Control Configuration for Header Facets

DESCRIPTION: Use the object page component entry in manifest.json to stash header facets (initially hide them) or restrict their adaptability. Reference header facets by the ID defined in annotations, or by the generated ID if no ID is present. Example shows stashing ColumnMicroChart and applying flexSettings designtime restriction for ProgressIndicator.

LANGUAGE: JSON

CODE:
```json
// manifest.json (component settings for an ObjectPage)
"SalesOrderManageObjectPage": {
  "type": "Component",
  "id": "SalesOrderManageObjectPage",
  "name": "sap.fe.templates.ObjectPage",
  "options": {
    "settings": {
      "editableHeaderContent ": false,
      "controlConfiguration": {
        "@com.sap.vocabularies.UI.v1.HeaderFacets": {
          "facets": {
            "ColumnMicroChart": {
              "stashed": true
            },
            "ProgressIndicator": {
              "stashed": false,
              "flexSettings": {
                "designtime": "not-adaptable-visibility"
              }
            }
          }
        }
      }
    }
  }
}
```

STEP: 4 — How Header Facet IDs Are Determined (Reference Behavior)

DESCRIPTION: If your annotation record contains a PropertyValue "ID", that ID is used in manifest.json references. If no ID is defined, the framework generates an ID from the AnnotationPath and qualifier (example: DataPoint::Rating). Use these IDs in controlConfiguration facets entries to stash or restrict adaptivity.

LANGUAGE: XML

CODE:
```xml
<Record Type="UI.ReferenceFacet">
  <PropertyValue Property="Label" String="Progress Indicator"/>
  <PropertyValue Property="ID" String="ProgressIndicator"/>
  <PropertyValue Property="Target" AnnotationPath="@UI.DataPoint#Progress"/>
</Record>
<Record Type="UI.ReferenceFacet">
  <PropertyValue Property="Label" String="Rating Indicator"/>
  <PropertyValue Property="Target" AnnotationPath="@UI.DataPoint#Rating"/>
</Record>
```

STEP: 5 — Stashing Behavior and User Experience

DESCRIPTION: Mark facets as "stashed" in manifest.json to keep them initially hidden and not loaded on app start. Key users can later add these stashed facets to the object page header via key user adaptation UI. (This is configured using the "stashed": true entry shown in Step 3.)

LANGUAGE: JSON

CODE:
```json
// Example entry that keeps a facet stashed (not loaded on startup)
"ColumnMicroChart": {
  "stashed": true
}
```

STEP: 6 — Restrict Adaptability Using flexSettings / designtime

DESCRIPTION: Use "flexSettings": { "designtime": "<value>" } to restrict allowed adaptation actions for a control. Example: "not-adaptable-visibility" disables add/remove actions affecting visibility but still allows move operations. Apply per facet in controlConfiguration as shown in Step 3.

LANGUAGE: JSON

CODE:
```json
// Example flexSettings to restrict visibility-related adaptions
"ProgressIndicator": {
  "stashed": false,
  "flexSettings": {
    "designtime": "not-adaptable-visibility"
  }
}
```

STEP: 7 — Enable Key User Adaptation in Forms (DataFieldDefault usage)

DESCRIPTION: To allow key users to add/move/remove form fields, expose properties using DataFieldDefault. Use DataFieldDefault as a wrapper for DataField or DataFieldWithUrl to make properties available in the Add dialog. Ensure FormContainers that will accept moved fields are based on the same entity.

LANGUAGE: JavaScript (annotation snippet syntax)

CODE:
```js
OrganizationDivision : String(2) @(
  Common : {Label : 'Division'},
  UI : {
    DataFieldDefault : {
      $Type: 'UI.DataField',
      Value: OrganizationDivision,
      Label: 'Default Division'
    }
  }
);
```

STEP: 8 — Constraints, Notes and Best Practices

DESCRIPTION: Keep these actionable constraints visible to the developer:
- Key user adaptation is available only for SAP Fiori elements for OData V4.
- Standard actions such as edit, save, delete are excluded from key user adaptation.
- Actions with dynamic visibility cannot be added or removed.
- DataFieldForAction, DataFieldForIntendBasedNavigation, DataFieldWithAction, and DataFieldWithIntentBasedNavigation are not supported for adding as form fields.
- Fields added via key user adaptation receive a stable ID provided by SAPUI5 flexibility (different from SAP Fiori elements generated stable IDs).

LANGUAGE: JSON

CODE:
```json
// Reminder (no code change) - ensure "sap.ui5": { "flexEnabled": true } is set
// and configure controlConfiguration entries per facet/form-field as required.
```

fiori-elements-framework sapui5 flexibility key-user-adaptation manifest.json annotations object-page forms


**TITLE**: Enabling Chart Personalization in SAP Fiori Elements (Manifest Configuration)

**INTRODUCTION**: This guide shows how to enable, disable, and control chart personalization options through the application manifest. It targets Fiori Elements apps (OData V4) and explains default behaviors, variant-management effects (Page/Control/None), and which fields are excluded from the chart Filter option.

**TAGS**: fiori-elements, chart, personalization, manifest, OData V4, variant-management, controlConfiguration

**STEP**: 1 — Default behavior and variant-management effect

**DESCRIPTION**: Understand default availability of chart personalization options and how variant management affects them. Default behaviors:
- Page-level variant or when variant management is not enabled: Filter option is disabled.
- Control-level variant: Filter option is enabled.
- Variant-management mapping to visible options:
  - "Page" => Item, Sort, Type
  - "None" => Item, Sort, Type
  - "Control" => Item, Sort, Type, Filter

Use this knowledge when choosing a variant-management strategy and when deciding whether to allow users to change Filter-related settings.

**LANGUAGE**: Plain

**CODE**:
```text
Default behaviors:
- Page-level variant or when variant management is not enabled: Filter option is disabled.
- Control-level variant: Filter option is enabled.

Variant-management mapping:
- "Page" => Item, Sort, Type
- "None" => Item, Sort, Type
- "Control" => Item, Sort, Type, Filter
```

**STEP**: 2 — Disable all chart personalization (manifest setting)

**DESCRIPTION**: To switch off all chart personalization options globally for a chart control, set the chartSettings.personalization value to false in the component manifest under controlConfiguration for the chart annotation namespace. Use this manifest fragment as-is within the corresponding Component entry.

**LANGUAGE**: JSON

**CODE**:
```json
"BusinessPartnersList": {
   "type": "Component",
   "id": "BusinessPartnersList",
   "name": "sap.fe.templates.ListReport",
   "options": {
      "settings": {
         "contextPath": "/BusinessPartners",
         .....
         .....
         "controlConfiguration": {
            "@com.sap.vocabularies.UI.v1.Chart": {
               "chartSettings": {
                  "personalization": false
               }
            }
         }
      }
   }
},
```

**STEP**: 3 — Fine-grained control of personalization options (manifest setting with object)

**DESCRIPTION**: To enable/disable specific personalization features, set personalization to an object with boolean flags for column, sort, filter, and type. Important notes:
- personalization: true enables all features (default).
- personalization: false disables all features.
- personalization: object must explicitly define any options you want enabled; omitted options are treated as false. This avoids unexpected automatic enabling of new features in future releases.

Use this manifest fragment as a template inside the correct Component entry.

**LANGUAGE**: JSON

**CODE**:
```json
"BusinessPartnersList": {
   "type": "Component",
   "id": "BusinessPartnersList",
   "name": "sap.fe.templates.ListReport",
   "options": {
      "settings": {
         "contextPath": "/BusinessPartners",
         ....
         ....
         "controlConfiguration": {
            "@com.sap.vocabularies.UI.v1.Chart": {
               "chartSettings": {
                  "personalization": {
                    "column" : true,
                    "sort" : false, // Sort option is not visible
                    "filter" : true,
                    "type": true
                  }
               }
            }
         }
      }
   }
},
```

**STEP**: 4 — Fields excluded from the chart Filter option

**DESCRIPTION**: When configuring Filter as part of chart personalization, these fields are automatically excluded and will not appear in the Filter personalization UI:
- Fields annotated with @com.sap.vocabularies.UI.v1.HiddenFilter
- Fields coming from a navigation entity set
- Properties annotated as measures (Analytics.AggregatedProperty) or marked with Aggregation.CustomAggregate

Refer to "Configuring Charts" docs for additional chart-specific rules and examples.

**LANGUAGE**: Plain

**CODE**:
```text
Excluded from chart Filter personalization:
- @com.sap.vocabularies.UI.v1.HiddenFilter annotated fields
- Fields from a navigation entity set
- Properties annotated with Analytics.AggregatedProperty or Aggregation.CustomAggregate
```

fiori-elements
chart
personalization
manifest
OData V4
variant-management
controlConfiguration


**TITLE**: Enabling Discovery / Persistence Mode for Object Page State Preservation

**INTRODUCTION**: Configure how the object page preserves/restores UI state (filters, tab/section selection, visible columns, chart/table personalization) via iAppState by setting the manifest property statePreservationMode. Use "discovery" for per-object transient state, and "persistence" for shared state across sibling objects (default for FCL apps).

**TAGS**: fiori-elements, sapui5, manifest.json, iAppState, statePreservationMode, object-page, persistence, discovery, flexible-column-layout, ODataV2, ODataV4

STEP: 1 — Choose the correct mode for your application

DESCRIPTION: Select the mode that matches your UX expectations and layout:
- discovery: default for non-FCL apps. Personalization changes affect only the current object instance and do NOT persist when navigating to another object at the same level.
  - Use when each object should revert to default settings when opened.
  - Examples: filter applied on one object shouldn't affect the next; tab selection resets to first tab on a new object.
- persistence: default for FCL apps. Personalization changes persist across sibling objects at the same level.
  - Use when personalization should be shared when navigating between objects (paginator or sibling navigation).
  - Examples: filters and selected tabs persist across objects.

LANGUAGE: text

CODE:
```text
Allowed values for statePreservationMode:
- "discovery"
- "persistence"
```

STEP: 2 — Configure statePreservationMode in manifest.json (OData V2)

DESCRIPTION: Set the statePreservationMode property under "sap.ui.generic.app" → "settings" in the application manifest (manifest.json). This is the primary configuration for enabling discovery or persistence mode for SAP Fiori elements (OData V2). Place the setting at the app-level where other generic app settings are declared.

LANGUAGE: JSON

CODE:
```json

"sap.ui.generic.app": {
        "_version": "1.3.0",
        "settings": {

            "objectPageDynamicHeaderTitleWithVM": true,
            "statePreservationMode": "persistence"/"discovery"
        },
        "pages": {
            "ListReport|C_STTA_SalesOrder_WD_20": {
```

STEP: 3 — Operational notes and edge cases

DESCRIPTION: Keep these behavior specifics in mind when implementing:
- Section selection: Persists only when selected via anchor navigation; scrolling to a section does NOT count as selection for persistence.
- Scope of persistence: Changes persist only while the object/subobject page remains open. Closing the page resets changes to annotation/manifest defaults.
- Exception: The latest opened object (most recently visited) retains its changes even after closing its page.
- Default behavior by layout: If your app uses flexible column layout (FCL), persistence is the default; non-FCL apps default to discovery.

LANGUAGE: text

CODE:
```text
Notes:
- Section selection persists only when selected from anchor area (not via scrolling).
- Changes to pages/subobjects reset to defaults when the page is closed (except the latest opened object retains its changes).
- FCL apps default to "persistence"; non-FCL apps default to "discovery".
```

STEP: 4 — OData V4 restriction

DESCRIPTION: For SAP Fiori elements with OData V4, discovery mode is not supported. Only persistence behavior is applicable — do not configure statePreservationMode to "discovery" for OData V4 apps.

LANGUAGE: text

CODE:
```text
Restriction for OData V4:
- Discovery mode is NOT applicable for SAP Fiori elements for OData V4. Use persistence behavior instead.
```


**TITLE**: Enabling Mass Edit (Dialog) in SAP Fiori Elements

**INTRODUCTION**: Action-oriented reference for enabling and configuring the Mass Edit dialog (mass edit) in SAP Fiori Elements applications. Covers compatibility (OData V2 vs V4), manifest.json configuration (enableMassEdit, visibleFields, ignoredFields), operation grouping, prerequisites, behavior, and restrictions. Use this as a checklist and copy-paste source for manifest.json changes.

**TAGS**: fiori-elements, mass-edit, manifest.json, OData, enableMassEdit, visibleFields, ignoredFields, operationGroupingMode, CAP

STEP: Compatibility (OData V2 vs OData V4)

DESCRIPTION: Determine where mass edit is supported and how configuration options differ between OData V2 and OData V4.

LANGUAGE: text

CODE:
```text
- OData V2: Mass edit dialog is available only in the list report.
- OData V4: Mass edit dialog is available in the list report and on the object page (object page only in edit mode). Configuration is via enableMassEdit in manifest.json and accepts:
  - undefined (disabled)
  - boolean
  - object with visibleFields or ignoredFields (only one of these can be used)
```

STEP: Enable mass edit in manifest.json (Boolean)

DESCRIPTION: Turn on mass edit for a specific table by setting enableMassEdit to true in the controlConfiguration entry for the table (identified by the LineItem annotation id/path).

LANGUAGE: JSON

CODE:
```JSON
"controlConfiguration": {
   "_Item/@com.sap.vocabularies.UI.v1.LineItem": {
      "tableSettings": {
         ......
         ......
         "enableMassEdit": true
      },
      ......
      ......
}
```

STEP: Enable mass edit using visibleFields (recommended for performance)

DESCRIPTION: Use visibleFields to explicitly list fields available in the mass edit dialog. This lets you load only required fields (performance boost). visibleFields accepts a FieldGroup annotation reference or a comma-separated property list. If visibleFields is set, ignoredFields is ignored. Use visibleFields when you need full control over the dialog fields.

LANGUAGE: JSON

CODE:
```JSON
"controlConfiguration": {
   "_Item/@com.sap.vocabularies.UI.v1.LineItem": {
      "tableSettings": {
         ......
         ......
         "enableMassEdit": {
            "visibleFields": "@com.sap.vocabularies.UI.v1.FieldGroup#FieldsForMassEdit"
      },
      ......
      ......
}
```

STEP: Enable mass edit using ignoredFields

DESCRIPTION: Use ignoredFields to hide specific fields from the mass edit dialog (fields listed are not shown). ignoredFields accepts a comma-separated list of properties or a FieldGroup annotation. Do not use ignoredFields together with visibleFields — visibleFields takes precedence.

LANGUAGE: JSON

CODE:
```JSON
"controlConfiguration": {
   _Item/@com.sap.vocabularies.UI.v1.LineItem: {
      "tableSettings": {
         ......
         ......
         "enableMassEdit": {
             "ignoredFields": "property2,property3"
      },
      ......
      ......
}
```

STEP: Configure operation grouping mode (ChangeSet vs Isolated)

DESCRIPTION: Choose how update requests from a mass edit are grouped: "ChangeSet" groups updates for multiple objects in a single OData changeset; "Isolated" sends separate changesets per object. Set via operationGroupingMode inside enableMassEdit. Default: object page = ChangeSet, list report = Isolated.

LANGUAGE: JSON

CODE:
```JSON
"controlConfiguration": {
   _Item/@com.sap.vocabularies.UI.v1.LineItem: {
      "tableSettings": {
         ......
         ......
         "enableMassEdit": {
            ......
            "operationGroupingMode": "Isolated"
      },
      ......
      ......
}
```

STEP: Prerequisites to enable/use mass edit

DESCRIPTION: Ensure these conditions before relying on mass edit:

LANGUAGE: text

CODE:
```text
- The application manifest.json must enable mass edit (see samples above).
- End users must select at least one record to open mass edit.
- On object pages, mass edit is available only in edit mode.
- For CAP Node.js back ends, you may need to enable a feature flag. See:
  https://cap.cloud.sap/docs/releases/dec23#sapui5-mass-edit
- If the back end is ETag enabled, ensure ETag implementation is in "etag master" mode (child entity ETag must not depend on parent/root ETag).
```

STEP: Mass edit behavior and runtime details

DESCRIPTION: Implementation and runtime behaviors that affect mass edit operations; use to design back-end and front-end expectations.

LANGUAGE: text

CODE:
```text
- Read-only fields are automatically excluded from the mass edit dialog. Only editable fields are changed.
- When saving, values entered apply to all selected records that are editable.
- Updates are executed per selected record:
  - If some records fail with errors/warnings, updates for other selected instances still proceed.
  - An individual record is only updated if all fields for that record can be updated.
- Suggestion values (prepopulated suggestion list) are proposed only using the first 30 selected lines.
  - For >30 lines, dialog opens immediately; field editability per line is computed in background and used on save.
- The Edit button
  - Is not visible if the table entity has an update restriction set to static false.
  - Visibility can be controlled by UI.UpdateHidden (can be path-based to parent for object/subobject pages or singleton in list report).
  - Is not enabled if an update restriction path resolves to false.
- If enableMassEdit is active and selectionMode is unspecified or "Multi", multiple selection is allowed regardless of other toolbar action conditions.
- Server-side validation is not performed while editing in the dialog; no back-end communication until the user presses Save.
- Do NOT enable mass edit if the back end locks the entire object while updating a child object.
- Mass edit is NOT supported on object pages when Collaborative Draft is enabled.
```

STEP: Restrictions — unsupported fields and limitations

DESCRIPTION: Fields and features that cannot be used in the mass edit dialog. Ensure these are not included in visibleFields or expected to work.

LANGUAGE: text

CODE:
```text
Unsupported field types/features in the mass edit dialog:
- Image-based fields
- DataFieldForAnnotation-based fields (examples: micro-chart fields, contact fields, fields coming from a FieldGroup-based field in the table)
- Multi-input fields
- Fields coming from navigation entities
- Custom fields
- Fields with context-dependent value help (see Field Help docs)
- Value help fields with fixed dropdown values (@Common.ValueListWithFixedValues: true)

Other limitations:
- Suggestion lists are not available when:
  - A field is part of Common.ValueListParameterIn mapping of another field that is filled (e.g., City suggestions suppressed if Country is selected in dialog).
  - A field has a Common.ValueListParameterOut mapping (Out mapping cannot be resolved reliably for multiple selected records).
```

STEP: Performance guidance

DESCRIPTION: Best practices for fast load and predictable mass edit dialogs.

LANGUAGE: text

CODE:
```text
- Prefer using visibleFields to explicitly list only the fields needed in the mass edit dialog (reduces payload and improves load time).
- Avoid including large or complex value helps in visibleFields if not required.
- Limit the number of fields exposed for mass edit to those strictly necessary for the operation.
```

fiori-elements mass-edit manifest.json OData enableMassEdit visibleFields ignoredFields operationGroupingMode CAP


**TITLE**: Enable Mass Edit Dialog in List Report (OData V2)

**INTRODUCTION**: This document describes how to enable and configure the Mass Edit (multiEdit) dialog on a List Report (OData V2). It covers enabling multiEdit in manifest.json, targeting fields via FieldGroup annotation for performance, ignoring specific fields from the dialog, overriding the dialog title, and platform limitations/behavior.

**TAGS**: fiori-elements-framework, list-report, mass-edit, multiEdit, manifest.json, FieldGroup, annotation, i18n, ODataV2

**STEP**: 1 — Enable multiEdit in manifest.json

**DESCRIPTION**: Enable multiEdit to show the Edit option in the table toolbar. When enabled, users can select multiple records and open the mass edit dialog; values entered are applied to all selected records. By default the dialog displays editable fields corresponding to columns currently displayed in the table (table personalization affects displayed columns).

**LANGUAGE**: JSON

**CODE**:
```json
"sap.ui.generic.app": {
        "_version": "1.1.0",
        "pages": [
            {
                "entitySet": "STTA_C_SO_SalesOrder_ND",
                "component": {
                    "name": "sap.suite.ui.generic.template.ListReport",
                    "list": true,
                    "settings": {
                           "tableSettings": {
                                  "multiEdit": {
                                         "enabled" : true
                                   }

                    }
```

**STEP**: 2 — Use FieldGroup annotation to select fields for multiEdit (recommended for performance)

**DESCRIPTION**: Provide a FieldGroup annotation (with a qualifier) and reference it from manifest.json via annotationPath. The DataFields in the FieldGroup define which fields appear in the multiEdit dialog. This is recommended to improve performance by explicitly enumerating editable fields.

**LANGUAGE**: JSON

**CODE**:
```json
"sap.ui.generic.app": {
        "_version": "1.1.0",
        "pages": [
            {
                "entitySet": "STTA_C_SO_SalesOrder_ND",
                "component": {
                    "name": "sap.suite.ui.generic.template.ListReport",
                    "list": true,
                    "settings": {
                           "tableSettings": {
                                  "multiEdit": {
                                         "enabled" : true,
                                         "annotationPath" : "com.sap.vocabularies.UI.v1.FieldGroup#MultiEdit"
                                   }
                    }
```

**LANGUAGE**: XML

**CODE**:
```xml
<Annotation Term="UI.FieldGroup" Qualifier="MultiEdit">
          <Record>
              <PropertyValue Property="Data">
                     <Collection>
                          <Record Type="UI.DataField">
                                <PropertyValue Property="Value" Path="NetAmount"/>
                          </Record>
                          <Record Type="UI.DataField">
                                <PropertyValue Property="Value" Path="TaxAmount"/>
                          </Record>
                          <Record Type="UI.DataField">
                           <PropertyValue Property="Value" Path="LifecycleStatus"/>
                          </Record>
                      </Collection>
            	</PropertyValue>
          </Record>
</Annotation>
```

**STEP**: 3 — Ignore specific fields from the mass edit dialog (key user adaptation)

**DESCRIPTION**: Exclude fields from being displayed in the mass edit dialog by adding an ignoredFields list in manifest.json. Provide comma-separated property names as the value. Use this to prevent specific properties from being added to the dialog.

**LANGUAGE**: JSON

**CODE**:
```json
manifest.json:
"tableSettings": {
                            "multiEdit": {
                                "enabled": true,
                                "annotationPath": "com.sap.vocabularies.UI.v1.FieldGroup#MultiEdit",
                                "ignoredFields":"NetAmount,TaxAmount" // comma separated values
                            }
}
```

**STEP**: 4 — Override the default dialog title

**DESCRIPTION**: The default dialog title is "Edit(X)". Override it by adding the MULTI_EDIT_DIALOG_TITLE key to the list report i18n file to customize the title displayed by the multiEdit dialog.

**LANGUAGE**: PlainText

**CODE**:
```
Add the resource key MULTI_EDIT_DIALOG_TITLE to the app's i18n properties file for the List Report.
```

**STEP**: 5 — Limitations and behavior

**DESCRIPTION**: Preserve these technical constraints and runtime behaviors when implementing multiEdit:
- Applicable table types: responsive tables and grid tables only.
- Not supported: smart multi-input fields, custom columns, and DataFieldForAnnotations.
- Only entity set properties (i.e., properties of the underlying entity) are supported for mass edit.
- Batch/update behavior: each selected instance is updated in a separate changeset within a single batch. If one or more selected instances fail during update, other instances in the batch are still executed.

**LANGUAGE**: PlainText

**CODE**:
```
- Tables supported: responsive table, grid table.
- Unsupported controls: smart multi-inputs, custom columns, DataFieldForAnnotations.
- Only entity set properties supported.
- Each selected instance is sent as a separate changeset within a single batch; failures for some instances do not stop updates for others.
```

**STEP**: 6 — Related resources

**DESCRIPTION**: Use these related documents for advanced customization (custom save, adding custom input fields, localization):

**LANGUAGE**: PlainText

**CODE**:
```
- Replacing the Standard Save Functionality in Mass Edit Dialog:
  replacing-the-standard-save-functionality-in-the-mass-edit-dialog-492d8a9.md

- Enabling Editing Using a Dialog (Mass Edit):
  enabling-editing-using-a-dialog-mass-edit-965ef5b.md

- Adding a Custom ViewExtension in the Mass Edit Dialog:
  adding-custom-input-fields-to-the-mass-edit-dialog-fd26fee.md

- Localization of UI Texts:
  localization-of-ui-texts-b8cb649.md
```

fiori-elements-framework list-report mass-edit multiEdit manifest.json FieldGroup annotation i18n ODataV2


**TITLE**: Enabling Inline Creation Mode and Empty Row Mode for Table Entries (Fiori Elements)

**INTRODUCTION**: Practical, code-focused guide to configure inline creation and empty-row creation modes for table entries in SAP Fiori Elements (OData V2 & V4). Includes required annotations, DefaultValuesFunction wiring, side effects, manifest.json settings, custom error message keys, and behavior toggles.

**TAGS**: fiori-elements, manifest.json, annotations, DefaultValuesFunction, InsertRestrictions, RequiredProperties, InlineCreation, creationRows, InlineCreationRows, side-effects, i18n

STEP: 1 — Choose creation mode and use-case
DESCRIPTION: Decide which creation mode suits your table. Use inline/empty-row modes only for tables with a small number of columns. For complex tables use a create page. Behavior summary:
- Inline Creation Mode: Add row inline, highlighted until saved; avoids automatic navigation.
- Empty Row Mode: A persistent empty row is shown (top for responsive tables, bottom for grid tables). No draft exists for the empty row until user inputs. Features: hidden row actions in empty row, no sorting/grouping for empty row; responsive table hides Create button; grid table shows Create and scrolls to empty row.
LANGUAGE: text
CODE:
```text
(Behavior summary; no code)
```

STEP: 2 — Annotate RequiredProperties for InsertRestrictions (XML)
DESCRIPTION: Mark required properties for insertion so empty-row/draft conversions require these fields. Use Capabilities.InsertRestrictions.RequiredProperties on the target entity (LineItem).
LANGUAGE: XML
CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.SalesOrderManage/_Item">
    <Annotation Term="Capabilities.InsertRestrictions">
        <Record Type="Capabilities.InsertRestrictionsType">
            <PropertyValue Property="RequiredProperties">
                <Collection>
                    <PropertyPath>RequestedQuantity</PropertyPath>
                    <PropertyPath>Material</PropertyPath>
                </Collection>
            </PropertyValue>
        </Record>
    </Annotation>
</Annotations>
```

STEP: 3 — Provide Default Values via DefaultValuesFunction (entity-level)
DESCRIPTION: Define a function import that returns default values and annotate the entity set with com.sap.vocabularies.Common.v1.DefaultValuesFunction to prefill empty rows.
LANGUAGE: XML
CODE:
```xml
<FunctionImport Name="GetDefaultsForRoot" ReturnType="cds_zrc_dv_defaultvalues.ZRC_DV_A_Create" m:HttpMethod="GET"/>

<Annotations xmlns=http://docs.oasis-open.org/odata/ns/edm Target="cds_zrc_dv_defaultvalues.cds_zrc_dv_defaultvalues_Entities/Root">
<Annotation Term="com.sap.vocabularies.Common.v1.DefaultValuesFunction" String="GetDefaultsForRoot"/>
</Annotations>
```

STEP: 4 — Provide Default Values via DefaultValuesFunction (navigation property / item-level)
DESCRIPTION: Create a function import for defaults when creating via a navigation property (item). Annotate the navigation property's target with DefaultValuesFunction.
LANGUAGE: XML
CODE:
```xml
<FunctionImport Name="GetDefaultsForItem" ReturnType="cds_zrc_dv_defaultvalues.ZRC_DV_A_Create" m:HttpMethod="GET" sap:action-for="cds_zrc_dv_defaultvalues.RootType">
<Parameter Name="UUID" Type="Edm.Guid" Mode="In"/>
</FunctionImport>

<Annotations xmlns=http://docs.oasis-open.org/odata/ns/edm Target="cds_zrc_dv_defaultvalues.RootType/to_Item">
<Annotation Term="com.sap.vocabularies.Common.v1.DefaultValuesFunction" String="GetDefaultsForItem"/>
</Annotations>
```

STEP: 5 — Recalculate default values when influencing properties change (SideEffects)
DESCRIPTION: If a property influences DefaultValuesFunction output, define SideEffects so the existing empty row gets recalculated. Use the navigation property that represents the table as TargetEntities.
LANGUAGE: plain
CODE:
```
SideEffects #TableIsRefreshed: {
      SourceProperties: [CustomerNumber],
      TargetEntities  : [_Item]
  }
```

STEP: 6 — Recalculate default values (XML annotation for SideEffects)
DESCRIPTION: Example of XML annotation syntax for Common.SideEffects with a Qualifier.
LANGUAGE: XML
CODE:
```xml
<Annotation Term="Common.SideEffects" Qualifier=" TableIsRefreshed ">
     <Record Type="Common.SideEffectsType">
          <PropertyValue Property="SourceProperties">
          <Collection>
          <PropertyPath>CustomerNumber</PropertyPath>
          </Collection>
          </PropertyValue>
          <PropertyValue Property="TargetEntities">
          <Collection>
          <NavigationPropertyPath>_Item</NavigationPropertyPath>
          </Collection>
     </Record>
</Annotation>
```

STEP: 7 — Configure createMode globally and per-page (OData V2 manifest.json sample)
DESCRIPTION: Configure createMode at app, object page, and section levels. Section-level createMode overrides page-level and app-level settings. Use section ID matching the annotation's ID when referencing sections.
LANGUAGE: JSON
CODE:
```json
{
  "sap.ui.generic.app" : {
    "_version" : "1.3.0",
    "settings" : {
      "tableSettings" : {
        "createMode" : " creationRows"   // Applicable to all tables in object page and sub object page.
      }
    },
    "pages" : {
      "ListReport|C_STTA_SalesOrder_WD_20" : {
        "entitySet" : "C_STTA_SalesOrder_WD_20",
        "component" : {
          "name" : "sap.suite.ui.generic.template.ListReport",
          "list" : true
        },
        "pages" : {
          "ObjectPage|C_STTA_SalesOrder_WD_20" : {
            "entitySet" : "C_STTA_SalesOrder_WD_20",
            "component" : {
              "name" : "sap.suite.ui.generic.template.ObjectPage",
              "settings" : {
                "createMode" : "inline",    // Applicable to all tables in the object page. Overrides the app level definition for create mode.
                "sections" : {
                  "to_Item::com.sap.vocabularies.UI.v1.LineItem" : {
                    "navigationProperty" : "to_Item",
                    "entitySet" : "C_STTA_SalesOrderItem_WD_20",
                    "createMode" : "newPage",     // Applicable to the table in the section. Overrides the object page and app level definition for create mode.
                    "tableSettings" : {
                      "inlineDelete" : true
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}
```

STEP: 8 — Toggle default inline-create row sorting (disableDefaultInlineCreateSort)
DESCRIPTION: In object page section settings, set disableDefaultInlineCreateSort=true to prevent new inline rows from being forced to the top in edit mode. Applicable only when createMode:"inline" is set.
LANGUAGE: JSON
CODE:
```json
"ObjectPage|STTA_C_MP_Product": {
                        "entitySet": "STTA_C_MP_Product",
                        "component": {
                            "name": "sap.suite.ui.generic.template.ObjectPage",
                            "settings": {
                                "showRelatedApps": true,
                                "tableType": "ResponsiveTable",
                                "editableHeaderContent": true,,
                                "sections": {
                                    "to_ProductText::com.sap.vocabularies.UI.v1.LineItem": {
                                        "navigationProperty": "to_ProductText",
                                        "entitySet": "STTA_C_MP_ProductText",
                                        "multiSelect": true,
                                        "createMode": "inline",
                                        "disableDefaultInlineCreateSort":true,
                                        "tableType": "ResponsiveTable"
                                    }
                                }
                            }
                        }
                   }
```

STEP: 9 — Custom error message key for empty required fields (i18n)
DESCRIPTION: Override the default "Enter a value" message by adding a key in your app's i18n file. Use the key format:
REQUIRED_PROP_ERROR|<EntitySet>|<navigationProperty>|com.sap.vocabularies.UI.v1.LineItem|<Required Property Name>
LANGUAGE: text
CODE:
```text
Example:
REQUIRED_PROP_ERROR|C_STTA_SalesOrder_WD_20|to_Item|com.sap.vocabularies.UI.v1.LineItem|so_item_pos=Enter an item position
```

STEP: 10 — Enable Inline creation mode in OData V4 manifest (ObjectPage controlConfiguration)
DESCRIPTION: For Fiori Elements OData V4, set creationMode "Inline" in controlConfiguration for the table. FieldControl=mandatory displays an asterisk in column header in edit mode.
LANGUAGE: JSON
CODE:
```json
"SalesOrderManageObjectPage":{
    "type": "Component",
    "id": "SalesOrderManageObjectPage",
    "name": "sap.fe.templates.ObjectPage",
    "options":{
        "settings":{
            ....
            ....
            "controlConfiguration":{
                "_Item/@com.sap.vocabularies.UI.v1.LineItem":{
                    "tableSettings": {
                        ....
                        ....
                        "creationMode":{
                            "name": "Inline",            // Results in Inline creation (default).
                            ...
                        }
                    }
                }
            }
        }
    }
}
```

STEP: 11 — Enable InlineCreationRows (empty row mode) and hide empty row in edit mode (OData V4)
DESCRIPTION: Use creationMode name "InlineCreationRows". Option inlineCreationRowsHiddenInEditMode (default false) hides the empty row in edit mode when true. Create button reveals/focuses the empty row when hidden.
LANGUAGE: JSON
CODE:
```json
"SalesOrderManageObjectPage":{
    "type": "Component",
    "id": "SalesOrderManageObjectPage",
    "name": "sap.fe.templates.ObjectPage",
    "options":{
        "settings":{
            ....
            ....
            "controlConfiguration":{
                "_Item/@com.sap.vocabularies.UI.v1.LineItem":{
                    "tableSettings": {
                        ....
                        ....
                        "creationMode":{
                            "name": "InlineCreationRows",
                            "inlineCreationRowsHiddenInEditMode": true
                        }
                    }
                }
            }
        }
    }
}
```

STEP: 12 — Set InlineCreationRows as default for all tables (OData V4 macros)
DESCRIPTION: Define a default creation mode at the app-level macros so all table macros use InlineCreationRows unless overridden per table.
LANGUAGE: JSON
CODE:
```json
"sap.fe": {
        …
        "macros": {
            "table": {
                "defaultCreationMode": "InlineCreationRows"
            }
        }
        …
    }
```

STEP: 13 — Show newly created objects at bottom for GridTable (createAtEnd)
DESCRIPTION: For GridTable, set creationMode.createAtEnd=true to append new inline-created objects at the bottom instead of top (default). Also set table type and personalization options if needed.
LANGUAGE: JSON
CODE:
```json
"controlConfiguration": {
    "@com.sap.vocabularies.UI.v1.LineItem": {
        "tableSettings": {
            "type": "GridTable",
            "personalization": {
                "column": true,
                "sort": false
            },
            "creationMode": {
                "name": "Inline",
                "createAtEnd": true
            }
        }
    }
}
```

STEP: 14 — Behavior notes & best practices
DESCRIPTION: Key operational notes to implement correctly:
- InsertRestrictions annotation controls whether table is insertable.
- If using a custom section ID, reference it in manifest (e.g., to_ProductText::com.sap.vocabularies.UI.v1.LineItem).
- For older NW 7.51 SP00 or lower using drafts: inline creation + filters may behave incorrectly.
- DefaultValuesFunction must be annotated on the entity set for empty-row prefill; use SideEffects for recalculation when influencing properties change.
- Set UI.Importance to High for RequiredProperties so required columns remain visible on small screens.
LANGUAGE: text
CODE:
```text
(Operational notes; no code)
```

fiori-elements manifest.json annotations DefaultValuesFunction InsertRestrictions RequiredProperties InlineCreation creationRows InlineCreationRows side-effects i18n


**TITLE**: Enable Lazy Loading for Custom Object Page Sections (Fiori elements, OData V2)

**INTRODUCTION**: Enable lazy loading for custom sections added via extension points on the SAP Fiori elements Object Page. Applicable only for Fiori elements with OData V2. This guide shows where to set the enableLazyLoading flag in your app's manifest.json and what to check before enabling it.

**TAGS**: fiori-elements-framework, lazy-loading, object-page, manifest.json, extension-points, OData V2, SAPUI5, ObjectPageLayout

STEP: 1 — Verify applicability and locate manifest.json

DESCRIPTION: Confirm your application uses SAP Fiori elements for OData V2 and locate the manifest.json file in your application root. Identify the extension point key under "sap.suite.ui.generic.template.ObjectPage.view.Details" corresponding to the custom section you added.

LANGUAGE: text

CODE:
```
manifest.json
// Ensure the app is Fiori elements for OData V2.
// Locate: "sap.suite.ui.generic.template.ObjectPage.view.Details" -> [YourExtensionPointKey]
```

STEP: 2 — Enable lazy loading for the custom extension point

DESCRIPTION: In manifest.json, under the object page view descriptor "sap.suite.ui.generic.template.ObjectPage.view.Details", set "enableLazyLoading": true inside the "sap.ui.generic.app" object for the extension point entry that defines your section (fragment). Keep the rest of the extension point configuration (className, fragmentName, type) unchanged.

LANGUAGE: JSON

CODE:
```json
"sap.suite.ui.generic.template.ObjectPage.view.Details": {
  "AfterFacet|STTA_C_MP_Producttext|ProductTextCollectionFacetID":{
    "className": "sap.ui.core.Fragment",
    "fragmentName": "STTA_MP.ext.fragments.ApplicationLogBreakout",
    "type": "XML",
    "sap.ui.generic.app": {
      "title": "{{xtit.applicationLog}}",
      "enableLazyLoading": true
    }
  },
```

STEP: 3 — Constraints, verification, and references

DESCRIPTION: Only enable lazy loading for sections that do not affect other sections or the object page header (inter-section dependencies or header updates may require immediate loading). Default standard sections are already lazy-loaded; apply this flag only to custom extension-point sections. After updating manifest.json, deploy or reload the app and verify the section loads on demand (check network and runtime loading of the fragment). For details and behavior, consult the ObjectPageLayout API and Fiori Design Guidelines.

LANGUAGE: text

CODE:
```
Checklist:
- Only set enableLazyLoading for independent custom sections.
- Do not enable for sections that update header or other sections.
- Test: Reload app, navigate to object page, confirm fragment is loaded on demand.
References:
- Fiori Design Guidelines: https://experience.sap.com/fiori-design-web/object-page/#structure
- ObjectPageLayout API: https://ui5.sap.com/#/api/sap.uxap.ObjectPageLayout
```

fiori-elements-framework
lazy-loading
object-page
manifest.json
extension-points
OData V2
SAPUI5
ObjectPageLayout


**TITLE**: Enable "Create Object" Dialog in List Report (OData V2 & V4)

**INTRODUCTION**: This guide shows how to enable creation of new entities using a dialog in SAP Fiori List Report pages for both OData V2 and OData V4. It includes exact manifest.json configuration snippets, required constraints, and i18n keys to customize dialog title and buttons. Use these snippets verbatim and ensure the specified fields are valid properties of the target entity set.

**TAGS**: manifest.json, ListReport, createWithParameterDialog, creationMode, ODataV2, ODataV4, i18n, SAP Fiori Elements

STEP: 1 — Enable create dialog in List Report (OData V2)

DESCRIPTION:
- Add the createWithParameterDialog property under the table settings for the List Report page in manifest.json.
- Provide the fields object mapping dialog field names to entity property paths. Keep the dialog fields to a maximum of 8 data fields.
- Ensure all mandatory properties of the entity are present in the fields list.
- Limitations: You cannot navigate to an object page in create mode after enabling this; draft state is not maintained; only list report pages support this. If backend returns state messages on create, each message must include a target pointing to the respective field.

LANGUAGE: JSON

CODE:
```json
"createWithParameterDialog" : {
               "fields" : {
                  "<fieldName>" : {"path":"<fieldname>"},
                  "<fieldName>" : {"path":"<fieldname>"}
             }
```

STEP: 2 — Full manifest.json example for OData V2 List Report

DESCRIPTION:
- Place the following example under "sap.ui.generic.app" -> "pages" for the ListReport page that targets your entity set.
- The snippet shows createWithParameterDialog under tableSettings -> createWithParameterDialog -> fields with explicit property mappings.

LANGUAGE: JSON

CODE:
```json
"sap.ui.generic.app": {
    "_version": "1.3.0",
    "pages": {
        "ListReport|STTA_C_SO_SalesOrder_ND": {
            "entitySet": "STTA_C_SO_SalesOrder_ND",
            "component": {
                "name": "sap.suite.ui.generic.template.ListReport",
                "list": true,
                "settings": {
                    "multiSelect": true,
                    "isWorklist": true,
                    "tableSettings": {
                        "createWithParameterDialog" : {
                            "fields" : {
                                "BusinessPartnerID":{"path": "BusinessPartnerID"},
                                "CurrencyCode" : {"path":"CurrencyCode"},
                                "BillingStatus" : {"path":"BillingStatus"},
                                "DeliveryStatus" : {"path":"DeliveryStatus"},
                                "OpportunityID" : {"path":"OpportunityID"}
                            }
                        }
                    }
                }
            },
            "pages": {
                ..............
                ..............
            }
        }
    }
}
```

STEP: 3 — Enable create dialog in multi-view (OData V2) per-variant

DESCRIPTION:
- For multi-view list reports (quickVariantSelectionX), specify createWithParameterDialog inside the tableSettings for the variant where you want the dialog available.
- This example shows a variant ("1") with tableSettings containing createWithParameterDialog.

LANGUAGE: JSON

CODE:
```json
"sap.ui.generic.app": {
    "pages": {
        "ListReport|STTA_C_SO_SalesOrder_ND": {
            "entitySet": "C_STTA_SalesOrder_WD_20",
            "component": {
                "name": "sap.suite.ui.generic.template.ListReport",
                "list": true,
                "settings": {
                    "quickVariantSelectionX": {
                        "showCounts": true,
                        "variants": {
                            "0": {
                                "key": "_tab1",
                                "annotationPath": "com.sap.vocabularies.UI.v1.SelectionVariant#Expensive"
                            },
                            "1": {
                                "key": "_tab2",
                                "annotationPath": "com.sap.vocabularies.UI.v1.SelectionPresentationVariant#Cheap",
                                "tableSettings": {
                                    "createWithParameterDialog": {
                                        "fields": {
                                            "bp_id": { "path": "bp_id" },
                                            "currency_code": { "path": "currency_code" },
                                            "op_id": { "path": "op_id" }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            },
            ...
        }
    }
}
```

STEP: 4 — OData V2: Dialog behavior and constraints (Action items)

DESCRIPTION:
- Ensure the specified fields exist in the entity type and include all mandatory fields.
- You can prefill dialog fields from filter values using the extension point (see platform docs on prefilling fields).
- If backend returns state messages after Create, each message must provide a target mapping so the UI can display the message on the correct field.
- Dialog title default key (i18n): CREATE_DIALOG_TITLE. Change in your i18n file or via Adaptation Editor.
- Default dialog buttons are "Create" and "Cancel" — changeable via Adaptation Editor.

LANGUAGE: Properties

CODE:
```properties
# i18n.properties (OData V2)
CREATE_DIALOG_TITLE=New Object
```

STEP: 5 — Enable create dialog in List Report (OData V4)

DESCRIPTION:
- For OData V4 List Report, use the creationMode setting in manifest.json under the page target options -> settings -> controlConfiguration -> @com.sap.vocabularies.UI.v1.LineItem -> tableSettings.
- Set creationMode.name to "CreationDialog" and specify creationFields either as:
  - an annotation path to a FieldGroup (e.g., com.sap.vocabularies.UI.v1.FieldGroup#CreationParameters), or
  - a comma-separated list of properties.
- Immutable properties are automatically included in creationFields.
- Place per-view creationMode settings in the TableSettings for each line item in multi-view mode.

LANGUAGE: JSON

CODE:
```json
"targets": {
    "ProductsList": {
        "type": "Component",
        "name": "sap.fe.templates.ListReport",
        "id": "ProductsList",
        "options": {
            "settings": {
                "contextPath": "/Products",
                "controlConfiguration": {
                    "@com.sap.vocabularies.UI.v1.LineItem": {
                        "tableSettings": {
                            "creationMode": {
                                "name": "CreationDialog",
                                "creationFields": "com.sap.vocabularies.UI.v1.FieldGroup#CreationParameters"
                            }
                        }
                    }
                },
                ...
            }
        }
    },
```

STEP: 6 — OData V4: Behavior, constraints, and customization

DESCRIPTION:
- Limitations: cannot navigate to an object page in create mode; draft state not maintained for dialog-created objects; navigation properties are not supported in the create dialog.
- Mandatory fields are marked with a red asterisk in the dialog. Ensure they are included in creationFields.
- To customize the dialog title for OData V4, add or override the i18n key C_TRANSACTION_HELPER_SAPFE_ACTION_CREATE in the page’s i18n file.

LANGUAGE: Properties

CODE:
```properties
# i18n.properties (OData V4)
C_TRANSACTION_HELPER_SAPFE_ACTION_CREATE=New Object
```


**TITLE**: Enable Object Creation via Creation Dialog on Object Page (OData V4)

**INTRODUCTION**: Configure the Object Page to allow creating new entities using a modal dialog instead of navigating to a create page. Applicable only for SAP Fiori elements with OData V4. Edit manifest.json to set creationMode for the table control configuration and optionally localize the dialog title via the page i18n file.

**TAGS**: sap-fiori, fiori-elements, odata-v4, manifest.json, object-page, creation-dialog, ui5, sap.fe

STEP: 1 — Enable creation dialog in the Object Page manifest

DESCRIPTION: Add a creationMode configuration to the table control within the Object Page target in manifest.json. Set creationMode.name to "CreationDialog" and set creationFields to either a FieldGroup annotation reference or a comma-separated list of properties. This example targets the Suppliers line item under Products.

LANGUAGE: JSON

CODE:
```json
"targets": {
    "ProductsList": {
        "type": "Component",
        "name": "sap.fe.templates.ObjectPage",
        "id": "ProductsObjectPage",
        "options": {
            "settings": {
                "contextPath": "/Products",
                "controlConfiguration": {
                    "_suppliers/@com.sap.vocabularies.UI.v1.LineItem": {
                        "tableSettings": {
                            "creationMode": {
                                "name": "CreationDialog",
                                "creationFields": "com.sap.vocabularies.UI.v1.FieldGroup#CreationParametersSupplier"
                            }
                        }
                    }
                },
                ...
            }
        }
    }
}
```

STEP: 2 — Specify creationFields (FieldGroup or property list)

DESCRIPTION: The creationFields value can be:
- A FieldGroup annotation reference (recommended) — use the fully qualified annotation path plus fragment (e.g., com.sap.vocabularies.UI.v1.FieldGroup#CreationParametersSupplier).
- A comma-separated list of property names (e.g., "Name,Category,Price").

Immutable properties are automatically added to the dialog fields even if not included in creationFields.

LANGUAGE: JSON

CODE:
```json
// Example: creationFields as a comma-separated property list
"creationMode": {
    "name": "CreationDialog",
    "creationFields": "Name,Category,Price"
}
```

STEP: 3 — Behavior and limitations

DESCRIPTION: Key behavioral points you must account for in code/design:
- This feature is only supported for OData V4 (do not enable for OData V2).
- When creation dialog is enabled, users cannot navigate to an Object Page in create mode; they can navigate to the page in display mode and modify entities.
- Filter-based prefill is supported: if filter values are entered to prefill fields, creation via dialog will honor those prefilled values.
- Mandatory parameters are shown with a red asterisk in the dialog (handled by UI framework).
- Navigation properties are not supported inside the creation dialog (do not include navprops in creationFields).
- For related functionality see: enabling a create dialog in the List Report or custom create dialog on Tree Table.

LANGUAGE: text

CODE:
```text
Notes:
- OData V4 only.
- No navigation-to-create page when dialog enabled.
- Immutable properties auto-added.
- Navigation properties unsupported for dialog.
```

STEP: 4 — Customize the dialog title via i18n

DESCRIPTION: Override the default dialog title "New Object" by adding/overriding the i18n key C_TRANSACTION_HELPER_SAPFE_ACTION_CREATE in the page i18n properties file (i18n.properties). The framework uses this key to display the creation dialog title.

LANGUAGE: Properties

CODE:
```properties
# i18n.properties (page-level)
C_TRANSACTION_HELPER_SAPFE_ACTION_CREATE=Create Supplier
```


**TITLE**: Enabling Quick Views for Link Navigation (OData V2 & V4)

**INTRODUCTION**: This guide shows the exact annotation steps to enable Quick Views for link navigation in SAP Fiori Elements. It covers how to identify the semantic object, locate the referential constraint or semantic key, and annotate the association end type with UI.QuickViewFacets (examples for XML annotations, ABAP CDS, and CAP CDS are included). Use these steps to generate the quick view content displayed in popovers for semantic-object links.

**TAGS**: fiori-elements-framework, quick-view, UI.QuickViewFacets, SemanticObject, annotations, odata-v2, odata-v4, ABAP-CDS, CAP-CDS, XML, metadata

STEP: 1 — Identify the property annotated as a SemanticObject (source property shown as link)

DESCRIPTION: Locate the property on the source entity that is annotated as a semantic object. Keep the annotation in the service metadata and/or CDS. Use either XML annotation, ABAP CDS or CAP CDS depending on your stack.

LANGUAGE: XML
CODE:
```xml
<Annotations Target="STTA_PROD_MAN.STTA_C_MP_ProductType/Supplier">
   <Annotation Term="Common.SemanticObject" String="EPMProduct"/>
</Annotations>
```

LANGUAGE: ABAP CDS
CODE:
```abap
annotate view STTA_C_MP_PRODUCT with {
  @Consumption.semanticObject: 'EPMProduct'
  supplier;
}ABAP CDS
```

STEP: 2 — Locate the association and referential constraint in metadata (identify association end type)

DESCRIPTION: In the service metadata, find the Association / NavigationProperty that contains a ReferentialConstraint referencing the identified source property (Dependent). This tells you the association end type to annotate with QuickViewFacets.

LANGUAGE: XML (metadata)
CODE:
```xml
<Association Name="assoc_2CCAF987BA334B3BD1DF2404F50BC9C5" sap:content-version="1">
    <End Type="STTA_PROD_MAN.STTA_C_MP_ProductType" Multiplicity="1" Role="FromRole_assoc_2CCAF987BA334B3BD1DF2404F50BC9C5"/>
    <End Type="STTA_PROD_MAN.STTA_C_MP_SupplierType" Multiplicity="0..1" Role="ToRole_assoc_2CCAF987BA334B3BD1DF2404F50BC9C5"/>
    <ReferentialConstraint>
        <Principal Role="ToRole_assoc_2CCAF987BA334B3BD1DF2404F50BC9C5">
            <PropertyRef Name="Supplier"/>
        </Principal>
        <Dependent Role="FromRole_assoc_2CCAF987BA334B3BD1DF2404F50BC9C5">
            <PropertyRef Name="Supplier"/>
        </Dependent>
    </ReferentialConstraint>
</Association>
```

STEP: 3 — Annotate UI.QuickViewFacets on the association end type (OData V2 example)

DESCRIPTION: Annotate the target entity (association end type) with UI.QuickViewFacets and define a UI.FieldGroup qualifier that contains UI.DataField entries for the quick view content. Use XML or ABAP CDS examples below.

LANGUAGE: XML
CODE:
```xml
<!-- QuickViewFacets annotation for Supplier-->

<Annotations Target="STTA_PROD_MAN.STTA_C_MP_SupplierType">
    <Annotation Term="UI.QuickViewFacets">
        <Collection>
            <Record Type="UI.ReferenceFacet">
                <PropertyValue Property="Target" AnnotationPath="@UI.FieldGroup#SupplierQuickViewPOC_FieldGroup_1" />
            </Record>
        </Collection>
    </Annotation>
    <Annotation Term="UI.FieldGroup" Qualifier="SupplierQuickViewPOC_FieldGroup_1">
        <Record>
            <PropertyValue Property="Data">
                <Collection>
                    <Record Type="UI.DataField">
                        <PropertyValue Property="Label" String="Company Name" />
                        <PropertyValue Property="Value" Path="CompanyName"/>
                    </Record>
                    <Record Type="UI.DataField">
                        <PropertyValue Property="Label" String="Supplier" />
                        <PropertyValue Property="Value" Path="Supplier"/>
                    </Record>
                    <Record Type="UI.DataField">
                        <PropertyValue Property="Label" String="Email Address" />
                        <PropertyValue Property="Value" Path="EmailAddress"/>
                    </Record>
                </Collection>
            </PropertyValue>
        </Record>
    </Annotation>
</Annotations>
```

LANGUAGE: ABAP CDS
CODE:
```abap
annotate view STTA_C_MP_SUPPLIER with {
@UI.Facet: [
  {
    targetQualifier: 'SupplierQuickViewPOC_FieldGroup_1',
    type: #FIELDGROUP_REFERENCE,
    purpose: #QUICK_VIEW
  }
]
@UI.fieldGroup: [
  {
    label: 'Company Name',
    value: 'COMPANYNAME',
    type: #STANDARD,
    position: 1 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_1'
  }
]
companyname;
@UI.fieldGroup: [
  {
    label: 'Supplier',
    value: 'SUPPLIER',
    type: #STANDARD,
    position: 2 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_1'
  }
]
supplier;
@UI.fieldGroup: [
  {
    label: 'Email Address',
    value: 'EMAILADDRESS',
    type: #STANDARD,
    position: 3 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_1'
  }
]
emailaddress;
}
```

STEP: 4 — Define semantic object and associations (OData V4 variations)

DESCRIPTION: For OData V4 you can define the SemanticObject as a string, path or EdmJson expression. Then define an association and a foreign-key association (or navigation property with referential constraint). The association/navigation points to the entity you will annotate with UI.QuickViewFacets.

LANGUAGE: XML (SemanticObject string)
CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.ProductSupplier/Supplier">
   <Annotation Term="Common.SemanticObject" String="EPMSupplier"/>
</Annotations>
```

LANGUAGE: ABAP CDS
CODE:
```abap
annotate view ProductSupplier with {
  @Consumption.semanticObject: 'EPMSupplier'
  Supplier;
}
```

LANGUAGE: CAP CDS
CODE:
```cds
annotate ProductSupplier with {
Supplier @Common.SemanticObject: 'EPMSupplier';
}
```

LANGUAGE: XML (SemanticObject via Path)
CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.ProductSupplier/Supplier">
             <Annotation Term="Common.SemanticObject" Path="SupplierSemanticObject"/>
</Annotations>
```

LANGUAGE: XML (SemanticObject via EdmJson expression)
CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.ProductSupplier/Supplier">
           <Annotation Term="Common.SemanticObject">
               <If>
                  <Eq>
                      <Path>SupplierType</Path>
                      <Int>2</Int>
                  </Eq>
                  <String>EPMSupplier</String>
                  <String>ERPSupplier</String>
               </If>
            </Annotation>
</Annotations>
```

LANGUAGE: ABAP CDS (association + foreign-key)
CODE:
```abap
association [1..1] to I_Supplier as _Supplier on  $projection.Supplier = _Supplier.Supplier
...
@ObjectModel.foreignKey.association: '_Supplier'
Supplier,
```

LANGUAGE: XML (NavigationProperty with ReferentialConstraint)
CODE:
```xml
<NavigationProperty Name="_Supplier" Type="com.c_salesordermanage_sd.I_Supplier">
    <ReferentialConstraint Property="Supplier" ReferencedProperty="Supplier"/>
</NavigationProperty>
```

LANGUAGE: XML (Common.ReferentialConstraint annotation)
CODE:
```xml
<Annotations Target=" com.c_salesordermanage_sd.ProductSupplier/_Supplier">
    <Annotation Term="Common.ReferentialConstraint">
        <Collection>
            <Record>
                <PropertyValue Property="Property" PropertyPath="Supplier"/>
                <PropertyValue Property="ReferencedProperty" PropertyPath="_Supplier/Supplier"/>
            </Record>
        </Collection>
    </Annotation>
</Annotations>
```

STEP: 5 — Annotate UI.QuickViewFacets on association end type for OData V4 (referential constraint case)

DESCRIPTION: Annotate the target entity (association end type) with QuickViewFacets and a FieldGroup for quick view content. Examples for XML, ABAP CDS and CAP CDS are provided.

LANGUAGE: XML
CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.I_Supplier">
<Annotation Term="UI.QuickViewFacets">
   <Collection>
    <Record Type="UI.ReferenceFacet">
      <PropertyValue Property="Label" String="Address"/>
      <PropertyValue Property="Target" AnnotationPath="@UI.FieldGroup#SupplierQuickView"/>
    </Record>
   </Collection>
</Annotation>
<Annotation Term="UI.FieldGroup" Qualifier="SSupplierQuickView">
   <Record Type="UI.FieldGroupType">
     <PropertyValue Property="Data">
      <Collection>
       <Record Type="UI.DataField">
        <PropertyValue Property="Value" Path="PostalCode"/>
       </Record>
       <Record Type="UI.DataField">
        <PropertyValue Property="Value" Path="CityName"/>
       </Record>
       <Record Type="UI.DataField">
        <PropertyValue Property="Value" Path="Country"/>
       </Record>
      </Collection>
     </PropertyValue>
   </Record>
</Annotation>
</Annotations>
```

LANGUAGE: ABAP CDS
CODE:
```abap
annotate view I_Supplier with {
@UI.Facet: [
  {
    label: 'Address',
    targetQualifier: 'SupplierQuickView',
    type: #FIELDGROUP_REFERENCE,
    purpose: #QUICK_VIEW
  }
]
@UI.fieldGroup: [
  {
    value: 'PostalCode',
    type: #STANDARD,
    position: 1 ,
    qualifier: 'SupplierQuickView'
  }
]
PostalCode;
@UI.fieldGroup: [
  {
    value: 'CityName',
    type: #STANDARD,
    position: 2 ,
    qualifier: 'SupplierQuickView'
  }
]
CityName;
@UI.fieldGroup: [
  {
    value: 'Country',
    type: #STANDARD,
    position: 3 ,
    qualifier: 'SupplierQuickView'
  }
]
Country;
}
```

LANGUAGE: CAP CDS
CODE:
```cql
annotate schema.I_Supplier with @(UI : {
QuickViewFacets             : [
    {
        $Type  : 'UI.ReferenceFacet',
        Label  : 'Address',
        Target : '@UI.FieldGroup#SupplierQuickView'
    }
],
FieldGroup #SupplierQuickView:{Data : [
    {
        $Type : 'UI.DataField',
        Value : PostalCode
    },
    {
        $Type : 'UI.DataField',
        Value : CityName
    },
    {
        $Type : 'UI.DataField',
        Value : Country
    }
]}
})
```

STEP: 6 — Quick view when target property is a semantic key or entity key (alternative approach)

DESCRIPTION: If the target property is a semantic key or an entity key, you can define an association on the source entity, annotate the navigation property with SemanticObject, ensure the target entity has a semantic key or entity key, and then annotate UI.QuickViewFacets on the target entity. Examples below use CAP CDS, ABAP CDS, XML and CAP CDS quick-view annotations.

LANGUAGE: CAP CDS
CODE:
```cql
entity ProductSupplier {
     CustomerReference: String;
     _NavigationProperty: Association to Customer
          on _NavigationProperty.Customer = CustomerReference @(Common : {
               SemanticObject             : 'Customer'
           });
}
```

LANGUAGE: CAP CDS (define target semantic key and key)
CODE:
```cql
annotate Customer with @(
     //…
     Common.SemanticKey : [CustomerName],
     //…
) {
 key Customer: String;
     CustomerName: String;
}
```

LANGUAGE: XML (QuickViewFacets on Customer)
CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.Customer">
    <Annotation Term="UI.QuickViewFacets">
        <Collection>
            <Record Type="UI.ReferenceFacet">
                <PropertyValue Property="Label" String="Address" />
                <PropertyValue Property="Target" AnnotationPath="@UI.FieldGroup#SoldToQuickView" />
            </Record>
        </Collection>
    </Annotation>
    <Annotation Term="UI.FieldGroup" Qualifier="SoldToQuickView">
        <Record Type="UI.FieldGroupType">
            <PropertyValue Property="Data">
                <Collection>
                    <Record Type="UI.DataField">
                        <PropertyValue Property="Value" Path="PostalCode" />
                    </Record>
                    <Record Type="UI.DataField">
                        <PropertyValue Property="Value" Path="CityName" />
                    </Record>
                    <Record Type="UI.DataField">
                        <PropertyValue Property="Value" Path="Country" />
                    </Record>
                </Collection>
            </PropertyValue>
        </Record>
    </Annotation>
</Annotations>
```

LANGUAGE: ABAP CDS
CODE:
```abap
annotate view CUSTOMER with {
@UI.Facet: [
  {
    label: 'Address',
    targetQualifier: 'SoldToQuickView',
    type: #FIELDGROUP_REFERENCE,
    purpose: #QUICK_VIEW
  }
]
@UI.fieldGroup: [
  {
    value: 'POSTALCODE',
    type: #STANDARD,
    position: 1 ,
    qualifier: 'SoldToQuickView'
  }
]
postalcode;
@UI.fieldGroup: [
  {
    value: 'CITYNAME',
    type: #STANDARD,
    position: 2 ,
    qualifier: 'SoldToQuickView'
  }
]
cityname;
@UI.fieldGroup: [
  {
    value: 'COUNTRY',
    type: #STANDARD,
    position: 3 ,
    qualifier: 'SoldToQuickView'
  }
]
country;
}
```

LANGUAGE: CAP CDS (QuickViewFacets on Customer)
CODE:
```cql
annotate schema.Customer with @(UI : {
QuickViewFacets             : [
    {
        $Type  : 'UI.ReferenceFacet',
        Label  : 'Address',
        Target : '@UI.FieldGroup#SoldToQuickView'
    }
],
FieldGroup #SoldToQuickView: {Data : [
    {
        $Type : 'UI.DataField',
        Value : PostalCode
    },
    {
        $Type : 'UI.DataField',
        Value : CityName
    },
    {
        $Type : 'UI.DataField',
        Value : Country
    }
]}
})
```

STEP: 7 — Add DataField on UI.LineItem / UI.FieldGroup / UI.Identification pointing to navigation property

DESCRIPTION: To render the link that shows the quick view on the source UI annotations, add a UI.DataField that references the navigation property path to the target property (use in LineItem, FieldGroup or Identification).

LANGUAGE: XML
CODE:
```xml
<Record Type="UI.DataField">
    <PropertyValue Property="Value" Path="_NavigationProperty/Customer" />
</Record>
```

STEP: 8 — Notes & behavior

DESCRIPTION: QuickViewFacets must be annotated on entity types within the same service (referential constraints reference only same-service entity types). If the user cannot navigate to the target application, no link is displayed. For configuration options and system behavior, refer to "Configuring the Content of Quick Views".

fiori-elements-framework quick-view UI.QuickViewFacets SemanticObject annotations odata-v2 odata-v4 ABAP-CDS CAP-CDS XML metadata