Insight into Dynamic Lists and Object Lists

Agile has had object lists for a while. What are object lists? These are out-of-the-box lists (any list with a description starting with 'ALL') that points to objects in the system - Changes, Customers, Declarations, Discussions, Items, Programs,.. you get the idea!

These lists are called object lists for a reason, they only yield object numbers as results or list entries. Object lists are non-customizable and they just work magically!

Customers have always asked us to provide something to help them customize the out-of-the-box object lists. For instance, look at scenario where you want to have a user list on Items where the users are Product Managers. Prior to 9.3.1 release you will have to maintain a list by manually adding and removing entries.

What did we do to solve the problem? Read More..

In Agile PLM 9.3.1 release,  a new capability to allow administrators to create lists that mimic the behavior of object lists has been introduced.

How is this done?

We added a criteria association to our existing object lists and called it 'Dynamic' lists. When creating or editing a list, a criteria can be associated with it to yield only objects that match the criteria as list entries. Again, like object lists, these new lists will only yield object numbers as list entries.

How do we differentiate between these new lists and other lists that have manually entered list entries?

We created 'Type' for lists. In 9.3.1, there are three types of lists - Simple, Cascade and Dynamic. While simple and cascade lists are maintained manually by editing the list entries, dynamic lists rely on criteria for generating list entries. We allow sorting of lists in Java Client based on Type (a new column on lists window).

While reusing a criteria that is already available in the system might look like a good idea, it is advisable to use new or dedicated criteria for lists. Once a criteria is associated with a list and put to production, it is dangerous (might result in data loss!) to edit or change the criteria. So, sharing a criteria between, say a workflow and a list - not a good idea!

'The best practice here would be to use naming convention to distinguish a criteria that is being created for lists from a criteria created for any other objects.'

A dynamic list as said earlier needs a criteria to be associated with it. So before we create the list, a criteria has to be created, which can be later selected during the list creation process. New criteria creation is not available from within a list creation window.

To create a dynamic list you would open lists node in Java Client - Admin Tab and click the new button. Key in the name, description and be sure to generate an APIName. Select the list to be enabled and the most important part, select the type of the list to be dynamic. The criteria property will become available when you change the type to dynamic. Select the criteria that need to be associated with lists and click OK, the list will get created. You would immediately notice the list tab is loaded with entries that match the associated criteria.

Now that you understand how to create a dynamic list, let us take a trip back to the scenario I talked earlier - a list with users who are Product Managers. You can create a criteria based on a category field on General Info Tab of User or any other field that can indicate a user is a Product Manager. Create a new list and use the criteria and you should have a list with users who are Product Managers!

A few things to note:

• As before, type of a list cannot be changed once created.
• If a criteria associated to a list or another object is being modified, the system will warn with a popup confirmation. If the criteria is saved ignoring the warning, the list entries that are on the list will also change accordingly.
• As list entries in a dynamic list are objects in the system, web client renders the entries as links when the business object is saved. Quick View is available for the same.
• Changing a criteria associated with a list that is in use, will not lead to immediate data loss.

Existing data is preserved as long as the attribute is not modified again.

Editing the object for modifying another attribute will erase the list selection.

The data in the attribute is preserved (though not visible on UI) till it is over written with something else. So if you were to revert the criteria back to what it was, the attribute data will show up automatically (we retain the attribute data in the database till it is overwritten).

• Result set record limit applicable to searches are applicable to dynamic lists as well. A popup search in web client on the list will yield first 250 entries.