Computed Fields and scripting

[Anonymous]

I have a workspace that captures travel requests.  Based on the type of travel (Domestic/International), I want the values in some fields to vary.  So, for example, if the type of travel is domestic, I want the value for Flight to be 600$, for example.  If international, the same field should dislay 2000$.  I used a code as below, but I am getting an error.  Please help!

if type_of_travel == 'Domestic'

  est_flight_cost=600;

else

  est_flight_cost=2000;

[jared.sund]

Hello sthimmappa,

You are very close with the syntax below for a scripting solution.   You just need to add parenthesis around the condition in your if statement.

if (type_of_travel == 'Domestic')

  est_flight_cost=600;

else

  est_flight_cost=2000;

I would also add brackets to make the code even more readable:

if (type_of_travel == 'Domestic'){

  est_flight_cost=600;

}else{

  est_flight_cost=2000;

}

One other note, if "type_of_travel" and "est_flight_cost" are both field IDs, then they should be prefix with item.  and capitalized: 

if (item.TYPE_OF_TRAVEL == 'Domestic'){

  item.EST_FLIGHT_COST=600;

}else{

  item.EST_FLIGHT_COST=2000;

}

[gasevsm]

In most of comparison cases, use === as general rule of thumb to avoid false negatives/positives.

Eg. if (item.TYPE_OF_TRAVEL === 'Domestic') {
// do something
}

The == operator will do the trick most of the time, but will compare for equality AFTER doing any necessary type conversions. The === operator will NOT do any conversion, so if two values are not the same type === will simply return false.

Cheers,
--
mg

[Anonymous]

Thank you.  I tried the code as you indicated.  However, I still see this error - attached file.

[dvirh]

Hi Sthimmappa

There are two different technologies that are used for Calculated Fields and for Scripting. The JS syntax as provided by Jared works for Scripting but not for Calculated Fields. Calculated Fields use PostgreSQL format. You may find a reference to it here.

To solve your problem using Calculated Field I used a pick list called ITEM_TYPE that has two possible values in it - Domestic (2) and International (1). Then I created a separate field to calculate the price in the following way:

CASE WHEN ITEM_TYPE = 2 THEN 600 ELSE 2000 END

When using a picklist, it is the order of the item in the list that counts. This is why I use the value 2 in this case.

Hope this helps.

[Anonymous]

Thanks Hagay.

I tried the If then statement and the case statement as previously suggested.  In both instances, I get an error - I had previously attached the screenshot of the error when I used the If- Then statement.  In fact, when I used the Case statement as you suggested, seems like plm did not like it one bit.  When I tried to go to an item record in my workspace, I got an error saying - This is a mystery - this is not your fault.  I have attached that mesage as well.  I contacted tech support when I saw that error and they suggested that i remove the case statement which I did and I can now go back to the Item record.  However, I am still unable to display a default value for the estimated flight cost based on the type of travel.  On that note, I also noticed that when I do add a computed field, the field becomes uneditable.  So my question is -

1) If the type of travel is domestic, I want to display a default value of 200.  If the type of travel is international, I want the default value to display as 6000. However, users should be able to change the rate if needed.  How can I accomplish this?

Thanks,

Sharmila

[dvirh · Accepted solution]

I am really not sure why you are getting an error except that maybe your setup is somehow different from mine. I tested the CASE statement and it is working well for me. Note that you cannot use the IF statement as it is not applicable to computed fields. It is only applicable to scripts. A computed field is not a script.

That said, I now understand what you are trying to do and it is not possible to do that with a computed field. Computed fields, by definition, are not editable.

Here is a different suggestion. Use the Description of the field to say what the defaults should be, and create a script with a behavior to run On Edit to set the value of this field IF the value was not set by the user. This will result in the following:

1. When creating/editing the item the field will be empty, but there will be a comment next to it that explains what the defaults are
2. Once an item is saved, if the field was not filled in by the user, the script will kick in and fill in the appropriate value