[midPoint] Disable instead of delete

Thu Aug 27 12:41:56 CEST 2020

Hello Richard,

concerning plugins: yes, Eclipse plugin still sort-of works, but it's a 
dead code now (it always was "write-only" prototype code).

IntelliJ IDEA plugin is getting better each day (thanks, Viliam!) After 
release of midPoint 4.2 I will integrate the trace viewing feature to 
master branch for this plugin.

> Higher education funding in the US is complicated right now to put it 
> lightly. As time allows, I will be trying to actively contribute back 
> the best I can to the community. Doesn't pay the bills right now, but 
> hopefully will get more involved in the community. That particular 
> blog post went up quick because I wrote it as I did it on one system, 
> and then used it to make the correct changes on another. I have 
> several more to write. 
I can imagine the funding situation. And I am looking forward to your 
blog posts :)

Best regards,

Pavol Mederly
Software developer
evolveum.com

On 27/08/2020 02:30, Richard Frovarp via midPoint wrote:
> Thank you for the extraordinary help. Been a long day here, but had a 
> chance to get a decent understanding of what you've said, and even 
> give it a bit of a test. More comments inline.
>
> On Wed, 2020-08-26 at 10:24 +0200, Pavol Mederly via midPoint wrote:
>>
>>
>> Most probably yes. I was confused originally a little bit as well, 
>> because I do not know this part of midPoint into great depth.
>>
>> This is crucial (from 
>> https://wiki.evolveum.com/display/midPoint/Disable+instead+of+Delete):
>>
>>         "That means if there is a valid assignment for that account 
>> *or if the account is allowed by any other policy (such as 
>> **Projection Policy 
>> <https://wiki.evolveum.com/display/midPoint/Projection+Policy>**).*"
>>
>> In your case, the default (/relative/) projection policy ensures that 
>> - assuming there is no change in the assignment - any existing 
>> account is considered legal. On the contrary, under /full /projection 
>> policy, only really assigned accounts are considered legal. (As I 
>> say, I didn't realize this fact.)
>>
>
> Working on getting those values correct for our different resources 
> and how we want it to work. I understand why the default is the 
> default for the software, but it's a confusing bit to come to on one's 
> own. Getting this right will eliminate some of the confusion I've 
> bumped into with other resources. For anyone else following along, I'm 
> going with full projection policy by default, then source resources 
> are getting a none with a legalize on them. It feels like this is 
> touched on somewhere, probably the book(?) but it isn't coming to me 
> right now. I'll have to review other documentation I've seen in the past.
>
>
>> Yes. The XML document is so large because it contains almost 
>> everything I need to analyze the situation - all evaluations of all 
>> scripts/mappings, almost all objects used, detailed logs from the 
>> processing, etc. It is so to avoid round trips with customers like 
>> "send me logs from X", then "run it again and please give me also Y 
>> and Z", etc.
>>
>> And yes, it can contain sensitive information. I thought you have 
>> only a kind of playground installation, so no real data. Anyway, as 
>> you said, you managed to remove sensitive info. (You can now remove 
>> the whole file.)
>>
>> BTW, here is also the reason one should use config properties for 
>> passwords, etc: such properties will not be part of these trace 
>> files, only if there would be a bug somewhere. (Unlike things that 
>> are present in resource XML objects. They are part of these files by 
>> design.)
>>
>
> Yeah, we're using constants from the config file for pretty much 
> everything. There was one encrypted password in there I think for the 
> admin account that I removed. Then there were things like my DoB and 
> employee number that I took care of a little bit. Config properties 
> are awesome.
>
>
>> This is a point I don't understand: The Target - Grouper NDSU 
>> Subjects is your target resource. You are managing its content from 
>> midPoint. And you use the content in Grouper. So far so good.
>>
>> But why you use this same resource as a /source/ for midPoint (using 
>> live sync)? Was it just for the sake of demonstration of this issue?
>>
>
> No. I think we had a misunderstanding on how to make such resources work.
>
>> Well, this is about what level of details you set in the trace 
>> viewer. (What kinds of operations should it show.) So if I select 
>> e.g. only an overview, I will see all the mappings, but with no 
>> particular context. If I select all operations, I will find the 
>> context but then I can get lost in the processing. (I am speaking of 
>> the viewer used in IntelliJ IDEA plugin, because I haven't used the 
>> web GUI viewer for a long time.) So, currently the viewers require 
>> some amount of midPoint knowledge to be used effectively. I hope that 
>> gradually they will be improved to be suitable also for wider audience.
>>
>> But, overall, you managed to find the issue and resolution yourself, 
>> so I think it was of some help to you. :-)
>>
>
> Yes it was of some help. I'll have to give the IntelliJ IDEA plugin a 
> try later this fall. I have the Eclipse one working for managing the 
> XML, which serves me well enough for now.
>>
>> ---
>>
>> A personal note: The analysis I have done for you is something that I 
>> really love to do. We do that regularly for our customers. I did it 
>> here just because I liked your work (e.g. the blogpost about Grouper 
>> integration) and your approach to midPoint. And I love the academy as 
>> such, being myself from this environment. But it's not sustainable - 
>> I did this on my own time (which I have almost zero, and this work 
>> was almost 2 hours for me), and now I have to return to work for our 
>> customers and midPoint development as such. So, please, do really 
>> consider purchasing a subscription. Maybe you'll be surprised that 
>> the price is not that high for HE sector. Then we would be able to 
>> cooperate in a regular way, not on "best effort" (which I have 
>> depleted for longer time now) basis. :-)
>>
>>
>>
>
> Thank you very much for this extra personal effort. It certainly 
> wasn't expected. Higher education funding in the US is complicated 
> right now to put it lightly. As time allows, I will be trying to 
> actively contribute back the best I can to the community. Doesn't pay 
> the bills right now, but hopefully will get more involved in the 
> community. That particular blog post went up quick because I wrote it 
> as I did it on one system, and then used it to make the correct 
> changes on another. I have several more to write.
>
> Thank you once again,
> Richard
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20200827/8ed255c9/attachment.htm>