Project from scratch, two months. Phase one completed.
Permissions are now simple. User table, Role table, Resource table of three.
There are currently only two shops. ID 0 is our own, as the background operations management, also abstracted into a shop, ID 0. Another shop ID of 1, is our first user.
The user table has the Merchantid and type fields. Merchantid indicates which product the user belongs to. The Type field represents user types. There is no use at present, because the Merchantid can distinguish, is the store backstage management personnel, or our own after-the-day operation and maintenance personnel. This field will be useful as a reserved field if the salesperson, the distribution clerk, and the employees of these identities are to be logged back in the future.
A user can have multiple role.
The role table also has the Merchantid and type fields. Same user. A role can access multiple resource.
The Resource table has a Type field. Indicates whether the resource is used by operations or shops.
Preset data:
All resource resources. Includes a special resource ' admin '. Represents a resource that only administrators can qualify to access. Used to assign permissions on the operation.
A role,code is admin. Does not belong to any shop. Merchantid is empty. Have Resource:admin permissions (this permission is not published to the interface to choose).
Two user. One is our Admin,merchatid is 0, one is the first store of Admin,merchantid is 1. They all have the role of that pre-role.
The advantage of this design is that the admin of OPS and the admin logic of the shop. There is only one small permission range that assigns permissions. After the system is initialized, log on to the login page to choose whether it is operations or shops. Each has its own user and admin. Log in with the respective admin, there is only one rights Management menu. Then, in the new user, assign additional business permissions. This will be unified.
Design of initial database for business-to-business multi-stores