Access to associated - inherited - associated attributes

I have a Person entity. This is associated with Adminsitrative.Account. And Account inherits from Syste.User. Which has associations woth UserRole. I have noticed that when setting source for a widget, I can traverse from Person to Account (via Person_Account) and can see Language and Timezone (both associations with Syste.User) but I can’t see UserRole. Is there any particular reason for this? (I notice that user is many to many with Userrole, whereas user is one to many with language) So can only a one to many association be traversed?
3 answers

Hi John Norris,

To answer your question, an association can be traversed from the owner of the association. It can be 1-1, 1-* or *-*.

For example, in the association between Language and Account via “User_Language”, User is the Owner of the association. hence, while using a reference selector on am account newedit page, you can traverse and set the association with a given language.

Similarly, In this case, even the userrole can be traversed via the user/account entity because if you see the domain model of System module, User is the owner of the association. Only thing is, since this is a *-* association, you need appropriate widget to traverse like a reference set selector widget. If you use a reference selector widget, the association won’t be shown because reference selector doesnot works for *-*

Hope this answers your question!

Thanks and Regards

Praharaj Mahaprasad Tripathy


Answering to the questions mentioned in the comments :


  1. “The user has write access to the Person entity, including the association with Account. So will this include the attributes of Account?”

 The answer to this is “No”. This is because Person and Account are two separate entities and merely linked to each other via association. You would need to configure entity access for both the Account as well as the Person entity for the module roles.

  1. “If I have a mixture of Person and Account attributes I want to change, am I better off moving the Person and Account attributes into a Registration object (microflow), update the form and then microflow save to move the Registration data into appropriate Person and Account and update them?”

This depends on situation to situation. usually we perform this kind of a logic when we have an anonymous user to create an account. At this point of time, we don’t want to expose the Person/Account entity to anonymous, so we let the user fill in the details in a separate “Registration” entity and have them mapped to the respective attributes of Account/Person entity


I believe it is because of security that you can not freely traverse the userroles. It is so the role names are never visible to the user. But i am not sure.

You can select Users of a given role using this xpath:

[System.UserRoles = '[%UserRole_Administrator%]']

Which i find sufficient for most applications.