Data Validity provides framework support for restricting the usage of data records. This functionality is only applicable when user creates or modifies a record and refers to a record in an entity with data validity. It does not restrict accessing the records from its own client window. Users who have the access to the Data Validity enabled basic data can do the modifications related to data validity. To learn the concept and how to model data validity, please refer modeling Data Validity in server
Client framework has provided basic support to achieve some behaviors related to data validity and those are discussed in this article.
To perform state transition in State Based Validity model, the developer can write his own state transition logic or enable state transition context Menu options provided by the framework. To enable framework support, the developer should first set the Foundation1 property "state machine" to true, and then add the new FndDataValidity decoration to the form as in below example:
[FndDataValidity(FndDataValidityMode.ActiveHiddenBlocked)] public partial class tbwAdditionalCostTypes : cTableWindow { //Logic inside class }
If developers need to add decorations targeting child tables, they still can do it as in following example. Keep in mind that it is possible to have multiple decorations together as well.
[FndDataValidity(FndDataValidityMode.ActiveHidden)] [FndDataValidity(FndDataValidityMode.ActiveHiddenBlocked, "tblFormulaVariable")] public partial class frmFormula : cFormWindow { //Logic inside class }
Depending on the flavor of the state based validity used, developer should select the correct FndDataValidityMode during decorating process. It could be ActiveBlocked, ActiveHidden or ActiveHiddenBlocked.
The code above will add new sub menu called ‘Change Validity’ in to standard context menu options of the window as in following example:
If developer wants to create his own state transition menus, they can be created following the standard guidelines to add state transitions for context menus.
If the modeling Data Validity in server has been properly done, developer has to add two columns with "Valid From" and "Valid To" to the Client Form. Then the date range values can be specified as below mentioned example.
In the Date Interval Based Validity model, during the validity check, Date range of an entity is compared against a particular date column in the referring entity (or the SYSDATE depending on how it is modeled). This date column will get reflected as the 'LOV Time Reference' property of the referring entity's column where the original entity's view is set as LOV Reference. This property will get its value automatically from the 'ValidityIntervalRefColumn' value in the model. Developer can change the F1 property to point to a different date column but this will be a rare occurrence. For more information on Date Interval based validity, please refer modeling Data Validity in server
Example:
In the above case, DISCOUNT_TYPE entity incorporates Date Interval based validity model and it is connected to DEMO_SALES_ORDER entity's closDiscount's LOV Reference. The data in the DISCOUNT_TYPE entity is filtered for LOV using the ORDER_DATE column value of the ORDER entity for a given record.
When LOV is used to refer an entity modeled with Data Validity, the data shown in the LOV dialog gets filtered out according to the validity model. In the case of State Based Validity, the LOV defaults to showing 'Active' records only. In the case of Date Interval Based Validity, the LOV will show records that falls within the desired date range.
One visible change in the LOV dialog when referring to a entity modeled with state based validity is the new 'Show Hidden' check-box as seen in the following image.
By selecting 'Show Hidden' checkbox, the end-user can override filtering and make both Active and Hidden records visible. However, LOV dialog will not list records with Blocked state in any case. When it comes to date interval based validity, no additional checkbox will get visible and the user will not be able to select record that falls outside the range.
The access to 'Show Hidden' checkbox can be restricted if needed. In order to be able to use the checkbox, the user must have been granted presentation object EE_SHOW_HIDDEN_CHECKBOX. Without the grant, the checkbox will be disabled.
To let records in Blocked state be listed in the LOV, message PM_DataItemValidityShowBlocked can be intercepted and overridden to return TRUE. The message default is FALSE.
This section discusses special cases that can lead to problems and how to resolve them
When introducing Data Validity to a Lookup type entity, developers must make sure to set the 'Lookup' flag true for the controls that refer lookup type entity. If the new 'Lookup' flag is set, framework will invoke 'Enum Method' specified for the control in its F1 properties. Failing to do so may leads to wrong enumeration values being displayed in the control.
Example:
Here, 'controls' refers to cComboBox, cLookupColumn, cComboBoxMultiSelection, cMultiSelectionColumn or any other control that derives from these controls.