Decision Filters
Learn about the use of decision filters.
Decision filters can be used for the following purposes:
- To use different field groups in the quick add based on the source data of a single article.
- To use different MiniDetails actions or default actions based on the record's data in a
RecordListView.
- To define quick actions for objectives.
A Decision filter has several sub-info area nodes of the same info area, each with conditions and properties.
Example: Decision Filter for the Quick Add
You can specify a Decision filter in the new FieldGroupDecider
input
argument (Serialentry
action call).
In the following example, items with an Item No. between 1000 and 1999 does not apply
the field group defined in the SerialEntry
action call but the ones
defined in the following Decision filter (i. e. AR2, UP2, and LP2).
The SourceFG
(AR2), DestFG
(UP2) and
DestChildFG
(LP2) parameters are applied to all items within the
Item No. range from 1000 to1999. These parameters override the "default" field group
assigned in the SerialEntry
action call.
You can also define multiple sub-info area nodes for multiple conditions.
You can define the following parameters:
-
Parameter:SourceFG
: OverridesSourceConfigName
(List-Control) -
Parameter:DestFG
: OverridesDestinationConfigName
(Edit-Control) -
Parameter:SourceChildFG
: OverridesSouceChildConfigName
(List-Control) -
Parameter:DestChildFG
: OverridesDestinationChildConfigName
(Edit-Control)
Decision filters only affect the display of data, the quick add business logic remains unchanged and is still defined in the field groups and in the action calls:
- All fields must exist in both, the field groups referenced by the filter and the ones assigned in the action. Fields that do not exist in the field group assigned in the action call are ignored.
- If fields are only needed for the filter, you can set the Hide Field field attribute in the field group.
- Function names and the Don't save and Don't save offline field attributes cannot be overridden by a Decision filter.
- You can define different (alternative) labels.
Example: Decision Filters for RecordListview
Decision filters can be specified in the DetailActionSwitchFilterName
input argument (RecordListView
action call).
In this example, the record's default actions are based on the ABC field's value. The defined default actions used are applied to the corresponding records. Additionally, for "C" companies an additional quick action is available in the MiniDetails.
You can define the following parameters:
-
Parameter
:DefaultAction
: Defines the alternative default action (context menu action) that is executed instead of the standard default action. -
Parameter
:DefaultActionButton
: Defines the alternative button instead of the default button. The action assigned to this button is executed. -
Parameter
:Action
: Defines one or more context menu action that are displayed as additional quick actions for the MiniDetails. -
Parameter
:ButtonAction
: Defines the buttons that are displayed additionally in the MiniDetails.
Decision Filters in Quick Actions for Objectives
If you use Decision filters in quick actions for objectives, define them as described in Example: Decision Filters for RecordListview.
However, only the following two parameters are available:
-
Parameter:Action
-
Parameter:ButtonAction
Assign the Decision filter to the
ExecuteActionFilterName
input argument of the
ObjectivesEditView
action call, see ObjectivesEditView.
Allowing Adding/Editing Records Only in Online Mode
You can define that a user is only allowed to add or edit records when in online mode.
You can:
- Set the
RequestMode
input argument for the desiredNewView
orEditView
page call, see General Input Arguments. - Set the
Edit.DefaultRequestMode
Web Configuration parameter toonline
to enable this option throughout the application, see Web Configuration Parameters and Layouts.