Multiple Selection pick list type does not float to the latest version automatically.

[b_sugumar]

Hello,

We want to add Spec documents to the Item workspace using a multi-select picklist, with the Spec documents being created in another workspace. When these documents are revised using a Change Order (CO), the latest revision should automatically update in the item attribute. However, it appears that the multi-select picklist does not automatically reflect the latest document revision. Is there a way to use a script to capture the DMSID of the latest revision and replace the previous DMSID, ensuring the document remains latest?

Does this approach actually work?

[philipfrench]

In picklist options, you need “Latest”. But as you detected, “Latest” is not available with multi-picklist.

It’s a limitation Autodesk should address.

Well, you could add the Specs to the BOM. Then you have control over which versions you see.

But I suspect you don’t want that.

The “Latest” option (single select) will display the latest revision, and it figures this out when the page is displayed.

Under the covers, the picklist will still point to the original (superseded) revision, a script will also notice this, but the page displays to the user the link to the latest revision.

In other words, the Item is not actually updated when the Spec is released.

The only way, as you suggest, would be to update the Item itself when the Spec is released.

It’s not a great solution, and it’s also quite difficult to code.

The trick is to find a trigger to run the code.

An easy way is to use the on-edit on the Item, to loop through the Spec list, and adjust the entries to the latest revision.

However, this will require an on-edit of the Item, and this will not happen when the Change Order releases the Spec.

A better place for the trigger is the “release” transition of the Change Order.

The trick is to use this to loop managed items (Specs), and navigate Spec --> Item, and update the picklist on the Item to point to the Working Revision of the Spec.

This Working Revision is the dmsid that is in the process of being released.

After the release, the Item will point to the released revisions of your specs.

The problem is navigating Spec --> Item.

Your Item has a link to the Spec, but not the reverse.

So you need an on-edit on the Item to maintain the bidirectional link Item --> Spec --> Item.

I expect this is a many-to-many relation?

If so, the best way is to let the Item add its dmsid to a list of dmsids on the Spec (in a string field).

Or, if you are not using the relationship tab for anything else, then let the Item on-edit add the Specs to the relationships tab with bi-directional option (and remove any on the rel tab that are no longer present).

In this way, you have the ability to navigate Spec --> Item (either with the reverse link, or using the rel tab), but you will need to do this for all revisions of your Spec, because the Item may have informed the Spec it is his parent in an older revision of your Spec.

This is around 100 lines of code, and it is not ‘beginner level’.

If you have very many Items referring to the same Spec, then you risk a time-out.

In fact, the above approach is very much the ‘last resort approach’. It is a poor data model too.

You might be better with 10+ fields SPEC_1, SPEC_2, etc – all single select and hope the user never chooses too many(!)

[b_sugumar]

Thanks @philipfrench .

I would rather have multiple fields with a "latest revision picklist" type that updates the document revision whenever the item is refreshed.

One issue I’m encountering involves slicing the document descriptor to extract just the document number and revision, like "DOCUMENT1 - 10 -", and storing it in a new field (field1). However, when the document undergoes a revision change, such as to "DOCUMENT1 - 11 -", the main spec doc field updates automatically, but field1, which holds the sliced value, still retains "DOCUMENT1 - 10 -". It only updates if I manually edit the item.

I tried updating a dummy field through a workflow, but the latest revision picklist type field does not refresh. Only when the spec doc field is refreshed or updated does the sliced field1 get updated with the latest revision.

Not sure if this limitation on that field.

[philipfrench]

Yes, that is what I meant when I said the script still sees the old revision.
Under the covers it is still pointing to the new old revision, but the latest revision is changed as the page is displayed.

You could try another approach...

Have a integer on your Spec Document called "REV_COUNTER"

You can try to increase this counter in the release transition of the CO, i.e. as it is being released.
(
loop item.workflowItems, and you need something like this
item.workflowItems[i].item.REV_COUNTER++;
)

Then on the Item, you can derive the REV_COUNTER to see the revision of the doc.

A recent improvement by Autodesk was to make derived fields source from the true Latest (i.e. what the user sees, not what a script sees).

But definitely try this out manually before you start scripting.

Try editing the counter manually on the working revision just before a release.

Test that the derived Spec field on the showing on the Item is behaving as you expect.

If yes, then your challenge is to update the counter just before release, and hopefully your REV_COUNTER will correctly align with the actual revision.