Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
devel:documentation:architecture:dev:filters [2020/05/29 07:54]
tomiskar [GuaranteeContractBySubordinateContractFilter]
devel:documentation:architecture:dev:filters [2020/06/11 20:11] (current)
tomiskar [Filters]
Line 4: Line 4:
 {{indexmenu_n>80}} {{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 (identitiesroles, 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 serviceFilter 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''): The filter (''FilterBuilder'') is registered with the given key (''FilterKey''):
Line 175: Line 189:
 ## managers by standard tree structure (manager will be found by contract on parent node) ## managers by standard tree structure (manager will be found by contract on parent node)
 idm.sec.core.filter.IdmIdentity.managersFor.impl=defaultManagersFilter idm.sec.core.filter.IdmIdentity.managersFor.impl=defaultManagersFilter
 +</code>
 +
 +==== DefaultManagerContractBySubordinateContractFilter ====
 +
 +@since 10.4.0
 +
 +Find managers' contracts by subordinate contract. Finding managers' contracts by tree structures and set guarantees. The manager contract is on an organizational structure component superordinate to a structure component of the subordinate's contract. The manager (guarantee) can also be configured directly to the subordinate contract.
 +
 +Filter parameters
 +
 +  * ''managersByContract'' - a key parameter; uuid of the subordinate contract for which the searched are managers' contracts
 +  * ''includeGuarantees'' - True => it is being searched for managers' contracts by tree structures and by direct guarantees. False => only managers' contracts by tree structures.
 +  * ''validContractManagers'' - an additional parameter; valid now or in future contracts. True => manager contracts of subordinate contract ended in the past will not be returned. False => manager contracts of subordinate contract ended in the past will be returned. All managers' contracts  otherwise.
 +
 +Configuration:
 +
 +<code properties>
 +## contract filters
 +## managers by standard tree structure (manager will be found by contract on parent node)
 +idm.sec.core.filter.IdmIdentityContract.managersByContract.impl=default-manager-contract-by-subordinate-contract-filter
 </code> </code>
  
Line 309: Line 343:
 # extended attribute persistent type, 'shortTextValue' is prefered (indexed column by default), but 'stringValue' is used as default for compatibility reasons # extended attribute persistent type, 'shortTextValue' is prefered (indexed column by default), but 'stringValue' is used as default for compatibility reasons
 idm.sec.core.filter.IdmIdentity.managersFor.persistentType=shortTextValue idm.sec.core.filter.IdmIdentity.managersFor.persistentType=shortTextValue
 +</code>
 +
 +==== EavCodeManagerContractBySubordinateContractFilter ====
 +
 +@since 10.4.0
 +
 +The second option for finding managers' contracts in the same way as ''DefaultManagerContractBySubordinateContractFilter'' with a difference that the manager contract is not being searched for by tree structure but by the value of an extended (eav) tree component parameter - a code of a extended attribute is stated in the tree component, where there are managers (having contract on the given component) defined.
 +
 +<code properties>
 +## contract filters
 +## managers by relation in eav attribute (manager will be found by code in eav on parent node)
 +idm.sec.core.filter.IdmIdentityContract.managersByContract.impl=eav-code-manager-contract-by-subordinate-contract-filter
 +# extended form definition code
 +idm.sec.core.filter.IdmIdentityContract.managersByContract.formDefinition=default
 +# extended attribute code - value contains superior node code
 +idm.sec.core.filter.IdmIdentityContract.managersByContract.formAttribute=parentCode
 +# extended attribute persistent type, 'shortTextValue' is prefered (indexed column by default), but 'stringValue' is used as default for compatibility reasons
 +idm.sec.core.filter.IdmIdentityContract.managersByContract.persistentType=shortTextValue
 </code> </code>
  
  • by tomiskar