[midPoint] Semi-manual connector as temporary solution

[Pavol Mederly]

Hello Wenzel,


the documented way is to write a custom ITSM plugin 
<https://docs.evolveum.com/midpoint/reference/support-4.10/resources/manual/itsm-plugin/> but 
that requires a custom overlay build of midPoint. Comparing to your 
approach, it provides an ability to get a direct feedback from Jira when 
the administrator closes a ticket (see "queryOperationStatus" method).


But as you are using semi-manual approach with the feedback provided via 
LDAP itself, this may not be so significant.


Maybe other members of the community could comment on this as well. 
Actually I'd be interested to know what is the percentage of users 
writing their own ITSM connectors vs those using notifications with 
custom transport to create the tickets. :-)


As a last note, in 4.11 we are going to solve the problem with 
manual/semi-manual connectors more seriously, as was presented on the 
Community Meetup last week. See 
https://docs.evolveum.com/talks/files/2026-05-mcm-macik-manual-connector-development.pdf.


Best regards,

-- 
Pavol Mederly
Interim Chief Product Officer
evolveum.com

On 21/05/2026 09:51, Pilar von Pilchau Wenzel - AKDB via midPoint wrote:
> Hi,
>
> We want to start using midpoint. We have a working on-prem AD that is 
> managed manually at the moment and that we can not connect directly to 
> midpoint. This might change in the future but for now we are not 
> allowed to write to it.
> So, what we want to do right now is to propagate changes via jira 
> tickets to the administrators.
>
> I did some research and the solution that I found is to use a 
> semi-manual connector in midpoint so that we can read from the AD but 
> not write back directly. I tested a custom transport that is triggered 
> by a simple workflow notifier event handler and creates jira tickets.
>
> My question is, is this the right approach? And in a later stage, when 
> we are allowed to write to our AD directly, can this semi-manual 
> connector easily be switched to an AD-connector.
> I also tested an Ad-connector with only read permissions, but then I 
> was not able to create shadows.
>
> Appreciate any feedback.
>
> *Dr. Wenzel Pilar von Pilchau*
> Prozessanalyst
> Process Management & Digitalisation
> Mobile +49 162 2530060
> Email Pilar-von-Pilchau.Wenzel at akdb.de 
> <mailto:Pilar-von-Pilchau.Wenzel at akdb.de>
> *AKDB* · Anstalt des öffentlichen Rechts
> Hansastraße 12-16 · 80686 München
> www.akdb.de <https://www.akdb.de/>
> AKDB Logo
>
> 	Great Place to Work Certified
>
>
>
> _______________________________________________
> 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/20260521/8d557c7f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-Mobile.png
Type: image/png
Size: 404 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260521/8d557c7f/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-Email.png
Type: image/png
Size: 924 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260521/8d557c7f/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-AKDB Logo.png
Type: image/png
Size: 3456 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260521/8d557c7f/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-Great Plac.png
Type: image/png
Size: 72182 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260521/8d557c7f/attachment-0007.png>