Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.

New Approval Type One Approve/One Deny

Idea ID 1646289

New Approval Type One Approve/One Deny

 

Brief

In approval definition, its needed to add a new approval type "One Approve/One Deny" to acheive concept of immediate approval for one operator or immediate denial. Details is listed below and for your info a support case #SD02172015 is submitted before and the support team encouraged me to review the QCCR #QCCR1E64117.

The suggested solution in QCCR#QCCR1E64117 partialy solved the case, what happens is when one of group approve/deny the record be approved/denied, but the issue is after record being approved/denied it still in the other operators as pending approval in spite of the request is already approved/denied before.

Details

In approval definition, I have defined an approval contains multiple operators and selected the Approval Type to be "One must approve by sequence approval level" and used this approval definition for a service catalog item approval.

The approval is working as intended when one operator approves, but the issue is, when one of operators deny the request, it still pending other operators to deny also.

What we need is if one operator approved, the request being approved and removed from the pending approval queue and if one operator denied, the request being denied and removed from the pending approval queue.

Scenario

Always occurs with all approvals

Workaround

Latest used workround- Workaround suggested in the #QCCR1E64117

Old workarounds - Tried to use different Approval Type and different combination,
The last is to add the operators as approvers in an assignment group and used the assignment group in the approval definition, but still not working.

Unacceptable

If one operator denied a request, it still pending other operators to approve or reject and still in their approval queues

Required

If one operator approved a request, it have to be approved and not pending other operators in the same approval sequence level.
If one operator denied a request, it have to be denied and not pending other operators in the same approval sequence level.

 

4 Comments
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

@emad-adly 

We’d like to know why the below workaround does not work. It’s very import to have step by step description which can lead us to the results customer met.  

-          The last is to add the operators as approvers in an assignment group and used the assignment group in the approval definition, but still not working.

Contributor.. emad-adly Contributor..
Contributor..

@Ming-Feng

For example: suppose we need an approval definition (name: new_approval) containing the following approvals in sequence 1- Direct Manager 2- Support Desk Group Approval 3- Security Team Approval the first approval in the list is a role-based approval (defined in the svcAprovalRole table) and the second approval (Support Desk Group Approval) is an assignment group approval. A conflict occurs here, the SM doesn't evaluate or fetch operators from the assignment group, it writes in approval record the pending approval "Support Desk" then show message "Support Desk doesn't have an email address", at this moment, the operators in the assignment group doesn't receive approval notification emails and doesn't have any approval pending in their queues.

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

@emad-adly

If the approval definition contains the group,  SM will fetch operators from the assignment group and send notification to them.  And the operators in the assignment group will receive approval notification emails and have approval pending in their queues. 

If SM cannot fetch the operators from the assignment group and show the incorrect message like you described,  those should be defects.  Please go to submit a support ticket for further investigation. It's better to have detailed approval and notification configurations.

 

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
Status changed to: Waiting for Votes
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.