Hi,
We are in the phase of designing an application based on aspnetzero and this question here is related to the application Business Logic design based on the aspnetzero schema. Though, most of the Business Logic is already converted to the aspnetzero schema, however there are a couple of things that I'm not sure of and that's why I'm asking you if you have any suggestions in this regard.
The application involves a Vendor entity, the application will hold the products and staff users for those vendors. The application will also hold the customers user data and our staff users. The design decision we took for users is to store all different users in the default Abpusers table. The application is going to be a single tenant application holding all the different kind of users, vendors and products.
Now the design decision to make is how the vendors should be managed inside this application. The critical business rules for vendor entity is that the vendor staff can only see/manage the products and users related to that vendor, nothing else. The customers can be linked to any vendor by our staff users. In essence, what we want is that when a vendor user logs in to the application, he can manage everything related to that vendor, when our staff member logs in into the app, they can manage everything. So the question finally is that can we use organization units, permissions or anything else to implement this kind of logic, or do we have to implement custom logic for this? It'd be great if we can use the pre-built administration pages for our staff members and vendor staff members based on the business logic I've shared above.
Thanks,
2 Answer(s)
-
0
Your answer for this question will help me as well
Looking for your answer
-
0
Hi,
You may have 3 different architecture based on your needs:
Organization units can be used to group users and vendors, so a user can see only vendors in his OUs. In that case, a user can be related to more than one Vendor.
If you want that a user only associated to single Vendor, then you just add VendorId to User and then use this VendorId to filter Vendors or other Entities.
You can use OUs as Vendors. So, there will not be a Vendor entity at all.
I understood your situation in general, but I can not advice an exact architecture since any architecture has pros and cons. If you did not read yet, first read <a class="postlink" href="http://www.aspnetboilerplate.com/Pages/Documents/Zero/Organization-Units">http://www.aspnetboilerplate.com/Pages/ ... tion-Units</a> document to understand capabilities of OUs.
Finally, this is not related to standard permissions. Permissions are used to restrict functionallity (like entering a page or clicking a button in a page), not filter a table based on a column.
