If you want to show the details of the current logged in user, I would go for the following construction
Microflow which retrieves the Persoonsgegevens object of the logged-in student
Configuring the retrieve like this
If this retrieve doesn’t find a Persoonsgegevens object, the message is shown.
=> And if this occurs, there isn’t an association set between the logged in Student and a Persoonsgegevens object.
If found, then it opens a page with a dataview containing the single persoonsgegevens object
I would solve it in the security. Put an XPath constrained like this in the Access rules of Persoonsgegevens for the student user role: [YourModuleName.Persoonsgegevens_Student='[%CurrentUser%]']
This way you restrict for that user role that the user can only see Persoonsgegevens that are attached to the person's student entity.
Regards,
Ronald
XPath:
Student logged in:
Administrator:
At first; why use a list view? Because the result of the XPath will be either 1 or 0 objects. Thus beter use a dataview instead.
Next to that; you filter on a association to the current user student inherits from account which inherits from user.
Also I do see an associations between Student and ProfielFoto & Student and Certificaat. While these associations also exist between Persoonsgegevens and ProfielFoto & Certificaat. This rings some bells, because Student inherits from Account/User and that data should not be used in the User process and only be used to login and assign rights. This might also conflict.
This is happened when I use dataview Persoonsgegevens with association with Student:
I cannot view nor edit the data.