Skip to end of metadata
Go to start of metadata
- Many configuration concepts in midPoint have optional names. Use them. E.g. mappings have names, authorization have names, objectSynchronization blocks have names. If you specify a good name there then you can easily find the trace of specific mapping evaluation in log files. You will see how the authorization was evaluated. You can check if the right objectSynchronization block was used.
- Use kind/intent combination instead of object class whenever possible. Object class is ambiguous when several kind/intent combinations use the same object class (which is quite common).
- MidPoint supports many independent organizational hierarchies. E.g. you can use one hierarchy in a form of a deep tree to model functional organizational structure (divisions, sections) and another shallow structure to model projects.
- Set orgType for each organizational unit. E.g. the functional tree should have orgType set to string "functional" in each organizational unit that belongs to that hierarchy, the projects should have string "project" in the orgType. As midPoint supports many parallel organizational structures and any object can belong to any of them, it is not always easy to determine which organizational tree to follow. E.g. in case that the function looks for user's manager. Many midPoint functions and expressions take orgType as an argument to determine which part of the organizational hierarchy is relevant for this specific expression. Therefore setting the orgType properly will save a lot of trouble later.