The questions is more where to make these changes! Is it useful to have some more generic methods on the User class like
* getObjectClass * getAuxClasses * setAuxClasses * hasAuxClass * getAttributes * getAttribute * setAttribute * hasAttribute Is this to LDAP specific ? Or another approach would be to have some kind of Eventlistener to react on the add and update methods. There you get an LDAP connection and the user object as parameters. You can then implement your custom logic there. More generic is to have access to the methods above and the add and update methods must check the extra aux classes and attributes and reflect them back into LDAP. Would be nice to have some kinde of configuration which extra classes to handle in the web UI. Then there should be a the possibility to edit there attributes if its not much effort. Am 18.10.2016 um 16:25 schrieb Shawn McKinney: On Oct 18, 2016, at 9:15 AM, Patrick Brunmayr <[email protected]><mailto:[email protected]> wrote: In my understanding Midpoint should not be responsible to take care of fortress attributes like ftProps or something else. Its up to the connector to make a transparent transfer between the two systems in an API like way. So whenever something needs to be altered in Fortress the way should be via the AdminMg. Also the conenctor is responsible to define what kind of schema it want to provide to midpoint. There is no need to sync ftPros or something else. Let’s assume that we decide it’s a good idea to extend the fortress api to support custom user aux objects. What would that change look like? user add and update methods have some sort of call back for you to add your custom attributes to the ldap entity. What else - user page in fortress web? Or can midpoint handle the data collection part with its UI? Shawn LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: [email protected]
