[midPoint] Import AD group membership

[Radovan Semancik]

On 05/19/2016 01:28 PM, Dick Muller wrote:
> But why is it so difficult.
>
> For Outbound I created a Metarole group and work with an association.
>
> You would expect that inbound more or less works the same?
>

The idea of outbound and inbound mappings is the same. Most of the 
lower-level code is shared (mapping evaluation, expression evaluation). 
But the hight-level code for outbound and inbound is slightly different. 
And there I expect some issues. There is special handling for 
associations in the outbound part of the code (e.g. to correctly 
reconcile them). Equivalent code is missing in the inbound part. The 
code cannot be entirely the same, as the high-level logic for handling 
inbound and outbound direction is almost reversed. For outbound code the 
association is in fact expression output. But for inbound it is the 
input. I have created special-purpose expressions such as 
associationTargetSearch and associationFromLink that are easy to use in 
the outbound direction because they create an association on the output. 
We do not have equivalent expressions for inbound direction (yet). And 
there may be some bugs as well, as the inbound mappings were in fact 
only very lightly tested in situations with complex inputs.

Yes, the code that handles entitlements in he provisioning subsystem is 
the same. The direction in the association definition works in the same 
way for inbound and outbound. The problem is not there. The provisioning 
code should work and that code is tested well. But the higher level code 
in the model subsystem is likely to cause some problems. But not too 
much problems. I would guess that this is not *that* difficult to 
implement. In fact I expect that there will be more effort in testing 
the code than the effort needed to write it. MidPoint is theoretically 
prepared to support this. But the devil is in the details. And even if 
something should work in theory it usually takes a couple of long days 
and nights to make it also work in practice. I'm sure you are well aware 
of that.

But anyway, there is also a completely different side to this: Our 
development capacity is limited. Even if this might be just a few days 
to make this work, currently we have quite a lot of similar little 
things in the backlog. And a lot of tiny tasks still means a lot of time 
spent in development and testing. I would *love* to work on midPoint 
just because it is the right thing to do (and it really is!). But our 
developers have their lives and they have bills to pay. So we need to 
carefully balance the work which brings us money and the work that does 
not. I think it is perfectly understandable that we are prioritizing 
requests from midPoint subscribers and sponsors. If there are not enough 
funding coming from subscribers and sponsors we do not have any other 
option than to switch developers from developing midPoint to do 
deployment or consulting work. So we have money to pay for their 
salaries. Which means that midPoint development goes slower and then 
there is absolutely no time for small improvements. Fortunately that 
does not happen often and midPoint development goes full speed ahead 
almost all the time. But even if we go full speed the features endorsed 
by midPoint subscribers and sponsors are developed first and the other 
features must wait. And that wait may be a very long one unless some 
puts his money into it. It does not need to be big money. Even a small 
amount of money can do miracles. But you see, there is no magic way how 
to get the features for free. Someone has to pay for it in the end. 
Subscription is the best way to do this because the subscribers are 
sharing the cost of the development with other subscribers. But there 
are many options how to fund the development ...

Therefore, if you want to help midPoint move forward, please consider 
getting subscription, sponsoring the feature or contributing the code.

-- 
Radovan Semancik
Software Architect
evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160519/bfe452d6/attachment.htm>