Thanks you, Nimish – that worked.

Ok, we figured it out.  Let me just document it here for anyone else. 
We weren’t sure if our import statements were conflicting, so we minimalized that.  But mostly it was the object.  Agile already specifies the object during whatever action is happening (hence why most examples leave it off).  So if your trigger (Event node) is updating the affected items tab of an ECO, Agile will already use that ECO as the Object (part of the sendNotification syntax).  Check the Event Handler Monitor for the Object that is specified. 

As a result, this worked for us:

//

import com.agile.agileDSL.ScriptObj.IBaseScriptObj;

import com.agile.agileDSL.ScriptObj.AgileDSLException;

void invokeScript(IBaseScriptObj object) {

try {

object.sendNotification(“Designs – Test Email”, false, [“userid”], “Comments: send from Script handler test with fake send notification”);

} catch (Exception e) {

object.logMonitor( e.getMessage() );

}

}

Event itself is updating the relationship tab of a Design (subclass).  Note that the Notification email Object type needs to match the notification type in the groovy script. 

I’m looking to now build on this for future use. 

I had just made it work using groovy script PX for Design objects.  This is part of a script that creates a new Design file after an event.

IDesign des =
(IDesign)m_session.createObject(“Design Deliverable”, “DESIGN-0082”);
(IDesign)des.setValue(6174, “test 6/8 test”);
(IDesign)des.setValue(6390, “Concept”);

Where line 2 is the new number to create (“Design Deliverable” is my subclass”); line 3 is the new description to be added; line 4 is the starting lifecycle.  Those numbers are the base ID found on the class tab next to the attribute ID column.

Perhaps this advice helps anyone in the future

And you’ve tried exporting an Advanced Search using something like this, correct?

Hi Sunny,
Remember, duration is in hours.  2 hours versus 20 hours probably didn’t make a difference for your search.

As for brackets versus parentheses, I think it’s a Groovy programming thing (though I’m not a programming expert).  You’ll only need brackets for workflow searches, like you’re using above.  Use parentheses with all other logic applications, just like you would with doing basic math problems. 

And for your CM metric report, you may have to be more specific.  The search above will pull all Change Orders over 2 hours in PE Approval with X users awaiting approval.  Submit to PE Review, as a measurement of past performance, can be found using the Change Metric Report and/or the Change Cycle Time Report.  A search like what you have above will show current status, though you can tweak what you have above for something like, “All Change Orders Released Greater Than 1/1/17 that sat in Submitted Status Greater than 48 hours”.

If at the end you can’t figure it out (sorry, I’m not an SDK pro), worst case scenario is that the Change Package Report can run multiple Change Orders at a time.  If it comes to that, run all of them at the same time in a single Change Package Report.

Hi Sunny,

Use brackets in the same way as parenthesis.  On the left and right sides. as you would when adding parentheses, click on the circles.  Then, down at the bottom of your screenshot you’ll see the “Grouping” button.  Choose brackets.  In your search above, all three lines will be in the same bracket.  This will solve #1 and #2 of your question. 

I’m quite sure you’ll need to use “Equals To” instead of Contains, by the way, for Approver Action (I seem to remember that causing issues when I was teaching myself how to use the workflow searches). 

Also, use $CURRENT.STATUS as part of the bracketed attribute.  You’re results, as-is, will pull Change Orders where a person didn’t sign, the change was rejected/returned, and then the user signed in Round 2 CCB and now the ECO is closed.  Then you can add a Cover Page status at the bottom to specify “Change Orders with PE Approval CCB” if you want.  Using $CURRENTSTATUS will pull just the current status (aka, current round of approvals)

Yes, so Duration uses Cover Page status while Approval/Observers use Workflow Status.

Hi Arif,
I had a recent case where instead of “IAgileSession session = obj.getAgileSDKSession();”, I had to use “m_session = object.getAgileSDKSession();”.  And instead of “obj.logMonitor…”, I had to use “object.logMonitor…”
Not 100% if either one is important right now, but those were edits I did with another one of my scripts as my IT programmer and I tried to make work. 

With Duration, make sure you’re using the brackets “[” and your error should be referring to the actual Cover Page Status at the top of the attribute search drop down (same Status field you’d use if you wanted to see all ECOs in Submitted status, for instance). 

See my attached example.  It’s a search called “Changes that Require My Approval” but I’ve added a Duration field (remember, duration is in hours).  It’s a good example of when you’d use Workflow Status versus Cover Page status.  Your search will mimic the bottom two lines I have.

Another option that wasn’t brought up here is a CCB group.  Probably not the best option for you specifically but might be worth it for some managers who have to delegate a lot.  Here, you would create a User Group and add your User 1, User 2, and User 3.  When you route your ECO, add the CCB User Group to the list of approvers (either manually, ad hoc during review, or using workflow criteria).  First person who signs, approves for the group.  Think of it as a sort of auto-delegating for those who need to do it often.