It is a common practice to provide an engine model with multiple application views, each intended to manage a subset of the data domain; from each view, you omit parts of the engine model that are not strictly necessary or that you want to hide from certain groups of users.
Restricting the visibility of specific records in an application view performs horizontal partitioning of the engine model; the data structure remains unchanged in all application views, but the set of objects that can be seen or associated changes depending on the view used.
Filters define Boolean conditions based on the syntax for expressions already used to define derived attributes in the Database Schema. More information about the expression editor interface is available here.
Filters on class objects #
On classes it is possible to define one or more filters called Class filters; a Class filter describes a boolean condition on all objects of a class, and is used to filter out records that do not satisfy this condition. You can create multiple Class filters for each class. In the presence of several filters, their conditions are joined by logical AND; in other words, an object of the class will be visible in the application view if all the conditions are evaluated as true
, while it will be filtered out if at least one condition evaluates as false
.
You can define Class filter on all enabled classes in the application view, including the platform class __User; It is not allowed to filter special classes such as Enum, Singleton and Form.
Create a Class filter #
From the Application Schema , select the class on which you want to define the filter and right-click to open its Class menu
; from here select the Set filters...
option to open the Class filters manager: from this panel, click the Add
button to open the Class filter editor and define the filter condition.
the Class filters manager has two panels; the first one shows the filters currently applied on the class. You can edit and delete previously defined filters with the (Add
) and (Delete
) buttons. A quick way to delete all filters defined on a class is to right-click on the icon in the footer and select Delete filters
from the context menu.
The Copy filters to other applications
option allows you to extend the selected filter to other application views, which can be selected using the respective checkboxes from the context panel (Link to other applications
). As shown in the following figure, only views that are compatible with the filter are selectable (for example, a view in which the class on which the filter is defined is disabled is incompatible).
In the second pane of the Class filters manager you can type the message that will be shown to the user when saving a class object in case the affected object violates at least one of the conditions defined in the class filters; to prevent such objects from persisting within the application, you must check the Reject save request
option.
When a Class filter is defined, all roles entering the class are marked with a black dot oriented towards the class; this also happens for roles entering any part classes (with the dot oriented towards the part class).
To disable the propagation of a Class filter on one of these roles, you need to right-click it, open its Role menu
and uncheck the Apply class filters
item.
Once a Class filter is added, the corresponding icon appears in the class footer.
Example of Class filter #
Let’s imagine that we want to keep track of the sales of an online store. In the Sale class, the boolean flag completed
indicates whether a sale has been completed or not.
We’ve created two application views (Administration
and Archive
), and we want the second one to only show sales that have already been completed. To do this, we declared a Class filter on the Sale class, called onlyCompletedOrders
, which references the flag by simply typing completed
, since the attribute itself is boolean.
In this way the application will evaluate for which objects of class Sale completed
is valid true
, and will show to the user of the application view Archive
only the objects that respect this condition, namely the completed sales. Since we have not checked the Copy filters to other application
option in the Class filters manager, the filter will only be valid for this application view, and users of the Administration
view will still be able to see all objects of class Sale.
Filters on role associables #
On the roles of the associations it is possible to define one or more filters that take the name of Selection filter; a Selection filter describes a boolean condition on the set of associable objects, i.e. the objects of class target that can be associated through that role, and is used to restrict that set by filtering out all objects/records that do not satisfy the condition. You can declare multiple Selection filters for each role. In the presence of multiple filters, their conditions are put in logical AND; in other words, a target object will be associated for that role in the application view if all conditions are evaluated true
, while it will be filtered if even only one condition evaluated on it gives value false
.
Create a Selection Filter #
From the Application Schema , select the role on which you want to apply the filter and right click to open its Role menu
; from here select the Set selection filters...
option to open the Role filters manager: from this panel, click on the Add
button to open the Role filter editor and define the filter condition.
Like the Class filters manager, the Role filters manager allows you to add (Add
), edit (Edit
) and remove (Delete
) conditions, and extend the filter to other applications (via the Copy filters to other applications
option).
When a Selection filter is defined, the role is marked with a black dot oriented towards the source class.
Example of Selection filter #
Let’s imagine that we keep track of employees (Employee) and projects (Project) in a company and want to manage the assignment of employees to various projects. Each employee plays a role in the company, identified by the association of the relevant class with the Enum Employee_type; this information is carried over to Employee with the derived attribute /employee_type
. There are two associations between Project and Employee to distinguish between project leaders (managers
) and generic assignees (assignees
).
Assuming that we want to prevent the system from associating employees without managerial qualifications as project leaders, we declared a Selection filter on the managers
role, called onlyManagers
, that takes this requirement into account.
The expression used is Employee.employee_type = Assignment[MANAGER]. name
, and checks whether the association between Employee and the Enum Employee_type points to the MANAGER
literal, taking advantage of the fact that Enum literals are globally visible constants on all Expression editors (more information is available here).
Selection Path #
In the Create a Selection filter section, you might have noticed that, in addition to the Set selection filters
item, the Role menu
also includes the Set selection path...
item: this function allows you to apply a known filtering pattern on an association role, which takes into account the paths connecting two classes. More details on this command are available on the following page: [Selection Path](/en/guide/
ing/application-schema/selection-path/).