cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Query items in a workspace based on FieldID values

Query items in a workspace based on FieldID values

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. 

5 Comments
jared.sund
Alumni

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?

ForrestJudd
Advocate

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.

jared.sund
Alumni

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.

jared.sund
Alumni
Status changed to: Future Consideration
 
aaron.tw
Alumni
Status changed to: Archived
 

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea  

Autodesk Design & Make Report