I want to be able to run a script on the affected items of a CO when they promoted to the new state. I need to spawn some new items each of the affected items once they are released. I have had two thoughts about doing this but I need some input.
Add a script to the transition to the managed state in the change order workflow. This would require me to be able to read the affected items of the change order using a script. Is this possible?
Set up a script to run when each of the affected items are edited. This approach would require that a lifecyle or revison change is an item 'edit'. I'm not sure if this is the case
Solved! Go to Solution.
So for the long wait on the reply but I want to make sure to cover all options and questions that may arise when answering this. If I still am leaving a little confusion in this answer let me know.
Side note- Thank you for the great mental exercise!
Let’s get started shall we?
So looking at the diagram this could be possible but there is one thing stopping us.
How it could work:
You could build to different library workspace building scripts one for Contract items, one for Sales Specifications. Then you would call on these when the Change order item moved through the transition to the Managed state.
Why it won’t work:
Unfortunately with a current limitation on how scripts are executed in the system, if a workspace is spawned there is no way to know what the item is until after the script is done. So Change order would know that Sales were created and Contract was created also, It could also tell the workspaces that “XXXX” Change order created it but Sales and Contract wouldn’t be able to tell the Contact order how to find them.
How you could work around:
If you were to tell and store the parent item (the link to the Change order) in the Sales and Contract item, then on a spate transition with in the spawned workspaces you could have them write back to the original Change Order.
Other possible problems to consider:
Scalability- the more workspaces you are spawning the more time it takes for the JAVA engine to run. This is a variable factor based on what else is happening in the cloud when this is going on. So in theory it could work one time but not the next (theory being the key word here). So now it comes down to testing (lots of it) and a backup plan for how to check if this does fail, so that a failure goes unnoticed.
Once again thankyou for the question and I hope this answers everything!
I spent some time digesting this last night. It seems that none of the proposed solutions will really do what I want them to do. The problem would be corrected if you were able to access relationships via scripts (like grid items). Can you provide me with any idea of when you hope to introduce this funtionality to PLM 360?
If I knew when relationship scripting was coming I would find a short-term manual work-around for this problem.
I know there's already a lot of chat about this in the IdeaStation.
Glad the info helped, but sorry for it not giving you a solution you were looking for.
As for when access to relations via scripting being available? This I unfortunately don’t know at this time.
However because it is under development / review, I would highly recommend joining in and offering your ideas on the conversations about it in the IdeaStation. Not only will you be able to help molded it in the way you would like to see it, but you could also help us understand more about what users like you are trying to achieve with our product.
I think the new 'workflow items' scripting functionality that's been added in the November update will solve my problem. It tool me a while to figure out the syntax but I think I've got it now.
//Load the item in the 'Affected Items' tab using the following;
var linked_item = loadItem(item.workflowItems.id);
//The make a change to any filed in the item using the following;;
linked_item.ORIENTATION = 'Vertical';
etc etc etc
I can create spawned items etc using this method I think.
Great work guys. Keep it up.