Discussions Workflow

This section provides information about functions, conditions, and variables for the Discussions workflow, as well as initial actions and reserved actions.

Table of Contents

Discussions Workflow: Initial Actions

The initial actions valid for Akana API Platform workflows relating to discussions are:

@StartDiscussion

This is how a discussion is introduced into the workflow. If you are customizing the initial behavior when a discussion is added, this is where the customization needs to go.

@Audit

An initial action that could be used to initiate a discussion for audit purposes.

@Alert

An initial action that could be used to initiate a discussion as the result of an alert—for example, SLA or quota alerts.

Discussions Workflow: Reserved Actions

The following reserved actions are defined for Akana API Platform workflows relating to discussions:

@read

Applies to unpublished discussions only.

This action controls who can read an unpublished discussion. When the @read action is available, read permission is available for someone to read the discussion in an unpublished state. If @read is not available for a specific user for the current state of the discussion, the user cannot see it.

Once the discussion is published, all users who have visibility of the resource can see it.

Discussions Workflow: Functions

The following functions are available for Akana API Platform workflows relating to discussions:

MarkPublished

Marks a discussion as published. This might be used in a scenario where the Moderator has determined that the discussion meets guidelines, or if discussions are not moderated.

Parameters

None.

Examples/Notes/Additional Information

The example below shows part of the workflow for a pending discussion. It can be approved for publication; the workflow restricts the action to certain authorized roles. The status is changed from Pending to Published, and the markPublished function is run.

<step id="200" name="Pending">
  <actions>
    <action id="201" name="discussion.action.approve.publish">
      <restrict-to>
        <conditions type="OR">
          <condition type="authorizeByAtmosphereRole">
            <arg name="role">SiteAdmin,BusinessAdmin,SubjectAssociatedApiAdmin</arg>
          </condition>
        </conditions>
      </restrict-to>
      <results>
        <unconditional-result old-status="Pending" status="Published" step="300" owner="${caller}" />
      </results>
      <post-functions>
        <function type="markPublished"/>
      </post-functions>
    </action>

markUnPublished

Marks a discussion as not published. This might be used in a scenario where the Moderator has determined that the discussion does not meet guidelines.

Parameters

None.

Examples/Notes/Additional Information

The example below defines valid actions for a discussion in the Published state. One valid action is for the discussion to be unpublished. The workflow first checks that the action is being performed by an authorized user. If so, the discussion is moved from an Approved state to Pending, and the markUnPublished function is run as a post-function.

<step id="300" name="Published">
  <actions>
    <action id="301" name="discussion.action.unpublish">
      <restrict-to>
        <conditions type="AND">
          <condition type="authorizeByAtmosphereRole">
            <arg name="role">SiteAdmin,BusinessAdmin,Author,SubjectAssociatedApiAdmin</arg>
          </condition>
        </conditions>
      </restrict-to>
      <results>
        <unconditional-result old-status="Approved" status="Pending" step="200" owner="${caller}" />
      </results>
      <post-functions>
        <function type="markUnPublished"/>
      </post-functions>
    </action>

deleteDiscussion

Deletes a discussion.

Parameters

None.

Examples/Notes/Additional Information

In the example below, for a discussion in the Rejected state, delete is a valid action. The workflow first checks that the user is authorized to perform the action. If so, the discussion is moved from the Rejected state to the Finished state, and the deleteDiscussion function is run.

<step id="400" name="Rejected">
  <actions>
    <action id="402" name="discussion.action.delete">
      <restrict-to>
        <conditions type="AND">
          <condition type="authorizeByAtmosphereRole">
            <arg name="role">SiteAdmin,BusinessAdmin,Author,SubjectAssociatedApiAdmin</arg>
          </condition>
        </conditions>
      </restrict-to>
      <results>
        <unconditional-result old-status="Rejected" status="Finished" step="500" owner="${caller}" />
      </results>
      <post-functions>
        <function type="deleteDiscussion"/>
      </post-functions>
    </action>

sendNotification

Triggers the specified notification based on an event relating to a discussion.

Note: The email isn't sent instantly; it is queued to be sent. It goes to the notifications queue, and the job runs every 60 seconds. There might be a short delay before the user receives the email.

Parameters

Name Description/Values
subjectType

Indicates the type of resource the notification relates to. Valid values:

  • apiversion
  • app-version
  • group
  • board
Role

The role to which the notifications will be sent—only users who hold this role for the type of resource as specified in the subjectType parameter. Valid values:

  • SubjectAdmin
notificationType

The type of notification being sent. Can be any valid notification existing in the platform. For example:

  • com.soa.notification.type.api.post.created (for an API)
  • com.soa.notification.type.app.post.created (for an app)
  • com.soa.notification.type.group.post.created (for a group)
  • com.soa.notification.type.board.post.created (for a board)

Examples/Notes/Additional Information

In the example below, the workflow is set up so that a review added by an administrator is approved automatically. When the review is published, a notification is sent to applicable admins. A different notification is sent for an API review versus an app review.

<action id="102" name="Auto Approve Auto Publish" auto="TRUE">
    <restrict-to>
      <conditions type="OR">
        <condition type="authorizeByAtmosphereRole">
          <arg name="role">SiteAdmin,BusinessAdmin</arg>
        </condition>
        <condition type="isAutoPublishEnabled"/>
      </conditions>
    </restrict-to>
    <results>
      <unconditional-result old-status="none"  status="Published" step="300" owner="${caller}" />
    </results>
    <post-functions>
      <function type="markPublished"/>
      <function type="sendNotification">
        <arg name="subjectType">apiversion</arg>
        <arg name="role">SubjectAdmin</arg>
        <arg name="notificationType">com.soa.notification.type.api.post.created</arg>
      </function>
      <function type="sendNotification">
        <arg name="subjectType">app-version</arg>
        <arg name="role">SubjectAdmin</arg>
        <arg name="notificationType">com.soa.notification.type.app.post.created</arg>
      </function>
      <function type="sendNotification">
        <arg name="subjectType">group</arg>
        <arg name="role">SubjectAdmin</arg>
        <arg name="notificationType">com.soa.notification.type.group.post.created</arg>
      </function>
      <function type="sendNotification">
        <arg name="subjectType">board</arg>
        <arg name="role">SubjectAdmin</arg>
        <arg name="notificationType">com.soa.notification.type.board.post.created</arg>
      </function>
    </post-functions>
  </action>

Discussions Workflow: Conditions

The following conditions apply to the discussions workflow:

isAutoPublishEnabled

Checks the platform settings to determine whether a discussion can be automatically published; returns true if so. If false, new discussions require moderation.

Arguments

None.

Discussions Workflow: Variable Resolvers

There are currently no variable resolvers for Akana API Platform workflows relating to discussions.