I have a behavior that is doing the following:
1. Iterate through all rows on a grid
2. Collate grid rows corresponding to particular vendors
3. Create new items in a different workspace, one for each unique vendor found in step 2
4. Populate the grid of each item created in Step 3 with information from the original grid
To accomplish this I have two scripts. The first script does the collation and creates the new records. As part of this, it passes information to the new records for building the new records' grids.
The second script should run on new item creation in the second workspace. This script parses the grid information passed from the original script and builds the grid.
I have all the logic working for all aspects of the behavior, and it works great. The only problem is that the second script is not running for every newly created record. To attempt to resovle this, I changed the grid manipulation script to run on item edit instead, thinking maybe it was a timing issue. It still doesn't work.Here's an example:
The original record (an order record) has on it three line items. There are two unique vendors that provide these items. This means two purchase order records will be spawned. I've tested this about 10 times now, and each time only one of the new PO records gets its grid populated. The information to build the grid is being passed, but the grid is not building. Here is the change log of the PO that worked:
Notice that all record changes happened between 8:50:44 and 8:40:45. Both scripts worked in conjunction perfecty. The scripted Item Edit happening at 8:50:45 to change the Notes field is from a script that runs On Creation. The other item edits (GRIDFIELD, notes, and grid row building) happen in a script that runs On Edit.
Here's the change log from the second PO:
Notice that this item was created at 8:50:45 as part of the original script, but that the item edit that should have occurred immediately (as a result of the On Create script) *did not* happen. The Item Edit in the above log was manual, 3 minutes after it was created. I did that to test that the script and data on the record was otherwise correct, and it is - the grid is successfully built.
So my question is this - why is the On Create script not running for both records?
If I understand you properly, a item created by a script is equivalent to an item being imported. Which boils down to the system not running a on creation script.
The system is setup to do this for failsafe reasons.
I'm doing that all over the place. I have several records where at some point in their workflow I want to spawn other records in different workspaces, and those new records need to have some or all of the grid row items from the original.
I'm accomplishing that by passing some information as part of the record's properties (in this example the GRIDFIELD property), then relying on a script that runs on creation in the new workspace to parse that information and add the grid rows.
I've resorted to this method because I was told that we couldn't directly manipulate the grid of a newly spawned (i.e. via createItem or createNewItem) item directly. And this method for the most part is working just fine, so either there's an issue with the on creation script running when it shouldn't, or not running when it should. Here's the general behavior I'm seeing:
1. Spawn ONE new record via script in workspace A
- On Creation script for workspace A runs and works beautifully
2. Spawn TWO or more new records via script in workspace A in quick succession
- On Creation script for workspace A will run for one record, but no others
If you're telling me that the behavior I'm seeing in case 1 above is not intended, then if and when that is fixed everything I've spent the last month doing is going to fall completely apart.
If Case 2 is a result of some sort of 'cooldown' for On Create script execution (which would be my guess if the behavior I'm seeing isn't a defect) then I guess what we want to do just won't work, and we'l have to resort to some other method.
Is there any more feedback on this script behavior.
Is it intentional that if a script spawns more than one record it is treated like a record import and stops executing any on create or on edit scripts from running on the additional creeated records?
As Forrest described, we have the need to create multiple records based on user selection, but our list is finite. Meaning that even if the user selected all the possible records to spawn for, the script will only create a set amount of records. Yes the potential exists for enough records to be created to hit the script time out, but I would rather have that happen then script action just not execute and the user not know why.
So can we get feedback on this behavior and is this how Autodesk intends for the on create behavior to work. I.E. execute the script for "on create" for one record creation at a time. We need to know inorder to plan out how we will work around it for our desired workflow.
The rule for spawning is that only the first spawned item in each workspace within the same script will have its OnCreate script run.
So for your particular case, you can easily work around the problem by adding all the code you want to the spawning script. It gets a bit tricky if there are multiple ways to spawn the same type of item and one of those ways is manual (direct). In that case, you need to add a condition to the OnCreate that will figure out how the item was created.
Thanks for confirming the behavior we were seeing and we are already doing something similar to what you suggest but our ultimate goal is to create information in the spawned records grid.
As we understand things the grid is not accessible for adding rows until after the On Create event is complete (I.E. having an dmsID to store the grid items). Our current set-up is as follows
1. In our spawing script we are storing the grid information in a field on the item details, through the newProperties array of the on create library script in the spawned records.
2. We then have a script which reads that field and splits the information and creates the grid rows. This script is set to the On Create and On Edit behaviors for the spawned workspace.
Since the On Create script is not running for the second & remaining spawned records their grid does not update. We are currently forcing our user to edit information on the item details as part of the workflow, which triggers the On Edit script to update the grid for those additional records. if we knew that we could automatically trigger (from the spawning script) the on edit after the on create script we could just put a loop in to run through the spawned records to execute that script. But it seems we run into order of operation condition which prevents access to the record to update or save information (i.e. the records are locked by other scripts) in trying to do this?
So for your particular case, you can easily work around the problem by adding all the code you want to the spawning script.
As Bob described above, what we're trying to do (add new grid rows) can't be done in the spawning script, at least based on my testing and confirmation from Michelle Stone (after discussing with development). Believe me, I'd love it if we didn't have to worry about the workaround...it's caused a lot of headaches.
To work around the On Create script run limitation for only the first item, we need to be able to do this:
var spawnedItem = createItem("WS_MYWORKSPACE", newProperties); var spawnedItemGrid = spawnedItem.grid; var newRow = spawnedItemGrid.addRow();
and we can't. From what I can tell, we're stuck. We'll have to introduce something into our workflow to get grid rows created for records beyond the first spawned record.
Something else just occurred to me though. All of these workspaces we're working with have workflow. I'm going to test now, but if the action script for the first workflow transition executes for all records (and not just the first spawned one) then that could be our way to get our code to execute.
So far my initial testing has borne fruit. It appears that not only will an action script assigned to the initial transition of a workflow run for all created items, but the grid can also be modified via that script.
I did encounter errors, however, when attempting to edit item details in that action script. I'm not sure if this is intended, but based on my testing I found the following:
If an action script running as a result of the initial transition of a workflow modifies any item detail field, an error is thrown and the record is not created. Here's the error log:
The action script was simply trying to set a Single Line Text field's value to something static. That was the only line of code. Of the two scripts above, the TEST_CREATE_RFQs script runs on edit of an RFQ record and spawns three test records. Test_Multi_Spawn_Transition runs on the first transition of the RFQ workflow, and the above errors are thrown when attempting to edit item details. Adding and editing grid rows, including accessing item details fields to populate those grid rows, works without issue.
I did test the Test_Multi_Spawn_Transition script (that runs on the first workflow transition) alone when creating new items, and I got the same error. Now that I think about it though, my test environment may have caused the problem, if the item detail edits were triggering the creation of new records, triggering more item edits to trigger more records, etc.
Access a broad range of knowledge to help get the most out of your products and services.