[midPoint] Fwd: Some tricky questions about develop connectors. Hello!
Али Саад
gerardo.saad at gmail.com
Fri Nov 28 09:42:00 CET 2025
**Guys, hello once again.
Could you please also answer my previous question?
I have one more question regarding entitlements.
If I have both entitlements and accounts on the resource, and my accounts
contain multivalued roles, is it possible to configure midPoint UI so that
the user sees a dropdown or searchable list of roles (taken only from
entitlements by name) instead of a free-text multi-value field where they
have to manually type the role name?
Thank you for your help.
Ali Saad**
чт, 20 нояб. 2025 г. в 18:02, Али Саад <gerardo.saad at gmail.com>:
> Hello,
>
> I have an important question regarding the behavior of *UpdateDeltaOp* in
> ConnId.
>
> I am integrating with an external REST API where the PATCH request body
> always requires the following structure:
>
> {
> "login": "sber32444",
> "firstName": "Ivan",
> "secondName": "Ivanov",
> "middleName": "Ivanovich",
> "active": true,
> "email": "ivanov_ii at email.ru",
> "password": "qwerty",
> "roles": ["appAdmin", "accAdmin"]}
>
> In this API, the field login is *mandatory*, even if only other
> attributes are being modified.
> The business contract of the API requires that the user is always
> identified by login inside the PATCH payload.
>
> In my connector configuration for midPoint, I'm using:
>
> -
>
> __UID__ = id
> -
>
> __NAME__ = login
>
> As expected, midPoint calls updateDelta() using only the UID, and
> midPoint *does not send the __NAME__ attribute* in the delta unless the
> login itself was modified.
>
> *My question is:*
>
> Is there any way to force midPoint to *always include __NAME__* in the
> UpdateDelta operation, even if it hasn’t changed, so that I can insert it
> into the PATCH request body?
>
> If so, can this be configured in *schemaHandling* (e.g., via
> returnedByDefault, updateable, etc.)?
>
> If not, what is the recommended approach?
> Should the connector fetch the current object state (e.g., via GET by UID)
> in updateDelta() and extract the login from there before constructing the
> PATCH request?
>
> Thank you very much.
>
> ср, 12 нояб. 2025 г. в 00:46, Али Саад <gerardo.saad at gmail.com>:
>
>> Hello again. I have a particularly delicate question about required. As I
>> understand it, the Tirasa source code in the AttributeInfo file states: **
>> * Determines whether this attribute is required for creation. *
>> * @return true if the attribute is required for the object, otherwise
>> false. */ public boolean isRequired() { return
>> flags.contains(Flags.REQUIRED); } and I tried not to pass the required
>> attribute when creating an account, for example, and everything was created
>> successfully, then this attribute in the midpoint only affects the fact
>> that it is filled in the projection (if there was one) and in the change
>> operation. As I understand it, there are no restrictions other than filling
>> in the UI (I tried to leave it blank and got an error), and there can be no
>> errors from it, right? Because no exceptions are thrown. If the projection
>> had been created correctly, then the comment about Must be optional on
>> _UID_ during creation would have been clarified. It is also clear that
>> _UID_ cannot be transferred and it must be setcreateble(false) for a more
>> “correct” scheme, but at least separately about setRequired, you can
>> confirm or refute what I said above, as there is no answer to that yet.
>>
>> вс, 9 нояб. 2025 г. в 05:37, Али Саад <gerardo.saad at gmail.com>:
>>
>>> Hi Ivan,
>>>
>>> Thanks a lot for your previous reply — it clarified the projection
>>> creation behavior perfectly.
>>> I’ll try to open a ticket in the support portal as you suggested.
>>>
>>> One question still remains regarding the attribute flags defined in the
>>> connector schema:
>>> setRequired(), setCreatable(), and setReturnedByDefault().
>>>
>>> Since the UI for manual projection creation doesn’t currently display
>>> any attributes (even in 4.4), I’d like to understand what these flags
>>> actually influence in practice.
>>>
>>> Am I correct in understanding that:
>>>
>>> -
>>>
>>> *setCreatable(true)* — means that the attribute *can* be provided in
>>> the Set<Attribute> passed to
>>> Uid create(ObjectClass objectClass, Set<Attribute> attributes,
>>> OperationOptions options) (and if set to false, it won’t be
>>> included)?
>>> Or was it meant to mark attributes that *should appear editable* in
>>> a UI for manual account creation (which currently doesn’t exist)?
>>> -
>>>
>>> *setRequired(true)* — means that the attribute *must* be present in
>>> the Set<Attribute> passed to create(), otherwise the connector or
>>> framework will throw an error?
>>> Or does it just mean the attribute must exist in the resource object
>>> schema definition, even if midPoint doesn’t provide it?
>>> -
>>>
>>> *setReturnedByDefault(true)* — instructs midPoint to automatically
>>> request this attribute during search/reload, or is it only informational
>>> for the framework?
>>> I’ve noticed that even attributes with setReturnedByDefault(false)
>>> are still returned when doing a “Reload” or listing accounts. (when i use
>>> executeQuery method from connector)
>>>
>>> I’d really appreciate a short clarification on how midPoint interprets
>>> these flags internally versus how the ConnId SPI expects them to be used.
>>>
>>> Best regards,
>>>
>>>
>>> *Ali*
>>> [midPoint] Fwd: Some tricky questions about develop connectors. Hello!
>>>
>>> *Ivan Noris* ivan.noris at evolveum.com
>>> <midpoint%40lists.evolveum.com?Subject=Re%3A%20%5BmidPoint%5D%20Fwd%3A%20Some%20tricky%20questions%20about%20develop%20connectors.%0A%20Hello%21&In-Reply-To=%3Cee841363-87f0-4cc2-8a3d-610c538646e6%40evolveum.com%3E>
>>> *Fri Nov 7 09:10:19 CET 2025*
>>>
>>>
>>> - Previous message (by thread): [midPoint] Fwd: Some tricky
>>> questions about develop connectors. Hello!
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/008609.html>
>>> - Next message (by thread): [midPoint] First start in MidPoint on
>>> Docker an LDAP
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/008601.html>
>>> - *Messages sorted by:* [ date ]
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/date.html#8611>
>>> [ thread ]
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/thread.html#8611>
>>> [ subject ]
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/subject.html#8611>
>>> [ author ]
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/author.html#8611>
>>>
>>> ------------------------------
>>>
>>> Hi,
>>>
>>> regarding Add projection and attributes: I confirm that at the moment of
>>> adding a new account (projection) there are no attributes displayed. (I
>>> have even checked old midpoint 4.4 - it's the same).
>>>
>>> But if you have outbound mappings, they will be executed. So you really
>>> should not specify your own values of attributes; they should be
>>> computed by outbound mappings.
>>>
>>> Also, you should consider using assigning roles. Roles can have outbound
>>> mappings too - they can override/complement outbound mappings in
>>> resource schema handling.
>>>
>>> Whether the inability to enter attributes during account creation is a
>>> bug or missing feature, I do not know from top of my head. You can for
>>> sure create a new ticket in our support portal. But keep one thing in
>>> mind: if you would have strong outbound mappings and at the same time
>>> you would attempt to specify manual values for the same attributes, you
>>> would have a conflict for single-value attributes.
>>>
>>> My recommendation: prepare outbound mappings in your resource which take
>>> values from your user object (focus) and compute target attribute values.
>>>
>>> If some values should be e.g. constants representing groups, roles etc.,
>>> you can use midPoint roles which would specify their own outbound
>>> mapping(s) providing such value(s).
>>>
>>> Hope this helps.
>>>
>>> Best regards,
>>>
>>> Ivan
>>>
>>> On 11/6/25 12:50, Али Саад via midPoint wrote:
>>> >>* Hi Evolveum team,
>>> *>>* I will try to explain the whole sequence of my actions clearly,
>>> *>* starting from the beginning.
>>> *>* At work, we frequently perform integrations using *midPoint 4.9*.
>>> *>>* The question is about *creating resource accounts (projections)*,
>>> *>* especially for REST resources.
>>> *>* There is very little information in the official documentation, for
>>> *>* example here:
>>> *>* 👉
>>> *>* https://docs.evolveum.com/midpoint/guides/admin-gui-user-guide/#:~:text=The%20account%20form%20is%20dynamically,definition%20in%20the%20resource%20object<https://docs.evolveum.com/midpoint/guides/admin-gui-user-guide/#:~:text=The%20account%20form%20is%20dynamically,definition%20in%20the%20resource%20object <https://docs.evolveum.com/midpoint/guides/admin-gui-user-guide/#:~:text=The%20account%20form%20is%20dynamically,definition%20in%20the%20resource%20object%3Chttps://docs.evolveum.com/midpoint/guides/admin-gui-user-guide/%23:~:text=The%20account%20form%20is%20dynamically,definition%20in%20the%20resource%20object>>
>>> *>>* It explains the process but doesn’t actually show *how to enter
>>> *>* account attributes manually* during creation.
>>> *>* Here’s the relevant part from the documentation:
>>> *>>* “To add one or more resource accounts to the user, click on the
>>> *>* Add projection button in the Projections pane...
>>> *>* The account form is dynamically generated using the resource
>>> *>* schema definition in the resource object…
>>> *>>>* Example scenario
>>> *>>* Suppose I have a REST resource where the POST body looks like this:
>>> *>* {
>>> *>* "username": "some name",
>>> *>* "email": "some email",
>>> *>* "number": "some number",
>>> *>* "password": "some password",
>>> *>* "roles": ["admin", "support"]
>>> *>* }
>>> *>>* Here, |username|, |email|, and |password| are mandatory for
>>> *>* account creation, while |number| and |roles|*are optional.*
>>> *>>>* What happens in midPoint
>>> *>>>* When I open a user and go to the Projections tab, I click “+
>>> *>* New Projection” → select the resource → click the checkmark
>>> *>* → then Add.
>>> *>* MidPoint creates a projection with the name null, linked to
>>> *>* the selected resource.
>>> *>>* When I click on that projection, I see only a Basictab with
>>> *>* Canceland Donebuttons — but no fields appear for editing.
>>> *>>* If I click Done, midPoint creates the projection using
>>> *>* outbound mappings (values coming from the User object).
>>> *>* This is not ideal, because we may have many different
>>> *>* resources and we can’t keep adding all external fields to
>>> *>* the User object.
>>> *>* It would make much more sense to allow manual input of
>>> *>* account fields directly in the projection form during creation.
>>> *>>* My question
>>> *>>* Do I need to configure something in |<schemaHandling>| so
>>> *>* that, when I click *“+ New Projection”*, midPoint displays
>>> *>* the attributes defined in the connector schema
>>> *>* (|setCreatable(true)|)?
>>> *>>* Currently, the projection appears empty (“null”), even
>>> *>* though I’ve marked all connector attributes as creatable.
>>> *>>* How can I make those attributes *visible and editable*when
>>> *>* creating a new projection manually?
>>> *>>>* Related: |setRequired|, |setCreatable|, and
>>> *>* |setReturnedByDefault| flags
>>> *>>>* I’d also like to clarify the meaning and effect of these flags:
>>> *>>* *
>>> *>>* Does |setRequired(true)| mean that the attribute *must
>>> *>* be included* in the |Set<Attribute>| passed to
>>> *>* |create(ObjectClass objectClass, Set<Attribute>
>>> *>* attributes, OperationOptions options)|?
>>> *>>* *
>>> *>>* Does |setCreatable(true)| mean that the attribute *can
>>> *>* be entered in the UI* when creating an account (projection)?
>>> *>>* *
>>> *>>* How does the combination of |setRequired| and
>>> *>* |setCreatable| affect midPoint’s behavior?
>>> *>>* *
>>> *>>* And finally — what exactly does
>>> *>* |setReturnedByDefault(true)| do?
>>> *>* Does it mean that such an attribute is *automatically
>>> *>* fetched* from the resource even if not explicitly
>>> *>* requested by the framework?
>>> *>* And does it also influence which attributes are
>>> *>* displayed in the projection form in midPoint?
>>> *>>* From what I understand, |setRequired| marks an attribute as
>>> *>* mandatory during creation —
>>> *>* but it’s not clear what happens in practice, especially when
>>> *>* there’s no visible UI form to fill in the value.
>>> *>>* The only relevant comments I found are:
>>> *>>* *
>>> *>>* ConnId 1.x Development
>>> *>* Guide<https://docs.evolveum.com/connectors/connid/1.x/connector-development-guide/#:~:text=uidAib,build. <https://docs.evolveum.com/connectors/connid/1.x/connector-development-guide/#:~:text=uidAib,build.>>
>>> *>* —
>>> *>* which says |// Must be optional. It is not present for
>>> *>* create operations|.
>>> *>>* *
>>> *>>* Oracle ICF API
>>> *>* docs<https://docs.oracle.com/cd/E21764_01/apirefs.1111/e24834/org/identityconnectors/framework/common/objects/AttributeInfo.html#isRequired__ <https://docs.oracle.com/cd/E21764_01/apirefs.1111/e24834/org/identityconnectors/framework/common/objects/AttributeInfo.html#isRequired__>>
>>> *>* —
>>> *>* which says “Determines whether this attribute is
>>> *>* required for creates.”
>>> *>>* So far, it’s still not clear how these flags influence what
>>> *>* midPoint shows in the UI or passes during |create()| and
>>> *>* |get()| operations.
>>> *>>* ------------------------------------------------------------------------
>>> *>>>* Summary
>>> *>>>* Please help us understand:
>>> *>>* 1.
>>> *>>* How to configure *account creation fields* for manual
>>> *>* input during projection creation.
>>> *>>* 2.
>>> *>>* What exactly |setRequired|, |setCreatable|, and
>>> *>* |setReturnedByDefault| mean in practice — and how they
>>> *>* affect the *UI and connector behavior*.
>>> *>>* 3.
>>> *>>* Whether the projection form can be generated dynamically
>>> *>* from connector schema attributes (like a “Create
>>> *>* account” form) without relying solely on outbound mappings.
>>> *>>* This is very important for us, as account creation often
>>> *>* requires partial manual input (some fields from the User,
>>> *>* some entered by an administrator).
>>> *>>* Thank you very much for your help, and sorry for the long post.
>>> *>>* Best regards,
>>> *>* *Ali*
>>> *>>* чт, 6 нояб. 2025 г. в 09:55, David Klement <dakle at evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint>>:
>>> *>>* Hi Али,
>>> *>>* regarding the most recent message in the thread, i.e., "make
>>> *>* account and record fields without outbound mappings" - if I
>>> *>* understand correctly, you wish to create an account on a resource
>>> *>* using midPoint without actually having the corresponding account
>>> *>* (i.e., its user object, shadow, etc.) in midPoint? Or, in a
>>> *>* narrower case, you want midPoint to send account attributes to the
>>> *>* resource without midPoint actually having the attributes saved in
>>> *>* its database? In other words, you do not want midPoint to manage
>>> *>* the accounts or account attributes in question. If that is the
>>> *>* case, maybe it would be best to edit the data directly in the
>>> *>* target resource, would it not?
>>> *>>* Please let us know if I misunderstood your question. It is indeed
>>> *>* true that connectors work directly with the resources, but they
>>> *>* can only send them data that midPoint gives them, i.e., is
>>> *>* instructed to send to the resource via the connector.
>>> *>>* Best regards,
>>> *>>* David Klement | Technical Writer
>>> *>* Evolveum, s. r. o.
>>> *>* dakle at evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint> | www.evolveum.com <http://www.evolveum.com> <http://www.evolveum.com <http://www.evolveum.com/>>
>>> *>>* ----- Original Message -----
>>> *>* From: "midPoint General Discussion" <midpoint at lists.evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint>>
>>> *>* To: "midPoint General Discussion" <midpoint at lists.evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint>>
>>> *>* Cc: "Али Саад" <gerardo.saad at gmail.com <https://lists.evolveum.com/mailman/listinfo/midpoint>>
>>> *>* Sent: Wednesday, November 5, 2025 7:36:05 PM
>>> *>* Subject: [midPoint] Fwd: Some tricky questions about develop
>>> *>* connectors. Hello!
>>> *>>* Guys please tell me one thing. How i can make account and record
>>> *>* fields without outbound mappings. We use ur product and all of us
>>> *>* don't know how to do it. Please help. We wanna create account, for
>>> *>* example for REST Resource and also make account by administrator.
>>> *>* We know only one way to do it - make outbound mapping and take
>>> *>* some attributes, which we record before, from UserType. I think
>>> *>* this is a horrible and wrong way. Please, tell me - how i can
>>> *>* record fields by administrator. Maybe i must add some layers in my
>>> *>* schemahandling on resources? But it doesn't work.
>>> *>>* ---------- Forwarded message ---------
>>> *>* От: Али Саад < [ mailto:gerardo.saad at gmail.com <https://lists.evolveum.com/mailman/listinfo/midpoint> |
>>> *>* gerardo.saad at gmail.com <https://lists.evolveum.com/mailman/listinfo/midpoint> ] >
>>> *>* Date: пн, 3 нояб. 2025 г. в 01:54
>>> *>* Subject: Fwd: Some tricky questions about develop connectors. Hello!
>>> *>* To: [ mailto:info at evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint> | info at evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint> ] < [
>>> *>* mailto:info at evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint> | info at evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint> ] >
>>> *>>>>>* ---------- Forwarded message ---------
>>> *>* От: Али Саад < [ mailto:gerardo.saad at gmail.com <https://lists.evolveum.com/mailman/listinfo/midpoint> |
>>> *>* gerardo.saad at gmail.com <https://lists.evolveum.com/mailman/listinfo/midpoint> ] >
>>> *>* Date: сб, 1 нояб. 2025 г. в 19:46
>>> *>* Subject: Some tricky questions about develop connectors. Hello!
>>> *>* To: < [ mailto:midpoint at lists.evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint> |
>>> *>* midpoint at lists.evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint> ] >
>>> *>>>* Hello! Could you please explain the difference between the
>>> *>* setRequired(true) and setCreateable(true) flags when defining
>>> *>* ConnId attributes? 1. If the UID is generated by the target
>>> *>* system, should we set required=false and createable=false? 2. For
>>> *>* the Name attribute that midPoint must send when creating an
>>> *>* account — should both flags be set to true? 3. If an attribute can
>>> *>* be provided during object creation but is not mandatory, should it
>>> *>* be required=false and createable=true? 4. Is it correct that we
>>> *>* should never use required=true together with createable=false? Am
>>> *>* I right that required=true means the attribute must be included in
>>> *>* the Set<Attribute> passed to the create() method of the CreateOp
>>> *>* interface? No to other operations. Only for Create? I'm trying to
>>> *>* understand the practical meaning of these flags when designing a
>>> *>* connector schema. 5. Additionally, I’m still confused about how
>>> *>* account creation actually works in practice. For example, if I
>>> *>* want to manually set the UID or other attributes when creating an
>>> *>* account — how is this done? Is it controlled by inbound/outbound
>>> *>* mappings, or by the connector schema itself? It’s quite hard to
>>> *>* understand how midPoint decides which attributes to send during
>>> *>* account creation on the first try. (I'm using midPoint 4.9.) 6.
>>> *>* And one last question: what is the purpose of
>>> *>* setReturnedByDefault(true)? Is it true that midPoint simply won’t
>>> *>* expect such attributes by default, but it will still accept
>>> *>* attributes marked with setReturnedByDefault(false) if they are
>>> *>* present in the resource response? 7. I would also like to mention
>>> *>* that I created an attribute on the diagram as a string for locking
>>> *>* and unlocking __ENABLE__. Am I correct in understanding that
>>> *>* Midpoint will still create it on the diagram with the type that it
>>> *>* defines and recognizes—that is, as Boolean for special system
>>> *>* attributes? According to the Special-Purpose Attributes table?
>>> *>* Thank you very much in advance!
>>> *>>* _______________________________________________
>>> *>* midPoint mailing list
>>> *>* midPoint at lists.evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint>
>>> *>* https://lists.evolveum.com/mailman/listinfo/midpoint <https://lists.evolveum.com/mailman/listinfo/midpoint>
>>> *>>>* _______________________________________________
>>> *>* midPoint mailing list
>>> *>* midPoint at lists.evolveum.com <https://lists.evolveum.com/mailman/listinfo/midpoint>
>>> *>* https://lists.evolveum.com/mailman/listinfo/midpoint <https://lists.evolveum.com/mailman/listinfo/midpoint>
>>> *
>>> --
>>> Ivan Noris
>>> Expert Identity Engineerevolveum.com
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20251107/4fbe8290/attachment-0001.htm>
>>>
>>> ------------------------------
>>>
>>>
>>> - Previous message (by thread): [midPoint] Fwd: Some tricky
>>> questions about develop connectors. Hello!
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/008609.html>
>>> - Next message (by thread): [midPoint] First start in MidPoint on
>>> Docker an LDAP
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/008601.html>
>>> - *Messages sorted by:* [ date ]
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/date.html#8611>
>>> [ thread ]
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/thread.html#8611>
>>> [ subject ]
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/subject.html#8611>
>>> [ author ]
>>> <https://lists.evolveum.com/pipermail/midpoint/2025-November/author.html#8611>
>>>
>>> ------------------------------
>>>
>>> More information about the midPoint mailing list
>>> <https://lists.evolveum.com/mailman/listinfo/midpoint>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20251128/2c5f2ff9/attachment-0001.htm>
More information about the midPoint
mailing list