PLM 360 IdeaStation
Share your wish list directly with the Autodesk PLM 360 Development Team
2 Kudos
ForrestJudd

Query items in a workspace based on FieldID values

Status: Comments Requested
by Active Contributor ForrestJudd on ‎10-30-2012 12:12 PM

I'd like to see the ability to query for records from a script.  An immediate need and example of this would be determining the exact record(s) specified by a set of filtered picklists.  The picklists themselves contain only information about the record(s) in the workspace they're tied to.  Since there's no guarantee that enough picklists are provided by the configuration to identify a single record in that workspace, in general you can't use this functionality to pick a single record.

 

However, if I want *all* the records that meet the filtered picklist criteria, or if I've designed the set of picklists such that picking a value from each one will identify a unique record, I'd like to know what record(s) the user has selected.  I can currently do this with some pretty clunky (and limited) workarounds as described in this forum post:

 

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

 

Fundamentally I"m using the brute force approach of checking every record to see if it matches my criteria.  To improve performance (and get around the script run time limit) I have to maintain a list of all valid objects on another record in a special workspace.  This lets me reduce the number of records I check against.  Eventually, though, as the number of records to check against grows, the script run time limit could be hit and the functionality will break.

 

All that trouble could be replaced with the simple ability to query records of a given workspace based on FieldID values.

 

In the simplest implementation I could see it working something like this:

 

var matchingItems = queryItems([WORKSPACE], [NAMEVALUEMAP]);

 

[WORKSPACE] = the name of the workspace to query

[NAMEVALUEMAP] = a map of FieldIDs and specific values

 

queryItems() would return an array of matching items, or null for no matches.

 

This would be great for extending the functionality of filtered picklists, and it has a lot of other general uses as well. 

Comments
by Employee on ‎10-30-2012 02:04 PM

ForrestJudd, thanks for the great post!  I like this idea, however I'm curious about your filtered pick list example.  Is there something missing in the standard filtered pick list functionality that would require this sort of scripting?

by Active Contributor ForrestJudd ‎10-30-2012 02:28 PM - edited ‎10-30-2012 02:31 PM

Jared, Thanks for the response.

 

The specific workflow we want is this:

 

1. User picks a customer

2. Based on customer, user picks a location

3. Based on customer and location, user picks a contact at that location

 

Those three choices define a record that contains the following:

 

- Shipping Address (multiple lines)

- Contact email

- Contact phone

- Special shipping instructions

- etc

 

I want to use a script to pull all of the above information off of the record the user has identified by picking from the three lists. Basically we want to validate user input.

 

If I used a single picklist of just contacts, that could get me the record that defines all of the above information But in cases where maybe a contact is not known (because maybe there's just one shipping contact at that address), and the user only has customer and location information, they might have to go back to the workspace itself and do a search to find that contact. The user will *always* know the customer and location information, though.

 

I think this would also be useful for information validation in general. For example, if I want to make sure that customer contact information doesn't get duplicated, I could run a query upon new record creation or item details edit to make sure there's not already an existing record with the same name, email address, phone number, etc.

 

Unless I'm missing something, right now with scripts I have to know exactly what record I want to deal with. I can only know what that record is by either accessing a non-filtered picklist or acting on the item whose behavior (create, edit, or workflow transition) triggered the script. In most cases I've encountered so far that's good enough and workable, but filtered picklists don't provide for the capability.

by Employee on ‎10-30-2012 06:24 PM

I see your point.  What might be slick here is the ability to tie the derived field source (pivot) to a filtered picklist.  I'll add a feature request for that, and search from scripting.

by Employee on ‎10-30-2012 06:24 PM
Status changed to: Comments Requested
 
You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Announcements
IdeaStation Guidelines
Review guidelines and best practices
before posting a new idea


PLM 360 Survey