Hi
I’m trying to port an existing backend to CUBA, to see its potential.
I have the following scenario (simplified):
A given user (someone who can login) can be one or more of the following classes (roles?): Teacher, Parent, Employee
Based on their classes/roles as above, they can have additional properties (most of them mandatory). For example a teacher must have a type and is associated with one or more grades.
A single logged in user can play the above roles simultaneously, and these roles can be changed later on. For example, a teacher can become a Parent at a later time, and when it happens the system must ask for the additional fields that are mandatory for a Parent.
What’s the best way to achieve this in CUBA?
I’ve seen that we’re able to extend the User entity, and add custom fields, but I don’t want to ask for fields that are useless (for example asking for the teacher type if the user is only a Parent). In addition I’d like to let the User entity have only the generic fields a login user should have…
In my current solution, I’ve implemented different entities/tables (Teacher, Parent, etc.) and added a one-to-one reference to a common User table. When I register a new User, I dynamically add/remove rows in the other tables based on the user classes/roles.
I’d like to follow a best-practice recommendation that fits well within the CUBA architecture…
From my point of view, your solution is perfectly fine. What flaws do you see in it?
The only thing you could pay attention to additionally is the Dynamic Attributes feature. It would allow you to manage attributes of your “user classes” at runtime. Also, the “user class” entity could be Categorized, so even the list of classes could be extended. All this at a price of leaving the relational model and storing data in EAV structure.
First of all, thanks for your answer!
I just read the docs on Dynamic attributes and, from what I understood, if I want to attach more than one category to an entity I must NOT implement the Categorized interface. Am I right?
In addition, do you recommend (and is it supported?) attaching categories to the sys$User entity, such that I have a User that can also be a Teacher, Parent and so on?
Given that the sys User entity is not visible in studio, to do the above I imagine I must extend the User table and attach the categories to it, even if I’m not adding any new field… is it right?
And a last question regarding the ability to fetch entities BY its category… Is it simple, or does it require convoluted calls? I’m especially worried about accessing by category via REST v2 api calls (I need to integrate the backend data with an existing SPA interface).
based upon your description i created an example, that will give you one possible solution for this problem. You can find it here:
The main purposes of the example is to show how to do hierachies of entity classes and what that means to the resulting database tables & UI screens.
It does not cover all of your requirements, but if you can elaborate a little bit on what is missing, we might get that going E.g. what do you mean by “A single logged in user can play the above roles simultaneously” - does the different users (that might either be parents or teachers) have different capabilities on the software so that it would require different security roles?
Actually i think although the dynamic attributes thing is a really cool feature, it should definivitly used wisely since it has some drawbacks as well. So you might be fine with this simpler solution as well…
I hope this helps to get started. If you have any questions, don’t hesitate to write it down.
Hi Mario,
thanks for your help! Really appreciated!
I must go home now, so I’ll take a look at it tomorrow morning… Just a couple of comments (I’ll add to this tomorrow, when I’ll come back to work):
Actually i think although the dynamic attributes thing is a really cool feature, it should definivitly used wisely since it has some drawbacks as well. So you might be fine with this simpler solution as well…
You’re absolutely right… after fiddling with them, I gave back for my scenario, and I’m convinced to use a standard relational model (but indeed they are really handy in simpler cases, and I’ll consider them in the future)
what do you mean by “A single logged in user can play the above roles simultaneously” - does the different users (that might either be parents or teachers) have different capabilities on the software so that it would require different security roles?
When a user logs in, he/she can play one or more roles simultaneously (a teacher and/or a parent and/or an administrative person).
Based on his/her role the logged in user:
must have some additional attributes tied to its profile (for example the teacher type, and the many-many association with grades)
has some specific permissions, for example a teacher can manage his appointment slots, take and cancel appointments with parents and so on
In my current ER model I have one separate entity for role type (for eg. a teacher and caregiver table), and in each entity/table I have a one-to-one mapping with the User table (the login table).
I’ll see if your solution of extending base entities fits better in my cuba project, but maybe in my case I’d need to extend the sys$User class instead of a generic Person… But I don’t know the implications, from the cuba framework standpoint, if I extend that system table multiple times…
E.g. what do you mean by “A single logged in user can play the above roles simultaneously” - does the different users (that might either be parents or teachers) have different capabilities on the software so that it would require different security roles?