Group Membership Workflow
This section provides information about functions, conditions, and variables for the group membership workflow, as well as initial actions and reserved actions.
Table of Contents
- Group Membership Workflow: Initial Actions
- Group Membership Workflow: Reserved Actions
- Group Membership Workflow: Functions
- Group Membership Workflow: Conditions
- Group Membership Workflow: Variable Resolvers
Group Membership Workflow: Initial Actions
The initial actions valid for Akana API Platform workflows relating to group membership are:
@Invite
Starts the workflow for a new group member. Used to control workflow actions that occur when a member is invited to a group.
This is the default initial action, used in most cases.
@Import
Starts the workflow when group membership information is imported. Takes the group membership direct to the Approved state.
Group Membership Workflow: Reserved Actions
The following reserved actions are defined for group membership workflows:
- @RecreateInPendingState
- @RecreateInAcceptedState
- @RecreateInDeclinedState
- Group.membership.action.accept
- group.membership.action.decline
- group.membership.action.resend
- group.membership.action.remove
- group.membership.action.make.admin
- group.membership.action.make.leader
- group.membership.action.make.member
- group.membership.action.group.deleted
@RecreateInPendingState
Used to control workflow actions that occur when a group membership action is recreated in pending state.
@RecreateInAcceptedState
Used to control workflow actions that occur when a group membership action is recreated in accepted state.
@RecreateInDeclinedState
Used to control workflow actions that occur when a group membership action is recreated in declined state.
Group.membership.action.accept
Used to control workflow actions that occur when a group membership invitation is accepted.
group.membership.action.decline
Used to control workflow actions that occur when a group membership invitation is declined.
group.membership.action.resend
Used to control workflow actions that occur when a group membership invitation is resent.
group.membership.action.remove
Used to control workflow actions that occur when a group member is removed from the group.
group.membership.action.make.admin
Used to control workflow actions that occur when a group member who was a member or leader is made a group admin.
group.membership.action.make.leader
Used to control workflow actions that occur when a group member who was a member or admin is made a group leader.
group.membership.action.make.member
Used to control workflow actions that occur when a group member who was a member or leader is made a group member.
group.membership.action.group.deleted
Used to control workflow actions that occur when a group is deleted.
Group Membership Workflow: Functions
The following functions are available for the group membership workflow:
setGroupMembershipRequestState
Changes the state of a group membership request to a new state specified in the parameter.
Parameters
Name | Description/Values |
---|---|
State |
The state that the group membership request is being set to. Valid values:
|
Examples/Notes/Additional Information
The example below shows the workflow step when an invited group member declines the invitation. As a result, the group membership request state is set to com.soa.group.membership.state.disapproved.
<action id="102" name="group.membership.action.decline"> <restrict-to> <conditions type="AND"> <condition type="isSelfMembership"></condition> </conditions> </restrict-to> <results> <unconditional-result old-status="Pending" status="Declined" step="300" /> </results> <!-- update status to declined --> <post-functions> <function type="setGroupMembershipRequestState"> <arg name="state">com.soa.group.membership.state.disapproved</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.appteam.membership.rejected</arg> <arg name="groupType">com.soa.group.type.appteam</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.privateapi.membership.rejected</arg> <arg name="groupType">com.soa.group.type.private.apigroup</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.apiadmin.membership.rejected</arg> <arg name="groupType">com.soa.group.type.api.admingroup</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.bizadmin.membership.rejected</arg> <arg name="groupType">com.soa.group.type.business.admingroup</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.siteadmin.membership.rejected</arg> <arg name="groupType">com.soa.group.type.tenant.admingroup</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.group.membership.rejected</arg> <arg name="groupType">com.soa.group.type.independent</arg> <arg name="roles">role.group.all.members</arg> </function> </post-functions> </action>
setGroupMembershipRole
Sets the group membership role for the specified group member to a new role.
Parameters
Name | Description/Values |
---|---|
role |
The group role which is now assigned to the specified group member. Valid values:
|
Examples/Notes/Additional Information
In the example below, the group member is made into a leader. The setGroupMembershipRole function is used to change the user's role to com.soa.group.membership.role.leader.
<action id="106" name="group.membership.action.make.leader"> <restrict-to> <conditions type="OR"> <condition type="isCallerGroupAdmin" /> <condition type="isCallerSiteAdmin"/> <conditions type="AND"> <condition type="isCallerGroupLeader" /> <conditions type="OR"> <condition type="isLeaderMembership" /> <condition type="isMemberMembership" /> </conditions> </conditions> </conditions> </restrict-to> <results> <unconditional-result old-status="Pending" status="Pending" step="100" /> </results> <post-functions> <function type="setGroupMembershipRole"> <arg name="role">com.soa.group.membership.role.leader</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg> <arg name="groupType">com.soa.group.type.private.apigroup</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg> <arg name="groupType">com.soa.group.type.independent</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> </post-functions> </action>
sendGroupMembershipNotification
Sends group membership email and dashboard notifications when parameters match the group membership. Since the same function is used for all groups and all membership, this function is designed so that different notifications can be sent to different roles or different group membership depending on the event.
Parameters
Name | Description/Values |
---|---|
notificationType |
Valid notification ID of the notification message template for the notification to be sent. For example:
|
groupType |
Checks whether the sendGroupMembershipNotification function is for the current group type for which the membership is being updated. When the value of this parameter matches the group type of the group membership that is being affected, a notification is sent. Otherwise, no action is taken. The group workflow is designed to accommodate several different group types. Depending on the group type, a different notification might be sent. This parameter tests the current group type. Valid values:
|
Roles |
Defines the roles to which the notification is sent, as a comma-separated list of role names. Role names used for this parameter are:
|
Any parameter with name prefixed with "param" |
Parameter values for parameters with names starting with "param." Can be used in the notification template data. Examples:
|
Examples/Notes/Additional Information
The example below shows workflow steps when a group is deleted. One of two possible notifications is sent out, depending on the group type, to notify group members that the group was deleted.
<action id="108" name="group.membership.action.group.deleted"> <results> <unconditional-result old-status="Pending" status="Group Deleted" step="400" /> </results> <post-functions> <function type="setGroupMembershipRequestState"> <arg name="state">com.soa.group.membership.state.group.deleted</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.independent.group.deleted</arg> <arg name="groupType">com.soa.group.type.independent</arg> <arg name="roles">role.invited.user</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.privateapi.group.deleted</arg> <arg name="groupType">com.soa.group.type.private.apigroup</arg> <arg name="roles">role.invited.user</arg> </function> </post-functions> </action>
Group Membership Workflow: Conditions
The following conditions apply to the group membership workflow:
- isSelfMembership
- isCallerSiteAdmin
- isCallerGroupAdmin
- isCallerGroupAdminMember
- isCallerGroupLeader
- isCallerGroupMember
- isMemberMembership
- isLeaderMembership
- isAdminMembership
- authorizeInviteeByDomain
- authorizeInviteeByDomainType
- authorizeInviteeByEmail
- authorizeInviteeByGroupName
isSelfMembership
Checks whether the group membership is for the logged-in user; returns Boolean true if so.
Arguments
None.
Examples/Notes/Additional Information
The example below shows workflow for when a group member accepts an invitation to join the group. Since the invited person is the only one who is authorized to accept the invitation, the workflow uses the isSelfMembership condition to check that the individual performing the action is the invited member.
<actions> <action id="101" name="group.membership.action.accept"> <restrict-to> <conditions type="AND"> <condition type="isSelfMembership"></condition> </conditions> </restrict-to> <results> <unconditional-result old-status="Pending" status="Accepted" step="200" /> </results> <!-- update status to approved --> <post-functions> <function type="setGroupMembershipRequestState"> <arg name="state">com.soa.group.membership.state.approved</arg> </function> <!-- <function type="addBoardComment"> <arg name="notificationType">com.soa.notification.type.accept.appteam.invite</arg> </function> --> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.appteam.membership.accepted</arg> <arg name="groupType">com.soa.group.type.appteam</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.privateapi.membership.accepted</arg> <arg name="groupType">com.soa.group.type.private.apigroup</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.apiadmin.membership.accepted</arg> <arg name="groupType">com.soa.group.type.api.admingroup</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.bizadmin.membership.accepted</arg> <arg name="groupType">com.soa.group.type.business.admingroup</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.siteadmin.membership.accepted</arg> <arg name="groupType">com.soa.group.type.tenant.admingroup</arg> <arg name="roles">role.group.all.members</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.group.membership.accepted</arg> <arg name="groupType">com.soa.group.type.independent</arg> <arg name="roles">role.group.all.members</arg> </function> </post-functions> </action>
isCallerSiteAdmin
Checks whether the logged-in user is a Site Admin; returns Boolean true if so.
Arguments
None.
Examples/Notes/Additional Information
In the example below, the action being performed changes a group member's role to admin. The conditions section tests that the user performing the action is either a group admin or a site admin, since these are the two roles authorized to perform the action.
<action id="105" name="group.membership.action.make.admin"> <restrict-to> <conditions type="OR"> <condition type="isCallerGroupAdmin" /> <condition type="isCallerSiteAdmin"/> </conditions> </restrict-to> <results> <unconditional-result old-status="Pending" status="Pending" step="100" /> </results> <post-functions> <function type="setGroupMembershipRole"> <arg name="role">com.soa.group.membership.role.admin</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg> <arg name="groupType">com.soa.group.type.private.apigroup</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg> <arg name="groupType">com.soa.group.type.independent</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> </post-functions> </action>
isCallerGroupAdmin
Checks whether the individual performing the action is an admin for the group; returns Boolean true if so.
Arguments
None.
Examples/Notes/Additional Information
In the example below, the action being performed changes a group member's role to admin. The conditions section tests that the user performing the action is either a group admin or a site admin, since these are the two roles authorized to perform the action.
<action id="105" name="group.membership.action.make.admin"> <restrict-to> <conditions type="OR"> <condition type="isCallerGroupAdmin" /> <condition type="isCallerSiteAdmin"/> </conditions> </restrict-to> <results> <unconditional-result old-status="Pending" status="Pending" step="100" /> </results> <post-functions> <function type="setGroupMembershipRole"> <arg name="role">com.soa.group.membership.role.admin</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg> <arg name="groupType">com.soa.group.type.private.apigroup</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg> <arg name="groupType">com.soa.group.type.independent</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> </post-functions> </action>
isCallerGroupAdminMember
Checks whether the logged-in user (the user triggering the action) is a group admin member; returns Boolean true if so.
Arguments
None.
isCallerGroupLeader
Checks whether the logged-in user is a group leader; returns Boolean true if so.
Arguments
None.
Examples/Notes/Additional Information
In the example below, the action being performed makes someone a group member. The conditions section specifies that a user who is a group admin or site admin can perform the action; additionally, a user who is a group leader can perform the action on another user who is a leader or member.
This limits the action to authorized individuals.
<action id="107" name="group.membership.action.make.member"> <restrict-to> <conditions type="OR"> <condition type="isCallerGroupAdmin" /> <condition type="isCallerSiteAdmin"/> <conditions type="AND"> <condition type="isCallerGroupLeader" /> <conditions type="OR"> <condition type="isLeaderMembership" /> <condition type="isMemberMembership" /> </conditions> </conditions> </conditions> </restrict-to> <results> <unconditional-result old-status="Pending" status="Pending" step="100" /> </results> <post-functions> <function type="setGroupMembershipRole"> <arg name="role">com.soa.group.membership.role.member</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg> <arg name="groupType">com.soa.group.type.private.apigroup</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg> <arg name="groupType">com.soa.group.type.independent</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> </post-functions> </action>
isCallerGroupMember
Checks whether the logged-in user is a group member; returns Boolean true if so.
Arguments
None.
isMemberMembership
Checks the role of the group membership being managed with the workflow to see if the role is Member (group membership represents member membership). If the role is Member, returns true.
Used in combination with isCallerGroupAdminMember, isCallerGroupLeader, and isCallerGroupMember:
To check the role of the user calling the workflow:
- isCallerGroupAdminMember
- isCallerSiteAdmin
- isCallerGroupAdmin
- isCallerGroupLeader
- isCallerGroupMember
To check the role of the group membership being managed with the action:
- isAdminMembership
- isLeaderMembership
- isMemberMembership
- isSelfMembership
This combination of conditions verifies that the person calling the workflow has adequate rights to perform the action. A group admin can perform actions relating to admins, leaders, or members; a leader can perform actions relating to leaders or members; a member can perform actions relating to members.
Arguments
None.
Examples/Notes/Additional Information
In the example below, the action being performed is to assign an existing group member the role of member (as distinct from leader or admin). The "restrict-to" section tests that the user performing the action is either a group admin or a site admin, or that the user is a group leader and the action is being performed on a group member who has the role of leader or member; and, therefore, that the user performing the action is authorized to do so.
<action id="107" name="group.membership.action.make.member"> <restrict-to> <conditions type="OR"> <condition type="isCallerGroupAdmin" /> <condition type="isCallerSiteAdmin"/> <conditions type="AND"> <condition type="isCallerGroupLeader" /> <conditions type="OR"> <condition type="isLeaderMembership" /> <condition type="isMemberMembership" /> </conditions> </conditions> </conditions> </restrict-to> <results> <unconditional-result old-status="Pending" status="Pending" step="100" /> </results> <post-functions> <function type="setGroupMembershipRole"> <arg name="role">com.soa.group.membership.role.member</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg> <arg name="groupType">com.soa.group.type.private.apigroup</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg> <arg name="groupType">com.soa.group.type.independent</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> </post-functions> </action>
isLeaderMembership
Checks the role of the group membership being managed with the workflow to see if the role is Leader. If the role is Leader, returns true.
Used in combination with isCallerGroupAdminMember, isCallerGroupLeader, and isCallerGroupMember:
To check the role of the user calling the workflow:
- isCallerGroupAdminMember
- isCallerGroupLeader
- isCallerGroupMember
To check the role of the group member being managed with the action:
- isAdminMembership
- isLeaderMembership
- isMemberMembership
This combination of conditions verifies that the person calling the workflow has adequate rights to perform the action. A group admin can perform actions relating to admins, leaders, or members; a leader can perform actions relating to leaders or members; a member can perform actions relating to members.
Arguments
None.
Examples/Notes/Additional Information
In the example below, the action being performed is to assign an existing group member the role of leader (as distinct from member or admin). The "restrict-to" section tests that the user performing the action is either a group admin or a site admin, or that the user is a group leader and the action is being performed on a group member who has the role of leader or member; and, therefore, that the user performing the action is authorized to do so.
<action id="106" name="group.membership.action.make.leader"> <restrict-to> <conditions type="OR"> <condition type="isCallerGroupAdmin" /> <condition type="isCallerSiteAdmin"/> <conditions type="AND"> <condition type="isCallerGroupLeader" /> <conditions type="OR"> <condition type="isLeaderMembership" /> <condition type="isMemberMembership" /> </conditions> </conditions> </conditions> </restrict-to> <results> <unconditional-result old-status="Pending" status="Pending" step="100" /> </results> <post-functions> <function type="setGroupMembershipRole"> <arg name="role">com.soa.group.membership.role.leader</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg> <arg name="groupType">com.soa.group.type.private.apigroup</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> <function type="sendGroupMembershipNotification"> <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg> <arg name="groupType">com.soa.group.type.independent</arg> <arg name="roles">role.group.all.members,role.invited.user</arg> <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg> <arg name="param.groupmembership.role">${groupmembership.role}</arg> </function> </post-functions> </action>
isAdminMembership
Checks the role of the group membership being managed with the workflow to see if the role is Admin. If the role is Admin, returns true.
Used in combination with isCallerGroupAdminMember, isCallerGroupLeader, and isCallerGroupMember:
To check the role of the user calling the workflow:
- isCallerGroupAdminMember
- isCallerGroupLeader
- isCallerGroupMember
To check the role of the group member being managed with the action:
- isAdminMembership
- isLeaderMembership
- isMemberMembership
This combination of conditions verifies that the person calling the workflow has adequate rights to perform the action. A group admin can perform actions relating to admins, leaders, or members; a leader can perform actions relating to leaders or members; a member can perform actions relating to members.
Arguments
None.
authorizeInviteeByDomain
Checks the domain of the invitee to make sure the domain is one of the domains specified as valid. If so, returns true. If the condition is not met, the invitation is not allowed.
This can be used as a security measure to help prevent user error in potentially inviting someone who should not be invited. For example, invitations can be limited to one specific domain for security purposes.
Arguments
Name | Description/Values |
---|---|
domain |
One or more domains that authorization is restricted to. To include multiple values, you can either include multiple <domain> arguments or list multiple domains on one line, separated by commas. Note: the value for this parameter should be the domain name used in Policy Manager for the applicable identity system. For Policy Manager, use Local Domain as the value. |
Examples/Notes/Additional Information
In the example below, this condition specifies that only users on the platform's domain, acmepaymentscorp, can be invited.
<condition type="authorizeInviteeByDomain"> <arg name="domain">acmepaymentscorp</arg> </condition>
authorizeInviteeByDomainType
Checks the domain type of the invitee to make sure it is one of the domain types specified as valid. If so, returns true. If the condition is not met, the invitation is not allowed.
This can be used as a security measure to help prevent user error in potentially inviting someone who should not be invited. For example, invitations can be limited to one type of domain, such as LDAP, for security purposes.
Arguments
Name | Description/Values |
---|---|
DomainType |
One or more domain types (Identity System type in Policy Manager, Domain Type in the Community Manager developer portal), that the action is restricted to. To include multiple values, you can either include multiple <DomainType> arguments or list multiple domain types on one line, separated by commas. Valid values:
|
Examples/Notes/Additional Information
The example below tests that the domain type is Directory Server. This limits invitees to LDAP users.
<condition type="authorizeInviteeByDomainType"> <arg name="DomainType">Directory Server</arg> </condition>
authorizeInviteeByEmail
Checks the email address of the invitee to make sure it matches the email address patterns specified in the argument. If so, returns true. If the condition is not met, the invitation is not allowed.
This can be used as a security measure to help prevent user error in potentially inviting someone who should not be invited. For example, invitations can be limited to one specific email domain for security purposes.
Arguments
Name | Description/Values |
---|---|
One or more specific email address patterns valid for invitations. To include multiple values, you can either include multiple <email> arguments or list multiple email values on one line, separated by commas. |
Examples/Notes/Additional Information
The example below shows the general structure of this argument.
<condition type="authorizeInviteeByEmail"> <arg name="email">Email Address,Pattern</arg> </condition>
The two examples below show different approaches to restricting email address to two domains.
Example 1: Both domains on the same line, with comma separators, using the AND condition:
<restrict-to> <conditions type="AND"> <condition type="authorizeByEmail"> <arg name="email">.*@soa.com,.*@akana.com</arg> </condition> </conditions> </restrict-to>
Example 2: Each domain on a separate line, using the OR condition:
<restrict-to> <conditions type="OR"> <condition type="authorizeByEmail"> <arg name="email">.*@soa.com</arg> </condition> <condition type="authorizeByEmail"> <arg name="email">.*@akana.com</arg> </condition> </conditions> </restrict-to>
authorizeInviteeByGroupName
Checks to make sure the invitee is a member of one of the specified groups. If so, returns true. If the condition is not met, the invitation is not allowed.
This can be used as a security measure to help prevent user error in potentially inviting someone who should not be invited. For example, invitations can be limited to one specific group for security purposes.
Note: If no domain argument is passed, the condition is applied to a platform group.
Arguments
Name | Description/Values |
---|---|
domain |
Optional: one or more domains that authorization is restricted to. Only needed if the group is not a group on the Community Manager developer portal; for example, a Policy Manager group. Defaults to Community Manager developer portal groups. To include multiple values, you can either include multiple <domain> arguments or list multiple domains on one line, separated by commas. Note: the value for this parameter should be the domain name used in Policy Manager for the applicable identity system. For Policy Manager groups, use Local Domain as the value. |
group |
One or more groups that authorization is restricted to. By default, if the <domain> argument is not present, a group name is interpreted to mean a platform group. To include multiple values, you can either include multiple <group> arguments or list multiple groups on one line, separated by commas. |
Examples/Notes/Additional Information
In the example below, this condition specifies that in order to be invited, users must meet any one of the following sets of conditions:
- Be a member of one of these two Community Manager developer portal groups: CM_Group1 or CM_Group2
- Be a member of one of these two Policy Manager groups on the local domain: PM_Group1 or PM_Group2
- Be a member of one of these two groups on the LDAP domain: LDAP_Group1 or LDAP_Group2
<restrict-to> <conditions type="OR"> <condition type="authorizeInviteeByGroupName"> <arg name="group">CM_Group1, CM_Group2</arg> </condition> <condition type="authorizeInviteeByGroupName"> <arg name="domain">Local Domain</arg> <arg name="group">PM_Group1,PM_Group2</arg> </condition> <condition type="authorizeInviteeByGroupName"> <arg name="domain">ldap</arg> <arg name="group">LDAP_Group1,LDAP_Group2</arg> </condition> </conditions> </restrict-to>
Group Membership Workflow: Variable Resolvers
The following variables are available for the group membership workflow:
- ${group.dn}
- ${group.type}
- ${group.membership.request.dn}
- ${membership.id}
- ${member.dn}
- ${groupmembership.oldrole}
- ${groupmembership.oldstate}
- ${groupmembership.role}
- ${groupmembership.state}
${group.dn}
The unique GroupID for the group.
${group.type}
A value indicating the group type as a string in the format ${group.type}.
Valid values:
- com.soa.group.type.tenant.admingroup
- com.soa.group.type.business.admingroup
- com.soa.group.type.internal
- com.soa.group.type.appteam
- com.soa.group.type.api.admingroup
- com.soa.group.type.independent
- com.soa.group.type.private.apigroup
${group.membership.request.dn}
The unique GroupMembershipRequestID. This is the Board Item ID corresponding to the group membership request. All audits related to the group membership are tracked under this request ID.
${membership.id}
The unique ID for the individual's membership in the group; a number.
${member.dn}
The unique User ID of the group member.
${groupmembership.oldrole}
The previous group membership role.
When the setGroupMembershipRole function is used, this variable is set with old role name of the group membership for use in subsequent conditions and functions.
${groupmembership.oldstate}
The previous group membership state.
When the setGroupMembershipRequestState function is used, this variable is set with the state name of the group membership for use in subsequent conditions and functions for the duration of the workflow action being performed.
${groupmembership.role}
The group membership role.
${groupmembership.state}
The group membership state.