Base User Authorization Types
User Authorization types can be edited based on client needs, but there are default types that are build into base EASYCommerce.
User Authorization Type
Consumer - B2C
Customer : Accounts Payable
Customer : Basic Access
Customer : EASYPay
Customer : Full Access
Customer : Order Entry
Customer : Self-Service
Internal : Administrator
Internal : AR
Internal : Customer Service
Internal : EASYPay Account
Internal : EASYPayAdmin
Internal : IT
Internal : Management
Internal : Marketing
Internal : Sales Representative
The admin of the site has access to two pages: Work with Customer Roles and Work with Internal Roles. These pages allow the admin to view the current access for each of the defined user authorization types.
From these pages the admin can view all the webpages that are available through the site menu that the user could possibly see. The admin can then check or uncheck the pages to control the user authorization type’s access to the corresponding pages.
The pages available to Customer type users is different from the pages for Internal users. This is because there are two different menus maintained in EASYProcess. A menu is an entity which is used as container for all the WebPages that will display. This categorizes WebPages into categories of who should see them. The menu has categories just like the users: Customer and Internal.
When a new webpage is made, the developer must know who the user of this webpage will be and assign it to exist under one of the menu categories. Once a webpage is defined under a menu, the admin will see it in “Work with Customer/Internal Roles” (the list of pages to give access to).
The “Work with Customer/Internal Roles” page in the Admin panel (the list of pages to give access to) will be a list of all the pages that exist under the menu. For an internal user authorization type, this will be a list of all the pages under the Internal menu. For a Customer user authorization type, this will be a list of all the pages under the Customer menu.
UserAuthorizationType UseType (Internal Vs. Customer)
The Authorization Types are categorized by UseType. It is easy to think of this as breaking the list of UserAuthorizationTypes as being broken into two groups: Internal and Customer. Internal user types do not have a JDE Address Number associated. The only way they can place orders is if they are granted access to impersonate an account. An example of use for this is a Sales Rep or Customer Service Rep who places an order on behalf of a customer.
Customer User Types do have a JDE Address Number associated. They have one parent account (sometimes referred to as a Web Accoutn) and that parent/web account has billing addresses associated to that. Each billing address has shipping addresses associated as well. Customer User Types can typically place orders, see prices, use shopping cart and item features like product compare or check price and availability, etc.
For a user to exist, a record must exist for them in the [EPUsers] table. Internal users who don’t have a Parent/Web account all exist under the same Internal Parent Account: AB-10000001. See below, an example from the base [EPUsers] table.
You will notice that Customer type users have a different WebAccountId and have values for their Billing and Shipping Addresses.
For a user to belong to a certain UserAuthorizationType, all that is needed is for the [EPUsers].[UserAuthorizationType] column to have a value that is already defined as a UserAuthorizationType.
The actual list of User Authorizations are defined in [EC_UserAuthorizations]. Here is an example of some base user authorization types.
Each type defined must have either “Internal” or “Customer” under the [UseType] column.
In another table, [EPUserAuthorizations], the description of each UserAuthorizationType is stored. If you wanted to display the value on a webpage for an admin, you might want to display a description that is very different than the defined value. For this reason they are kept separate.
Here is the same example from base:
You will notice that there is also a column for Security level. This is because as a user, I will look to my UserAuthorizationType for my security level. This will be compared against the security level of webpages and if I do not have a high enough security level, I will not be granted access to view the page.
If a user simply tries to go to a page they don’t have access to, the following message is shown:
This protects against users trying to go to pages from a saved url or bookmark when they no longer have access.
However, just because I am not granted access, does not mean it is gracefully handled. The more graceful solution is to not display the links or the menu option so the user cannot navigate to the restricted page without a direct url.
To do this, there is another feature in place to control who can see what. These security levels are used as a base upon which the concept of User Restrictions and User Overrides are built.
User Security (User Restrictions and User Overrides)
From within the Admin Panel there are two page: “Work with Customer Roles” and “Work with Internal Roles”. Click into either to view all the User Authorization Types of the corresponding UseType.
Below is the “Work with Customer Roles” screen:
Once you click “Edit Access” for any UserAuthorizationType, this will bring you to the next page which displays all the menu categories for the menu associated with the user’s UserAuthorizationType.
Editing Access of the User’s Menu
What the Logged In User Sees in Their Menu
See how the menu categories correspond to the titles of the drop down menus for this logged in Customer User Type. You will notice when editing, the menu categories have more options than when the user is logged in. This is because the admin can restrict access to all pages under a Menu Category. When doing so the Menu Category no longer displays because if it did, it would be empty.
Clicking a menu category will open a popup window to select which pages the user will be allowed to see. If there is a checkbox, the page will appear in the user’s menu. If there is not a checkbox, the page will no longer appear in the menu.
Any user that is logged in during these changes will see the changes reflected when they log in on their next visit.
As previously mentioned, if a user bypasses this feature by directly typing in a url, the base security level prevents the user from seeing the page:
Assigning a Menu to a User Authorization Type
Each User Authorization Type is associated to a specific Menu. After this association, the Admin has the ability to grant or restrict access to the pages in that menu, but the Menu itself is already defined.
This association is done in EASYProcess via Entity Deployments. The specific deployment for the menu is called “StaticMenu”.
The above screenshot is from EASYProcess. The left column defines the default menu to use for everyone. This is just referred to as “Menu”. The right column defines groups by their UserAuthorizationType and assigns specific menus to specific types. You can see almost all shown user types are assigned a customer menu. The admin however, sees the Admin Menu.
The Menu assignment should not need to be edited except when initially setting up the site or when adding an additional UserAuthorizationType or Menu.
Changing the Menu
The Menu is the bar the user sees when they are logged in. This is how the users navigate to different web pages across the site. Not all users see the same site. Which menu they see depends on the user’s UserAuthorizationType.
Each menu that exists can be edited via the “Work with Menus” admin panel. This page allows the site Admin to select a menu to edit.
After selected a specific menu, all the menu categories display in a grid. The Admin can move the Menu Categories up and down to change the order they display in.
Clicking on “Manage Pages” opens a pop up window to display the pages that show under that Menu Category.
From here the Admin can again change the order, but also add or remove pages.
While the User Restriction/Access feature mentioned so far prevent users from seeing pages as a whole, a page may have other links on it that when clicked will result in the error message that they do not have access. This is why it must be used in combination with the EASYProcess GetVisibility Process.
The GetVisibility process is called from many pages throughout the site. It is very simple and just returns “True” of “False” for various features.
This would be used on the shopping cart. It is assumed the user has access to the shopping cart or they wouldn’t be able to see the content of the page. However, they may not have access to “My Lists”. This means the link below the shopping cart grid to add the cart to a list should be hidden. This is achieved by a process call to the GetVisibility Process and based on the output, dynamically setting the visibility of the “Add To List” Hyperlink.