Filtered Picklist - Scripting Access No longer available with June Update

[Anonymous]

I hope I am doing something wrong,

It seems that you can no longer get the value of a field if it is a filtered picklist type, this has caused several scripts that were working to now give us multiple different errors. They all seem to be pointing to the fact that now after the update that when you try to read the value of an Item details field that is a filtered picklist type is always returns null instead of the selected value. which is what it did before the update.

A simple test on an existing workspace dmsID showed us this, for example running the following agains an existing record.

println(item.CONTACT), Used to return the picklist value, now returns null

if I change the field to single selection (Item Descriptor) the prinln function then returns a value (the selected records Item Descriptor)

Is this now the behavior for picklist fields? That would be a problem, in the above example we are sort of duplicating the use of derived fields but we are using this functionality of being able to read the filtered picklist values to the point us to a workspace and iterate through all the records and collect (sum, Match etc.) information to update records being added in the same or other workspaces. If we cannot read these values we lose the ability to match to the unique records those selections may point to.

Please advise?

Bob Donovan

[Anonymous]

Bob,

I'm also experiencing a problem related to filtered pick lists and scripting. Autodesk are currently looking at it for me. The issues may be related (or they may not be). I'll keep you posted.

David.

[Anonymous]

Thank you David,

I have been developing and in the process to utilzing filtered picklist functionality to control and verify through workspace record polling the processing and push of information stored in multiple records into downstream processes.

If I can't read the filtered picklist values then the whole premis of using them to iterate through workspace records looking for matches is broken.

I look forward to a good resolution to this for you and me.

Thanks again.

Bob Donovan

[bastien.mazeran]

Hi Bob,

I have escalated this issue to a support case and will continue to update you on progress.

Regards,

[Anonymous]

Hi Bob,

Can you tell me a little bit more about your script? It sounds very interesting.

David.

[Anonymous]

// Process Customer Information to Update Information Fields if info selected
if (item.CONTACT !== null || item.SHIPPING_ADDRESS !== null || item.CUSTOMER_ID !== null)

{


// Load the record that contains a list of all Customer Information record dmsIDs

var customerList = loadItem(874);


// Build array of dmsIDs from the single pipe delimited string

var customerIDs = customerList.RECORDSLIST.split("|");
var customerInformationRecord;



// iterate through each dmsID and store matching record (Must match Contact Name, Shipping Address & Customer Id)

for (i=0; i < customerIDs.length; i++)

{

try

{

var custItem = loadItem(customerIDs[i]);


// Check against contact first - this is the most likely unique identifier

// and so will prevent later checks upon failure and speed up script operation

if (custItem.CONTACT_NAME == item.CONTACT)

{

// Check against address

if (custItem.ADDRESS1 == item.SHIPPING_ADDRESS)

{

// Check against customer ID

if (custItem.CUSTOMER == item.CUSTOMER_ID)

{

customerInformationRecord = custItem;

break;

}

}

}

}

catch (err)

{}

}


// Now that we have the customer information record set all of the

// Sales Quote Address & Contact properties based on the CI properties

if (customerInformationRecord !== null)

{

item.ADDRESS2 = customerInformationRecord.ADDRESS2;

item.ADDRESS3 = customerInformationRecord.ADDRESS3;

item.CITY = customerInformationRecord.CITY;

item.STATE = customerInformationRecord.STATE;

item.ZIP_CODE = customerInformationRecord.ZIP_CODE;

item.COUNTRY = customerInformationRecord.COUNTRY;

item.CONTACT_PHONE = customerInformationRecord.PHONE;

item.EMAIL = customerInformationRecord.EMAIL;

}
}

// blank address fields if picklist fields not selected
else

{

item.CONTACT = null;

item.SHIPPING_ADDRESS = null;

item.CUSTOMER_ID = null;

item.ADDRESS2 = null;

item.ADDRESS3 = null;

item.CITY = null;

item.STATE = null;

item.ZIP_CODE = null;

item.COUNTRY = null;

item.CONTACT_PHONE = null;

item.EMAIL = null;

}

[Anonymous]

Thanks Bob. Very interesting.

So you've created a way to search through a set of records (e.g. a workspace) to find a matching record? I guess you need to create the customerList.RECORDSLIST list yourself manually? I'm curious - do you not get script timeout issues when you run this? How many records are in the list?

David.

[Anonymous]

David,

That is correct. The catalyst was the teaser introduced by filtered pick
lists and derived fields that then did not work together. This is our
attempt at doing just that.

So far our lists are small. 50-100 records and I have not run into
script timeouts.

But we are very conscience of that issue and we try to set our matching
criteria up to minimize looping through the records.

Yes for each workspace you want to be able to iterate through I have to
create a new record in my "Lists for Scripting" workspace and in my
scripts I hardcode the dmsID of that record when I target the retrieval
script.

