Users, Roles & Groups#

Authentication uses ASP.NET Membership; authorization is layered as Users → Groups → Roles → Module permissions.

Layers#

• Users (AspnetUsers, AspnetMembership, AspnetProfile) — the ASP.NET Membership standard tables. UsersHelper and UserSetupHelper wrap the operational CRUD (create user, reset password, activate / deactivate).
• Groups (AspMnxGroup) — Manex-defined group of users that share a permission set. AspMnxGroupHelper and AspMnxGroupUsersHelper manage groups and membership.
• Roles (AspNetRoles) — ASP.NET role membership; AspNetRolesHelper associates roles with groups.
• Module permissions — per-module toggles that decide which controllers / actions a role can hit.

The recent MD-4693 fix (aspmnxSP_GetRoles4Group SP update in TSQL/) corrected module visibility in the role-group setup UI — specifically that some modules weren’t showing in role-group setup and that Receive-roll from SCM wasn’t granting the right subset of receiving actions.

Business rules#

• Users can belong to multiple groups; effective permissions are the union.
• A permission on a “parent” action (e.g. Receiving) does not automatically imply “child” actions (PO receive vs. general receive vs. consignment receive) — each must be granted explicitly. MD-4693 was a bug where this fanout was missing.
• Deactivating a user does not remove their group memberships — reactivation should restore access without re-configuration.
• Role / group setup is authoritative in the DB; UI caches must be invalidated when the setup changes.

Where it lives#