How does Harvest approve process works and what does the approval status of a package mean?

Document ID : KB000055193
Last Modified Date : 14/02/2018
Show Technical Document Details

Descriptions:

If users defined in the Harvest approval group left the company and the user-id's were deleted in Harvest, would any packages they approved or rejected need to be re-approved?

How does the Harvest approve process work in different scenarios?

Solution:

Account/role information:

In Harvest, there are four statuses for approval of a package. They are "approved", "rejected", "pending approval" and "frozen". The approval status of packages is dynamic (not static).

When a user right clicks a package in Workbench and selects Properties to invoke the package Properties window. There, the Approval tab's Action field will display "approved", "rejected" or "need". These Actions are static records for a particular package. They are used to derive the package approval status. For example, if the Approval tab's Action field shows one "need" and two "approved", depending on whether there are one or more approve processes defined in that state, that package approval status could be either "pending approval" or "approved".

Furthermore, there is NO action for "frozen" status. However, once the approve process is executed and the package meets the conditions of an approval process , that package will be "frozen". A session log like below will be displayed:

---------- Begin    Process ---------------
I00020136: Approve process successful for package : XXX . Package is frozen.
---------- End    Process ---------------

Once a package is frozen, no change is allowed to that package (for example: checkout for update, delete versions or checkin etc.) nor is that package allowed to be demoted. In contrast, after a package is "rejected", that package will be not frozen. A session log like below will be displayed:

---------- Begin    Process ---------------
I00020135: The approve process was successful for package: XXX . Package is not frozen. 
---------- End    Process ---------------

Of course, changes will be allowed at this point .

Simply put, t he "approved", "pending approval", "rejected" and "frozen" status of a package is relative to

  1. the state where the package is located.
  2. the time when approval action is performed on the package and
  3. the user that executes the action.

Some other details of an approval process:

  1. An approval process is specific to the state where it is defined.
  2. An approval process contains zero or more approvers.
  3. An approver is either a user or a user group.
  4. An approval action is either "approve" or "reject".

The "approved", "pending approval", "rejected" and "frozen" status of a package is dynamic and can change due to the following operations:

  • Promote Package (when packages are promoted)
  • Demote Package (when packages are demoted)
  • Move Package (when packages are moved)
  • Delete User from Harvest (delete user who approved/rejected packages in states with approval processes)
  • Delete User Group from Harvest (delete user group which approved/rejected packages in states with approval processes)
  • Delete User Group Membership
  • Create Approval Process (affects all packages in the state where the approval process was created)
  • Update Approval Process - Add/Delete Approver (affects all packages in the state where the approval process was updated)

A package status is "approved" when:

  • it is located in a state that contains approval processes and
  • it meets the conditions of at least one approval process in the state where it is located.

A package status is "pending approval" when:

  • it is located in a state that contains approval processes and
  • it does not meet the conditions of any approval process in the state where it is located.

A package status is "rejected" when:

  • it is pending approval and
  • an approver has rejected it in the state where it is located.

A package status is "frozen" when:

  • it is located in a state that contains approval processes and
  • in the state where it is located, there is at least one approval process where: at least one approver has approved it and none has rejected it.

An approver is considered to have approved a package when:

  1. if the approver is a user and the user's last approval action on the package is "approve"
  2. if the approver is a user group and there is at least one user from the user group whose last approval action on the package is "approve" and there is no user from the user group whose last approval action on the package is "reject".

An approver is considered to have rejected a package when:

  1. if the approver is a user and the user's last approval action on the package is "reject".
  2. if the approver is a user group and there is at least one user from the user group whose last approval action on the package is "reject".

A package meets the conditions of an approval process when:

  • the approval process does not have approvers or the approval process has approvers and all of them have approved the package.

A package does not meet the conditions of an approval process when:

  • the approval process has approvers and at least one of them either has not approved or has rejected the package.

Below are a few scenarios and expected results:

Case A) Users defined in the Harvest approval group left and the Harvest administrator has either deleted that user or removed that user from the user-group. Since package approval status is dynamic, that package status will change from "approved" to "pending approval". Another user from the same user group has to re-approve that package.

Case B) If the user left is the only user in that approval group or this user is the only user defined as approver, then a second approval process must be defined to act as an override to the first approval process.

Case C) If the user that left has rejected a package, then a second approval process must be created to override since the approval of another user from the same group does NOT override the "rejected" status.

Moreover, if one approval process is defined to have multiple approvers, for example, a user plus a user group, then that single user as well as a member from that group, all must approve a package otherwise that package cannot be promoted.