But once it is set up it will always update when new records are created
due to my create behavior script, and I just need to remember to run the
maintain scripts to prevent script errors when you encounter deleted
records. Which could get more frequent as users and functionality are
added in our companies use of PLM, which if they continue with the
improvements could be substantial for us. We are a project based company
and have very manual processes & procedures that we use to execute our
project plans. PLM is perfect for automating, enforcing and documenting
those processes.

We discussed the feasibility of this idea in these support forum posts
and ultimately generated the below Idea Station Ideas to get a better
solution, but we'll see.

http://forums.autodesk.com/t5/Autodesk-PLM-360/Idea-for-accessing-filter
ed-pick-list-items/td-p/3676070

http://forums.autodesk.com/t5/Autodesk-PLM-360-IdeaStation/Query-items-i
n-a-workspace-based-on-FieldID-values/idi-p/3679650

BD

[michelle.stone]

Just want to say this is the beauty of a community forum - customers working together to brainstorm and share ideas.

Love it!

(and Bastien will continue working the issue, it's just nice to see the forum being used as intended as a way for PLM admins to connect and share)

Michelle

[Anonymous]

David, Michele & PLM Support

Umm, don't know if it is a related issue or not but just discovered this UI issue

You can no longer use a picklist with search feature on a grid

When you add or edit the grid the picklist with search filter field is not editable. you can't even select it.

I have attached screenshots but don't know if it communicates the issue well.

BD

[Anonymous]

Hi Bob,

This is a really nice idea. But in order for us to be able to use it we would need to be able to update the customerList.RECORDSLIST list automatically. Did you try any ways of doing this?

I was thinking that you could create a script and use it on the item create behaviour to add the new item's dmsID to the list? Or perhaps the list could contain links rather than dmsIDs. That way you could read the related attributes directly rather than having to use 'loadItem'. However, the latter point would restrict the items in the list to those from one workspace.

David.

[Anonymous]

David,

Yes we are automatically adding the dmsID to the lists as records are
created in the source workspaces. As you indicated this is being done in
the ON CREATE behavior

Currently I have a short script duplicated in each source workspace, but
I am going (when I get the time) create a library script to call from
the script used in the on behavior actions to make this easier to use.

The script basically appends the dmsID to the RECORDLIST field along
with the delimiter. The list workspace record needs to exist first and
you need the dmsID of that record to call it in the appending script.
The issue is when users delete records from the source workspaces.

You can either add a bunch of condition checks for deleted records in
any script that is doing matching or our solution is to just use a
verification script on the transitions in the list workspaces workflow
to check if a record has a status of deleted and remove it from the
RECORDLIST string.

I will go directly to the forum to post the two scripts, it appears that
when you reply to messages the body of the message get posted to the
forum but attachments are blocked as I included these in my previous
response.

Any word on the proposed fix. It current appears the FLP fields still
return null?

BD

[Anonymous]

Here are the script examples of adding and maintaining the Recordlist fields

[Anonymous]

Hi Bob,

Tanks for the images. That's really clever. I might have to steal it 

One question. Could this be modified to add a linked item to a multi-select field instead? Did you try this?

David.

[Anonymous]

BTW I think there's a fix coming on Thursday evening. Autodesk may be able to confirm.

[Anonymous]

David,

Here is that simplified script to retrieve info and store it in a multiselect pick list field

// Script to get supplier list to pass to multiselect picklist field

// Define supplier list array

var ItemVendors =[];

// Get target workspace record to check and store the vendors

var Target = item.ITEM_NUMBER;  // This field is set up as a single select picklist based on a workspace when read

                                                      // it returnd the linked items dmsID or target.

// Check if target has sourcing info

if (Target.sourcing.length > 0)

                        {

// Loop through sourcing info and store vendor target in array

                            for (var vIndex in Target.sourcing)

                                {

                                    if (ItemVendors === '')

                                        {

                                            ItemVendors[vIndex] =Target.sourcing[vIndex].supplier.descriptor.dmsID;

                                        }

                                }

// Now store that array in the current workspace multiselect picklist field

                item.QVENDORS = ItemVendors; // The QVENDORS field is a multiselect pick list on the supplier workspace

The key is to know what info (dmsid, pick list id or value) the field you are storing the info in is so you can match it.

I had word that they updated the system today, but no go, my scripts still bomb out. Hopefully like you said by Thursday

BD

[Anonymous · Accepted solution]

I am happy to report the base issue with filtered pick lists has been corrected. The functionality of reading the selections made in FPL fields has been restored.

Thank you Autodesk support for your quick response and efforts.

Regards, Bob Donovan

PS. Keep the ideas flowing, share share share....