This section needs to be expanded. However, documentation work is similar to the development work in that it takes time and that it needs funding.
Those "result handlers" are an artifact of an original original Identity Connector Framework over-engineering. The handlers are supposed to assist connectors by implementing "mechanism" that the connector or resource does not support - such as search result filtering, data normalization and so on. However, those handler are generic and they know nothing about the particulars of the resource that the connector connects to. Therefore in vast majority of cases those handlers just get into the way and they distort the data. Good connectors usually do not need those handlers at all. Unfortunately, these handler are enabled by default and there is no way for a connector to tell the framework to turn them off. The handlers needs to be explicitly disabled in the resource configuration.
We strongly recommend to disable all the handlers when working with well-designed connectors in general and when working with our LDAP or AD/LDAP connectors in particular.
<icfs:resultsHandlerConfiguration> <icfs:enableNormalizingResultsHandler>false</icfs:enableNormalizingResultsHandler> <icfs:enableFilteredResultsHandler>false</icfs:enableFilteredResultsHandler> <icfs:enableAttributesToGetSearchResultsHandler>false</icfs:enableAttributesToGetSearchResultsHandler> </icfs:resultsHandlerConfiguration>
In a normal case all timestamps in midPoint are in W3C DateTime format. MidPoint converts all the date/time values to this format. However, there is one problem when it comes to the connectors. The ConnId framework does not have any way how to express date/time information in the schema. ConnId framework is representing date/time information as (long) integers in UNIX timestamp format. Therefore by default even LDAP timestamps are converted to UNIX timestamps. As midPoint does not know that this is a date/time information it cannot properly convert this to W3C dateTime format.
However, you can control this behavior in LDAP connector configuration by using timestampPresentation property. It has two possible values:
unixEpoch: LDAP connector will present timestamps in UNIX epoch format (number of seconds since 1970)
string: LDAP connector will present timestamps in LDAP-native format (generalized time, ISO 8601
In any case, if you are mapping LDAP timestamp attribute to midPoint dateTime properties you have to make explicit conversion in the mapping expression. This would be normally done by midPoint itself. But as ConnId framework does not have a way how to express timestamps in schema then midPoint does not know that this is a timestamp and it cannot make the automatic conversion (https://jira.evolveum.com/browse/MID-3220).
This is a missing or incomplete feature of midPoint and/or of other related components. We are perfectly capable to implement, fix and finish the feature, just the funding for the work is needed. Please consider the possibility for supporting development of this feature by means of midPoint Platform subscription. If you already are midPoint Platform subscriber and this feature is within the goals of your deployment you may be able to use your subscription to endorse implementation of this feature.