Metadata properties - ReadOnly, AllowEdit, Mandatory

This article covers the behavioral properties of metadata for ReadOnly, AllowEdit, and Mandatory.

Behavioral properties on data entities

Each data entity has certain properties that give you the option to override the same property values on the tables or views that are the data sources of the entity. Your choices affect the behaviors of the entity. In the following table, the left column lists the properties that are discussed in this topic. The top row lists the level where the property is found in entity designer. The data source level is more granular than the entity level and less granular than the field level. You can find a complete list of properties by examining the data entity in Visual Studio.

Property Entity level Data source level Field level
ReadOnly Applies Applies
AllowEdit Applies
AllowEditOnCreate Applies
Mandatory Applies

Entity level

In the designer for your data entity, when you click the name at its root node, the Properties pane includes the Is Read Only property. The following table describes the behavioral differences between the Yes and No values.

Group Property name Display name Values Default Description
Behavior IsReadOnly Is Read Only No, Yes No
  • No – Data modification operations (CUD) are allowed, unless an individual data source node in the entity’s designer is set to IsReadOnly = Yes.
  • YesOnly read operations are allowed, regardless of the IsReadOnly settings on the individual data source nodes in the entity’s designer.

IsReadOnly = Yes would be used for entities that would be consumed mainly for export.

Data source level

When a data entity has three data sources, you might want to enable processes to use the entity to modify the data in only one of the data sources while disallowing data modification for the remaining data sources. A read-only data source would be used for lookup purposes. You can use the entity designer to achieve this extra degree of granular control. Under the entity’s Metadata > Data Sources node, you can highlight any entity node and then set the IsReadOnly property value for that data source. The following table describes the interaction between the IsReadOnly settings at the data source level versus the entity level.

Group Property name Display name Values Default Description
Behavior IsReadOnly Is Read Only No, Yes No
  • No – Data modification operations (CUD) are allowed on the data source, unless IsReadOnly = Yes is set at the entity level.
  • YesOnly read operations are allowed, regardless of the IsReadOnly setting on the entity.

Scenario

Suppose the FMCustomerEntity entity has a second data source of FMCustGroup. Additionally, the FMCustomer table has a foreign key field named CustGroup that references the FMCustGroup, and the relation is N:1. Because the entity is for a customer, it's reasonable to allow use of the entity for data modifications to the FMCustomer data source. However, FMCustGroup is added as a data source for lookup to allow surrogate foreign key (SFK) expansion to the natural key. When a customer is inserted/updated, the intention isn't to insert/update attributes on customer group. In this scenario, you set IsReadOnly = No at the entity level and FMCustomer data source level. In the entity designer, at the data source level, you set IsReadOnly = Yes on the FMCustGroup. In this scenario, an entity field from the FMCustGroup data source, such as the CustomerGroupDescription field, isn't updatable through the entity. However, entity fields from FMCustomer can be updated through the entity.

Field level

At the field level, the AllowEdit and AllowEditOnCreate properties are available in place of an IsReadOnly property. The two Allow\* properties add Auto as a third available value. The Auto value inherits the value that is on the field in the underlying table. Note: The Auto value isn't available for unmapped fields (that is, computed or virtual fields).

Group Property name Display name Value Default Description
Behavior AllowEditOnCreate Allow edit on create Auto, No, Yes Auto
  • Auto – Inherit the property from the underlying table field. Note: The Auto value isn't available for unmapped fields (computed or virtual fields).
  • No – Users are not allowed to modify the data for this field in a new record.
  • Yes – Users are allowed to modify the data for this field for a new record.
This is enforced for all consumers (X++, OData, and so on). Important: A value of No or Yes does not override the setting on the field in the underlying table. If entity values are less restrictive than table fields, a BP warning is thrown.
Behavior AllowEdit Allow edit Auto, No, Yes Auto The same as for AllowEditOnCreate, except it applies to updates to existing records instead of new records that are being created. This is enforced for all consumers (X++, OData, and so on).
Behavior Mandatory Mandatory Auto, No, Yes Auto Auto – Inherit the property from the underlying table field. This is enforced for all consumers (X++, OData, and so on).Important: A value of No or Yes does not override the setting on the field in the underlying table.