|
|
|
|
The first step towards using the Comergent eBusiness System is to assign the necessary functions within your organization that will administer the various parts of the enterprise site. Once you have done that, the second step is to create the users who will perform these functions and assign access privileges for that purpose.
The tasks for this purpose are presented in CHAPTER 6, User Administration.
Once your company has installed the enterprise edition of the Comergent eBusiness System, it is useful to assign the following functions in your organization:
The user administrator is the person at the Comergent installation responsible for adding users to the system and giving them access to the areas appropriate for them to perform their function. In general, user administrators do not have any privileges associated with partners. In particular, they cannot create partner users. (The only enterprise employees who can create partner users is the channel administrator.)
When you create users, you must assign them a username and password. The username you assign must be unique. Each username is checked for uniqueness when the user is created: if the username is already in use, then the user administrator must choose a different username. When a user is deleted from the Comergent eBusiness System, their username is not: that is, once a username is in use, it can never be re-used.
As you create users, you must also assign access privileges by assigning one or more functions.
You can also set a preferred locale for each user. See Internationalizing the Comergent eBusiness System for more information.
In the Comergent eBusiness System, entitlement functions and roles explicitly define the access that users have to business objects and the functions they can perform such as updating users or creating price lists. These functions and roles are listed in the Entitlements.xml configuration file which is read by the Comergent eBusiness System server on startup. The file comes with several entitlement functions and roles pre-defined (see Pre-defined Functions), but you can customize access by editing this configuration file to create more roles and edit the privileges of existing roles.
Roles are grouped into functions: functions are intended to correspond quite closely to the business functions within an organization: finance, sales, and so on. Each function has a label: this is what is displayed in the browser when you perform user administration.
It is important to distinguish these entitlement functions from the organizational functions described in the earlier section. Any person in your organization may have one or more organizational functions that they perform to complete their job responsibilities: system administrator, product manager, sales manager, and so on. These may or may not correspond to the entitlement functions defined in the Comergent eBusiness System.
Consequently, the entitlement functions defined in your implementation of the Comergent eBusiness System may serve as "umbrella" roles that cover more than one organizational function. For example, to provide them with the proper access, you may need to assign the same entitlement function to the channel administrator and the user administrator. At implementation time, your system integrators determine appropriate groupings of organizational functions into entitlements functions. These entitlement functions are defined in the Entitlements.xml configuration file.
However, note that only those roles present in the access policies and access control lists (ACLs) or in the Entitlements.xml file have any effect on the privileges users have. Refer to the Comergent eBusiness System Reference Guide for more information.
The Entitlements.xml configuration file that is implemented with the Comergent eBusiness System comes with the following pre-defined functions:
For partners, the following table summarizes their functions:
Users can be marked as managers. Managers are entitled to navigate to child nodes of their node to perform the same tasks as they can at their own node. They can also view and modify the activity of other users at their node. For example, an enterprise user with the Commerce function and marked as a manager can navigate to a child node in the enterprise hierarchy and view the orders created by EnterpriseCommerce users at the child node.
An enterprise user who is a manager can access all the accounts assigned to their enterprise node and nodes below this node. That is, managers do not have to explicitly draw accounts from the pool of accounts assigned to their node: they can work on any account assigned to their node.
Every user has a status. Together with the profile status of their partner, this determines what the partner user can do. See Profile Statuses for more details on partner profile statuses.
In Release 7.0.1 the following user statuses are defined:
When you set a user status to closed, or if their effective status becomes closed because you close their partner, this does not affect the carts, orders, returns, and other objects that the user has been working on. These remain in their current status until another partner user or enterprise user changes them.
Note that only partner users can be assigned the On Credit Hold and On Hold statuses. Only enterprise users with the Financials function can set partner users on On Credit Hold status. An enterprise user can re-open an On Hold partner user, but only enterprise users with the Financials function can re-open On Credit Hold partner users.
Each user belongs to a partner, and the user's effective status is inferred from their user status and their partner's effective status. For example, suppose that User 1 is a partner user of Partner B and that the effective status of Partner B is Open. Then if User 1's status is Open, then there is no restriction on the user's activities. If you change the profile status of Partner B to On Hold, then even though you have not changed the status of User 1, their effective status changes to On Hold, and so they can log in, but they cannot place orders.
Suppose that Partner B is the child of Partner A, and that the status of Partner B is Open. If you set the status of Partner A to On Credit Hold, then even though you have not changed the status of Partner B, the effective status of Partner B is inherited to be On Credit Hold. Consequently, the effective status of Partner B users is On Hold, and so they cannot place orders.
A partner's status overrides a user's status if the partner's status is more restrictive: In the example above, if the status of Partner B is set to Closed, then the effective status of User 1 is also Closed, irrespective of the status of User 1.
|
|
|