I am looking at trying to rewrite an application that is mostly procedural to an MVC/OO approach in order to teach myself a deeper understanding of both.
BUT, I am having some conceptual issues with the current group/access control that is used.
We have Groups (Businesses) that have role based users (Manager, salespersons, customers).
They can have customers either assigned to a salesperson, or not. The manager sees everything, the salesperson only those customers assigned to him.
Business
|
---Manager
|
---Salespersons
|
---Customers
|
---Customers
The table structure for this currently is something like this:
users (userID [demographic info])
business (businessID, userID, et al [demographic info])
salespeople (salesID, businessID, userID [just foreign keys])
customers (customerID, businessID, userID, et al [demographic info])
salesAssignments (salesID, customerID [just foreign keys])
The Manager can affect everyone within that businesses group (everyone has a businessID that links them to that business and no other). The customers can login and make minor changes to their profiles or interact via messaging to their salesperson or the businesses manager.
Added Spice to the mix: (comment on any of these if they apply to your insights to the above question) Is there a better way to have similar user access and control?
I want to rebuild the site with an API that can be used by both the web app and mobile apps.
EDIT
My main conceptual hangup at the moment relates to how to recreate this structure in a user object for the OO part of the application. Now everything is accessible via session variables, or queried from the DB via procedural functions.
Again my understanding of OO is limited, and this is an attempt to figure it out.
Create a user class, and then a class that inherits from it for each kind of user. Add a collection of type as appropriate to each of these classes for the child relationships e.g.
class User {}
class Manager : User
{
Collection<SalesPerson> SalesPeople { get; set; }
}
class SalesPerson : User {}
Now, when you have a manager, you can navigate into the related sales people (assuming the list is correctly populated)
1
Conceptually, the way you achieve this in your repository is to limit your database accesses by adding a WHERE clause to your SQL, to the effect of:
WHERE <User is manager> OR UserID = <currently logged in employee id>
1
You could implement permissions using the type object pattern http://gameprogrammingpatterns.com/type-object.html
So each of your users would have a type property that defines their type in 1 of 2 ways.
- differing type object properties eg. typeName
- type object inheritance hierarchy
1 has the advantage that all type objects are of the same class and thus can always be treated identically and it is quite simple to interrogate an object’s type.
2 has the advantage of specifying differing type properties that apply only to that type (and it’s subtypes), eg. the Manager type may have the property groupSalesTarget which might not make sense for a customer
One of the big advantages of this pattern in general is the ease of upgrading and downgrading the permissions of individual users.