Item Details fields with default or required values are always empty when created via scripting

[patrick.fluegge]

Hello everyone,

is it an expected behavior in PLM that when an item is created via scripting  ( createItem("WS_XYZ") ) fields with default or required values stay empty?

For example if you have a field with priority LOW/MED/HIGH and you set the default to MED, the field will have an empty value when it is created from a script.

Also when you set up a field to be required, creating a record via script will not give a warning or error, that there are missing values.

Right, now you need very deep knowledge of the workspace configuration, to avoid this in scripting.

[philipfrench]

Yes, it is expected/known. Whether that is what you want, or not, is another question, but the javascript engine does not respect default values, nor permissions. (The Rest API follows different rules).

You can set the field values automatically via making a script call to /api/v3/workspace/<WS>/fields, and then parse the results, extract the default values, and set them onto a new item.

See script example below. Look at the output of this API call first in the browser, then the example will hopefully make sense.

Making an API lookup like this for every create is poor performance. I would not deploy it in this form myself, but it is a minimal example - albeit nasty looking code. You may be able to take something from the example.

Try the api call in the browser and inspect the response for "defaultValue"...

[patrick.fluegge]

Hello Philip,

thanks for the confirmation.

I'm assuming you are using some other functions to make that GET request? The function "prepareReq()" in line 13 probably contains calls to the 2-legged OAuth and extracts bearer token etc. ?

Considering the limited script runtime of 9 sec., this will probably cause a lot more issues with timeouts. Still interesting though, that we can use such advanced function inside "Actions Scripts".

Best Regards

Patrick

[philipfrench · Accepted solution]

Yes, you guess correct. Google for "prepareRequest" on this forum, and you will find the example library.

You can do a lot in 9 seconds, eg whereused lookup call, or similar, but yes calling APIs from scripts should be a "last resort" option imho. If your solution uses this extensively, my guess is that you are building yourself trouble for the future, and I imagine Autodesk would likely not be sympathetic.

Queries are one thing, but changing data is a bad idea (it will be in a different transaction), and trying to change the actual data that is passed into the scripting session will simply not work. Remember your changes made during scripting are not saved to the database until your script completes.

But as a test-bed to play with the APIs before deploying them to proper middleware, or a proper Rest client, then I think would be ok.

Personally I would like Autodesk to extend the javascript API to allow search queries, where-used, markups, attachments etc to be possible, which will reduce the need for javascript calling v3 API. Having an extra boolan argument to createItem() method, to say "Yes I want to initialise with the defaults", would be a great start.