Classification and On_Edit script timing issue

[Anonymous]

Hi guys,

I think I'm experiencing a timing issue between when the classification writes to the record.  What I'm trying to do is when I edit an existing record and change the classification, I want it to regenerate my smart number using my on-edit script.  Sometimes it works, sometimes it doesn't work. 

It seems like the record will save first, before the classification items save.  If this happens, my script doesn't pick up the new classification changes.  I have to click edit and save one more time before the smart number calculates correctly.

In my use case, the existing record is AH6110XX.  I edit the classification and save, but the record still shows AH6110XX even though I can see in the classification, the field has changed.  I click edit and save a secodn time without changes, and it then correctly saves as AH6120XX.

Is this a known issue?

[Anonymous]

Hi guys,

I think I'm experiencing a timing issue between when the classification writes to the record.  What I'm trying to do is when I edit an existing record and change the classification, I want it to regenerate my smart number using my on-edit script.  Sometimes it works, sometimes it doesn't work. 

It seems like the record will save first, before the classification items save.  If this happens, my script doesn't pick up the new classification changes.  I have to click edit and save one more time before the smart number calculates correctly.

In my use case, the existing record is AH6110XX.  I edit the classification and save, but the record still shows AH6110XX even though I can see in the classification, the field has changed.  I click edit and save a secodn time without changes, and it then correctly saves as AH6120XX.

Is this a known issue?

[tony.mandatori]

I think you're right.

Classification relies on a separate service at Autodesk.  When the record is saved, this other service is called via rest to update the classification.  So the FLC record is persisted before the classification service is called to store the changes.  If you sniff the post requests in the modern UI, you'll see the classification service being called immediately after posting the payload for the FLC record.

To get around this, you can queue a new item in a separate workspace to perform the update, or perform the update as part of a workflow process after the record is no longer updateable by users..

Does that help?

[tony.mandatori]

I think you're right.

Classification relies on a separate service at Autodesk.  When the record is saved, this other service is called via rest to update the classification.  So the FLC record is persisted before the classification service is called to store the changes.  If you sniff the post requests in the modern UI, you'll see the classification service being called immediately after posting the payload for the FLC record.

To get around this, you can queue a new item in a separate workspace to perform the update, or perform the update as part of a workflow process after the record is no longer updateable by users..

Does that help?

[gasevsm]

Hi Jason,
It is not known issue but it not a desired one either ~ classification saves should be handled by FLC and the script processing should be the last thing that happens to a modified item. This is irrespective if you’ve changed no classification fields i.e. Fields of other sections, changed both non- and classification fields in same edit item operation, or changed only classification fields within that single edit. I recommend you open a ticket with Support against this. The behavior should be deterministic and always run scripting as the very last procedure of a larger edit transaction.
Hope this helps,
Martin

[gasevsm]

Hi Jason,
It is not known issue but it not a desired one either ~ classification saves should be handled by FLC and the script processing should be the last thing that happens to a modified item. This is irrespective if you’ve changed no classification fields i.e. Fields of other sections, changed both non- and classification fields in same edit item operation, or changed only classification fields within that single edit. I recommend you open a ticket with Support against this. The behavior should be deterministic and always run scripting as the very last procedure of a larger edit transaction.
Hope this helps,
Martin

[Anonymous]

Ok Martin, I'll create a ticket. Thanks.

[Anonymous]

Ok Martin, I'll create a ticket. Thanks.

[Anonymous]

I ended up creating and forcing users to regenerate the number after edit and save.  This caused me to add pre-conditions before approving the number.  It works for now.

[Anonymous]

I ended up creating and forcing users to regenerate the number after edit and save.  This caused me to add pre-conditions before approving the number.  It works for now.