Hi Ivan,
That error has to do with an error in one of your microflows. if you double click it, it will take you to the error. Most likely one of the end events in a microflow is set to return a value and there is no value set. If you arent trying to return anything, double click the end event and set it to return nothing.
What is the "Add person" button executing? Is it a create button or does it trigger a microflow?
In both cases, ensure that the created role object is associated with the project. If not done properly, then the role object, with the association to the selected person is committed to the database, though not referenced by the project and thus it won't appear.
Create microflow: https://modelshare.mendix.com/models/dceeadb4-6183-43ba-a418-f800cb4ff161/act_createroleselect
Create button properties:
note: After taking a better look at your domain model; why do you use a *-* between Project & Role & Role & Person?
I think both will suffice with a 1-*
Doing a bit of thinkering about your requirement and the roles.
In case that one person has on role in all projects, then the Role_Person association should be a 1-1 and the selection should be done on person with a *-*. Given that one person can join multiple projects and a project can have multiple persons
Or one person can have a different role per project, but the roles are a fixed set; Then one project should be referenced by multiple roles, but the role should reference one project 1-*
And the role will reference one person. again 1-* . This will allow you to have a dynamic role for each project the person joins. Actually your name Role for the entity should be Membership and the attribute should be called Role. Since one person joins a project as a member and the value defines his/hers role.
Last option is same as previous, but where the role is dynamic. In that case the role is captured in a separated entity (table) and is referenced by a membership.
Hope this helps you a bit.
I would not go with the 1-1 relationship as I am thinking future.
=> agree
The roles are a fixed set (enumeration) in my model. I did that for now to ensure I get consistency.
What would be the advantage of pulling Role out as a seperate entity from Membership?
=> use of a separated entity is only usefull when you want to add or edit roles as an application user.
i.e. an administrator can manage the project roles.
If one of my designers becomes a site project manager there and could change but could be different on different projects.
=> My second solution is exactly covering this scenario. Each time a person joins a project as member the relation is set using the Membership entity.
A direct *-* association between Project and Person will cover the scenario that a project can have multiple person as member an each person can join multiple projects. But there is no way you can specify any information about how they are related; i.e. a person joins a project as developer or PM
This is the reason to add the Membership entity and 2 times a 1-* association. This allows you to specify additional information to the perosn-project relation. In this case it is the role you want to specify.
Now you have this situation; One project can have multiple memberships. Each membership refers to a single person. AND One person can be referenced by MULTIPLE membership (each with a specific role) and each membership refers to a single project.