I want to have "employees" table containing basic informations about employees and a roles field inside defining of what certain employee can do and what not.
I was having few ideas for this, however I'm not sure which one would be the best:
My first idea was to separate users and employees tables and create complete new auth instance for employees, however it's pointless somehow, since I'd have to use package/module for an admin panel, plus the project structure wouldn't be clear.
My second idea was to keep using users table for everyone and extend the default simpleauth class to load employee roles from the table field.
Of course, one might say that if I want roles to be stored in the database, I could simply use Ormauth. However, I think that Ormauth is simply too much (I wont need that heavy permission system for standard users).
So basically, what I want is a proper structure idea, separating users from employees.
There is nothing heavy about Ormauth. You don't have to use anything you don't have to, we have plenty of apps that only use groups and/or roles, and no permissions.
In these cases, we tend to extend the users table with a client_id or an employee_id (depending on the type of users) and create a one-to-one relation with a employees table or a one-to-many with a clients in the ORM model. And in Ormauth you can also add the field to the metadata (which is fully automatic) so an extension isn't needed, but it makes searching or queries a bit more complex.
In case of employees the user record is usually generated when the employee is added to the system by HR, in case of clients the application usually has self registration, and then someone in the backoffice will link the user record to the client record based on some external "evidence".
Donate
