Differences

This shows you the differences between two versions of the page.

--- devel:documentation:architecture:dev:filters [2020/05/29 08:25]
tomiskar [EavCodeManagersFilter]
+++ devel:documentation:architecture:dev:filters [2020/06/11 20:11] (current)
tomiskar [Filters]
@@ Line 4: / Line 4: @@
 {{indexmenu_n>80}}
-<note important>Expand the introduction</note>
+[[https://docs.oracle.com/javaee/6/tutorial/doc/gjivm.html|JPA criteria API]] is used for search entities from underlying database. JPA [[https://github.com/bcvsolutions/CzechIdMng/blob/develop/Realization/backend/core/core-api/src/main/java/eu/bcvsolutions/idm/core/api/service/AbstractReadDtoService.java#L419|predicate]] has to be constructed for all supported filter properties. Predicate can be constructed two ways:
+  * by service - predicates are constructed in ''[[https://github.com/bcvsolutions/CzechIdMng/blob/develop/Realization/backend/core/core-api/src/main/java/eu/bcvsolutions/idm/core/api/service/AbstractReadDtoService.java#L326|AbstractReadDtoService#toPredicates]]'' method. This predicates are statically implemented and not overidable.
+  * **By registered filter builders** - A mechanism for dynamic registry and composing of filters has been developed in the application for searching the data in IdM (identities, roles, tree structure components, etc.). A new filter can be registered for existing REST services in any module. Filter builder can be registered by custom module and can override filter builder from other module (e.g. filter in custom module can override core filter behavior).
-A mechanism for dynamic registry and composing of filters has been developed in the application for searching the data in IdM (identities, roles, tree structure components, etc.). A new filter can be registered for existing REST services in any module. Filter can be used by [[..:..:security:dev:authorization#base_authorization_evaluators|authoritazation policy evaluator]] for securing data access.
+<note important>
+When no filter implementation is found for given filter property, then ''FilterNotSupportedException'' will be thrown. Filter builders (predicates) and all added filter properties have to be registered (constructed). Check for filter property is properly implemented is evaluated two ways:
+  * By registered filter builders - filter key is used.
+  * By filter definition (dto), if filter predicate is defined directly in service. Filter dto can define properties as fields or constants (see ''DataFilter'' generalization). **Make sure all properties are defined in filter dto if services predicate is used** - is required for check filter is supported.
+Check for filter property is properly implemented can be turned off by [[..:..:..application_configuration:dev:backend#entity_filters|configuration]] (e.g. before filter registration will be fixed).
+</note>
+<note tip>All supported filters can be found in [[#filter_agenda|agenda]] (menu Setting-> Modules -> Filters).</note>
+Filter can be used by [[..:..:security:dev:authorization#base_authorization_evaluators|authoritazation policy evaluator]] for securing data access.
+===== Filter builder =====
 The filter (''FilterBuilder'') is registered with the given key (''FilterKey''):
@@ Line 331: / Line 345: @@
 </code>
-==== DefaultManagerContractBySubordinateContractFilter ====
+==== EavCodeManagerContractBySubordinateContractFilter ====
 @since 10.4.0