Hi Jason,

If you’re okay with it, my recommendation will be to write a small & nice event on Approve/Reject action of the ECO to show the users that some of the exit required fields are not filled in.

I don’t see any option to restrict it from criteria level of the Approve/Reject privilege because Agile doesn’t allow using any Redline Item attribute’s value for Approve/Reject type of privilege.

Swagoto is correct.
The simplified script would go something like this:

try {
IEventInfo req = obj.getPXEventInfo();
ISignOffEventInfo objectEventInfo = (ISignOffEventInfo)req
IChange eco = objectEventInfo.getDataObject();

String important_value = eco.getValue(ChangeConstants.ATT_PAGE_TWO_LIST01)

if (important_value == null) {
     throw new Exception (“You need to fill out the important_value field on this ECO prior to approving!”)    }

} catch (Exception ex) {
throw new AgileDSLException(ex);
} // end of try catch block

That should work for you.  Let us know if you need more help.

Thanks for the input everyone.  I figured there would need to be some sort of px created. 

Question on the above code:  

So the approver clicks “Approve” button, does this then invoke this PX, thus halting the approval itself and displaying the message?  I’m trying to prevent the approval from completing so it does not disappear from the approver’s queue.  Thanks.

Jason

Yes, that sample would have stopped a user from approving if the important_value field is null and the eco will stay in the person’s queue.  The message is displayed as a pink-colored banner message on the signoff comment/approval window that pops up like my example.  

And like Swagato mentioned, if the field you need the script to review is a redlined field, you’ll need to get and iterate through the redlined BOM or redlined title block section if you’re looking for whether or not change controlled redlined fields are filled out or not:

private static String check_redlined_titleblock (IItem item) throws Exception {
Iterator titleblock = item.getTable(ItemConstants.TABLE_REDLINETITLEBLOCK).iterator();
while (titleblock.hasNext()) { //start iterating through page two redlines and data
IRow pagetworow = (IRow) titleblock.next();
String important_value = pagetworow.getValue(ItemConstants.ATT_PAGE_TWO_LIST01)

if (important_value  == “value_1” || important_value == “value_2”) {
return important_value 
}
else return null } //done iterating through redlined page 2
}

Just one thing to note –
If you have multiple approvers responsible for populating different required fields (or maybe some reviewers are responsible for populating data and some are not) in the same status – going about it this way would likely prevent some approvers from approving even if their portion IS complete/populated.   This can lead to things being held up even longer as most users don’t want to have to be constantly checking on the routable object just to see if they are able to approve it yet. 

If/When this is the case – I think it is best to leave it to the routing manager to sort it out.  Upon receiving the ‘auto-promote failure’ notification – the routing manager should run a status audit to see what is missing and then contact the appropriate reviewer to populate the missing information.

It also helps to train users to get in the habit of always running a status audit prior to approving, though that is not at all fool-proof.  
 

True – I’m thinking about the technology solution here though certainly many of us think in either people or process terms that would make for a better, more comprehensive solution.
The solution my screenshot example uses works to get the session’s current user (i.e., the user approving), the Deviation Originator, and then if the person approving is the Deviation originator and 
closure statement field is null or blank, Agile throws an error and blocks the originator from approving.  The script runs for everyone else but since they (the current user signing) is not the Originator, Agile skips over that part in the script and just lets them approve.  Therefore, this same method can be applied to look at different fields for different users, like say getting their job titles and forcing different actions based off of someone’s job title.  Again, not to undermine good processes and good training, of course.

Here’s the real kicker… I see that you’ve coded for a particular attribute. Can we mine the workflow criteria to look for the exit required fields?  If not then I can see some maintenance issues.

Additionally, I’m not sure we could address the below

Affected items Criteria 1 – required field A (Approver A)
Affected items Criteria 2 – required field A&B (Approver B)

Two documents on on the same ECO with 2 approvers.  As to Danny’s point, I’m thinking the above PX would error on both approvers no matter who approves first.

Hi Jason,

If you wanna get the exit required fields from a workflow criteria with SDK, here is the piece of code you can use:

IWorkflow wf = (IWorkflow) session.getAdminInstance().getNode(NodeConstants.NODE_AGILE_WORKFLOWS).getChildNode(“My Sample Workflow”);
INode child;
for(IStatus status : wf.getStates()){
              System.out.println(“For status “+status.getName());
              for(Object obj : status.getChildNodes()){
                          child = (INode)obj;
                          for(Object o : child.getChildNodes()){
                                  System.out.println(“For workflow status criteria: “+((INode)o).getName()+”, the exit required field is: “+((INode)o).getProperty(new                                                                    Integer(202)).getValue().toString());
                          }
              }
}

Would using the audit() method in the API not be more useful/simple if it’s simply “Exit Required Fields” we’re concerned about?  Then you could loop through the map that gets returned and spit out the missing required fields?  Don’t have a tonne of experience with this via API but looks like that could work…

I think we’ve decided to go down the path of developing a PX to do the following (In theory)

Turning auto-promote off for the status of the workflow

1.  User clicks approve, and approve on the ensuing pop-up
2.  PX will validate required fields as below (assuming user is the last one to approve that status – more on that later) 
    a.  Attempt to promote the status
    b.  Ignore “Approver” warnng message
    c.  If it recieves error for required fields (display message to check audit status) and won’t finish approving
    d.  If no errors, advance the status and finish approval

Question:  Is anyone aware of a method to determine the last approver if there are multiple approvers?  We could query it, but wondering if there is an easier way.

Thanks.