Admin can create, view, update and delete the SHGGroup. FieldOfficer can create, view, update and delete their own SHGGroup.
The above scenario is working.
Now if Admin is also an FieldOfficer, then when I assign FieldOfficer role to the same employee in auth_assignment whose first role is Admin, and tried to login using the employee username and password, but his admin role gets executed and not the fieldofficer role.
A user can have ‘Admin’ role and ‘FieldOfficer’ role at the same time, and he/she can do what ‘Admin’ can do plus what ‘FieldOfficer’ can do.
He/she has two ways to delete his/her own SHGGroup, one is via ‘Admin’ role and the other is via ‘FieldOfficer’ role. And he/she can delete other SHGGroup by ‘Admin’ role.
If ‘Admin’ can do all the things that ‘FieldOfficer’ can do, then there’s no reason to assign both ‘Admin’ and ‘FieldOfficer’ to one user.
If you want a certain user to act only as a ‘FieldOfficer’, then you should not assign him/her ‘Admin’ role. Or, in other words, you should give him/her two user accounts: one is for ‘FieldOfficer’ and the other for ‘Admin’.
Then you can assign ‘jdoe-a’ with Admin role and ‘jdoe-f’ with FieldOfficer role.
If he wants to act as Admin, he could login as ‘jdoe-a’. If he only wants to manage his own SHGGroup, with no fear of breaking other groups, he should login as ‘jdoe-f’.
Do you want to create a single account ‘jdoe’ and assign him with 2 roles that can be switched between them?
That would require some trick. I would consider creating some rule for Admin role that would require extra password.
I would have 2 records in employee table: one for jdoe-f and the other for jdoe-a. And optionally I would create additional field in the table that can be used to determine the user types: whether he/she is a real employee or a virtual user for system administration.
It would not look very smart to you. It might not be DRY. But I believe it’s simpler and easier.
Sorry, but I can’t give you a good answer on this. I myself have no experience.
But I believe it could be achieved by adding some rule to the Admin role, probably checking a session variable that defines the current role. And it would also require additional UI that enables the user to switch the role and set the session variable accordingly.