[midPoint] Fwd: Some tricky questions about develop connectors. Hello!
Али Саад
gerardo.saad at gmail.com
Sun Nov 9 03:37:59 CET 2025
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/#:~: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/20251109/629ec817/attachment-0001.htm>
More information about the midPoint
mailing list