Defining access groups
An access group is a required element in a policy definition. It defines which users are entitled to act upon which resources. There are many instances where it is necessary to define a new access group.
Some common examples are:
- A new role and then a new policy is created to give authorities to this new role.
- New controller commands are created and you want to assign users with particular roles to access these commands.
The default access groups that are part of Commerce+ are found in language-specific XML files, such as utilities_root/xml/policies/xml/ACUserGroups_ locale.xml. This file follows the DTD specified by utilities_root/xml/policies/dtd/ACUserGroups_en_US.dtd.
The following is the format of an access group element:
<UserGroup Name="value" OwnerID="value" Description="value"
<UserCondition>
<![CDATA[
<profile>
Condition XML
</profile>
</UserCondition>
</UserGroup>
where:
-
Name - The name of the access group, which is stored in the
MBRGRPNAMEcolumn of theMBRGRPtable. -
OwnerID - The
Member IDthat owns this access group. The combination ofNameandOwnerIDmust be unique. Special values that can be used include:RootOrganization (-2001)orDefaultOrganization (-2000). -
Description (optional) - An optional attribute that is used to describe the access group.
-
UserCondition (optional) - An optional element that specifies implicit conditions of membership in this access group. This
criteria is stored in the
CONDITIONScolumn of theMBRGRPCONDtable. -
Condition XML - Using the condition framework, any valid combination of the
orListCondition,andListCondition,simpleCondition, andtrueConditionConditionelements.
| Variable Name | Description | Supported Operators | Supported Values | Qualifiers | Qualifier Values |
|---|---|---|---|---|---|
| role | Specifies that the user must have this role in the MBRROLE table. | = != |
Any value of the NAME column in the ROLE table. |
org ( if not specified, the user must have the role for any organization in the
MBRROLE table. |
|
| registration status | Specifies that the user must have this registration status. | = != |
Any value of the REGISTER-TYPE column in the USERS table such as G for
guest, and R for registered. |
none | n/a |
| status | Specifies that the user must have this member state. This is usually used for the status of registration approval. | = != |
Any value of the STATE column in the MEMBER table such as 0 for pending
registration approval, 1 for registration approved, and 2 for
registration rejected. |
none | n/a |
| org | Specifies that the user is a child of the specified organization. This information is based on data stored in the MBRREL table | = != |
|
none | n/a |
Examples of simpleConditions for access groups
Role without a qualifier
The following example displays a role simpleCondition without a qualifier; most
commonly used in role-based policies. In this example, the user must have a Seller Administration
role for any organizational entity.
<UserConditon>
<![CDATA[
<profile>
<simpleCondition>
<variable name="role"/>
<operator name="="/>
<value data="Seller Administrator"/>
</simpleCondition>
</profile>
</UserCondition>
Role with a qualifier
The following example displays a role simpleCondition with a qualifier; most
commonly used for organization-level policies. In this example, the user must have a Seller role for
the organizational entity with ORGENTITY_ID = 100.
<UserCondition>
<!CDATA[
<profile>
<simpleCondition>
<variable name="role"/>
<operator name="="/>
<value data="Seller"/>
<qualifier name="org"
data="100"/>
<simpleCondition>
</profile>
</UserCondition>
Role with a qualifier and parameter
The following example displays a role simpleCondition with a qualifier and the special data value OrgAndAncestorOrgs. This qualified data value, OrgAndAncestorOrgs, works only in groupable template policies. In this example, the user must have a Sales Manager, Account Manager, or Seller role in the organization that owns the resource, or any of the organization's ancestors.
<UserCondition><!CDATA[
<profile>
<orListCondition>
<simpleCondition>
<variable name="role"/>
<operator name="="/>
<value data="Sales Manager"/>
<qualifier name="org" data="OrgAndAncestorOrgs"/>
</simpleCondition>
<simpleCondition>
<variable name="role"/>
<operator name="="/>
<value data="Account Representative"/>
<qualifier name="org" data="OrgAndAncestorOrgs"/>
</simpleCondition>
<simpleCondition>
<variable name="role"/>
<operator name="="/>
<value data="Seller"/>
<qualifier name="org" data="OrgAndAncestorOrgs"/>
</simpleCondition>
</orListCondition>
</profile/>
</UserCondition>
registrationStatus
The following example displays a registrationStatus simpleCondition. In this
example, the user must be registered (USERS.REGISTERTYPE = R).
<UserCondition><!CDATA[
<profile>
<simpleCondition>
<variable name="registrationStatus"/>
<operator name="="/>
<value data="R"/>
</simpleCondition>
</profile>
</UserCondition>
status
The following example displays a status simpleCondition. In this example, the
user must have had registration approved. (MEMBER.STATUS = 1)
<UserCondition><![CDATA[
<profile>
<simpleCondition>
<variable name="status"/>
<operator name="="/>
<value data="1"/>
</simpleCondition>
</profile>
</UserCondition>
org
The following example displays an org simpleCondition. In this example, the user
must be registered in organizational entity 100. In the MBRREL table, there must be
a record where the user is a descendant of an organization that has ANCESTOR_ID =
100, and SEQUENCE = 1.
<UserCondition><![CDATA[
<profile>
<simpleCondition>
<variable name="org"/>
<operator name="="/>
<value data="100"/>
</simpleCondition>
</profile>
</UserCondition>