JavaScript Automation Rules Improvements | Targetprocess Release

4 days ago

JavaScript Automation Rules Improvements

At the end of last year we released our long-awaited Automation Rules feature. Our goal is to help you automate various tasks inside Targetprocess.

While some automations can be configured with a graphical user interface, our JavaScript support takes the flexibility of Automation Rules to the next level. Writing your own JavaScript may seem daunting at first, so we want to make the editing experience more user-friendly. Here's a brief overview of recent changes we've made to make your life easier.

Better Suggestions

The JavaScript editor now knows which fields exist inside args and provides typing assistance, including the name of existing custom fields.

Suggestions for JavaScript editor

Automatic Script Formatting

Pressing the "Enter" key, or typing a special symbol like ; at the end of a statement, or } at the end of the object definition, now automatically formats the source code, making it more readable for you and your teammates.

 

You can also press Shift+Alt+F any time when the cursor is inside the editor to force the formatting.

Error Analysis

The editor now automatically analyzes the source code and reports both syntax and semantic errors, like an incorrect usage of the Targetprocess API or JavaScript constructs.

Error Analysis in JavaScript editor

Case-Insensitive Field Access

JavaScript is a case-sensitive programming language, so the following 2 lines of JavaScript in automation rules should behave completely different:

const featureName = args.Current.Feature.Name; // this works
const featureName = args.current.feature.name; // this doesn't work =((

However, Targetprocess users are accustomed to not thinking about such things when using filters, configuring metrics, or building visual reports. So we added some magic to our JavaScript, and now you can use both lower- and upper-case names for args and API v2 results in Targetprocess automation rules.

Here's the old script, in which we had to mix both lower- and upper-case field access, causing a lot of confusion.

const response = await api.queryAsync('UserStory', {
  select: '{Id,Name}', // Script explicitly asks for UpperCase field names
  where: `Id=${args.Current.Name}` // And uses UpperCase `args`
});
// But API v2 results were always in lowerCase format
const name = response[0].name; // response[0].Name would be undefined

With the new release, the casing doesn't matter, you can use whichever option you like.

const response = await api.queryAsync('UserStory', {
  select: '{id,name}',
  where: `Id=${args.current.name}`
});
const name = response[0].name; // but response[0].Name is valid if you prefer it

For those interested in technical details: the magic is powered by proxies.

New Names For args

We also did some rebranding in "args department" to make it more clear what different fields mean.

args.Changed.Name; // old format
args.Current.Name; // new format: `Changed` is replaced with `Current`

args.Original.Effort; // old format
args.Previous.Effort; // new format: `Original` is replaced with `Previous`

The old format will still work for a while, but we strongly recommend migrating to the new one.

That's it for improvements today. Stay tuned for other cool automation things we plan to roll out soon!

You can subscribe to our monthly newsletter here:

Thank you!

Сheck out latest blog posts:

Get Started for free

Enter your email
By clicking "Continue", you acknowledge that we will process your Personal Data in accordance with our Service Privacy Policy and Terms of Service, and agree to the aforementioned documents.

We’ve sent you a confirmation e-mail — please, go check it.

Or get a live
product demo