Pick List with Properties

[nborrerojr.]

I have a list of people. I would like to say which people were involved with a certain test. I also want to say what role they filled during the test. How can I have a list of people where I can also specify what their role was for the test?

[JoeBartlett]

Do the users' roles ever change from test to test? If someone is always a "systems integration tester", for example, then it would probably make the most sense to represent these users via an IBPL field. IBPLs allow you to build the visible values as a concatenation of fields from the backing items:

An IBPL identifier could look something like this:

{ID} - {UserField} - {UserRoleField}

And produce this kind of result in the IBPL drop-down:

12345 - John Smith (jsmith) - Systems Integration Tester

12346 - Jane Doe (jdoe) - Project Manager

...etc

[nborrerojr.]

User roes do change. We call our testers "Test Directors" (TD). During a test session you can have a TD of Record, TD of Training, or someone can just be part of the flight as a SME. You may have multiple TD's in a single test session. So the field could look like:

12345 John Smith

or it could look like

12345 John Smith (TD)

12346 Jane Doe (TDIT)

12347 Joe Smoe (SME)

I also have another field made up of a completely different group of people who have roles that could change. This would be listed in a different field.

[JoeBartlett]

In that case, I would probably set-up multiple fields, each as a user listing by role. For example:

Test Directors	Test Directors of Record	Test Directors of Training	SME
User1	User3	User6	User7
User2	User4		User8
	User5

There would be 4 fields on the type (one for each role) and would simply be multi-valued User fields. I have seen similar configurations before, with business logic enforcing that there had to be a user in one of the fields before a sign-off could be done or related item could only be created by a user listed in one of the fields.

[nborrerojr.]

I have considered this but I didn't want to have extra fields just to create this capability. I would assume this is multiple IBPL fields? I'm also considering just adding the user multiple times to one field with a role after their name. So you would have John Smith, John Smith (TDIT), John Smith (SME). I don't like that solution too much either. Are there any enhancements requested already for a functionality similar to what I'm looking for? I'm meeting with some PTC people in like two hours so I'm going to bounce the question off of them also.

[JoeBartlett]

I meant that those 4 fields would be simple User fields and the roles assigned to them for each test would be determined by which field their name appeared under. If you're meeting with PTC people from the Global Services Organization (GSO) then they may have a more creative solution since they have far more experience with implementing Integrity for different business needs.

[nborrerojr.]

Ah,gotcha. Another piece of the puzzle is that not all of the people that will be listed are necessarily users in the system though. I will look into doing it this way except I think it'll just have to be with IBPL instead of User fields.

[mrump]

Hi Joe,

your suggestion implies that there is some kind of "backing Item" for a user.

Does PTC Integrity support such a concept natively or is it part of a particular solution.

AFAIK the "Workflow and Documents"/Users do not allow such a concept (although I'd love to see that).

So IMHO there you need a custom Item Type "User Backing Item" that has a mandatory single value field e.g. "assigned User" and that serves as a container for all your user specific meta data.

Only this item type can then be used in a IBPL field as you suggested.

Do you know of any default setup for this kind of "User Backing Item" type; and can you share it?

It has definitely not been part of the ALM solution.

[JoeBartlett]

Hi Mattias,

Yes, my old comment was working with the assumption that there would be a custom Type created to represent users, which would then back the IBPL field. This is not an out-of-the-box function but would be a cool thing if it were.

As for examples of such item-backed users, I have seen some organizations just use a very simple configuration:
- Type is "User"
- Has a User field on it to select the user object from the realm

- Has some text field to indicate the name they want to use (eg. login ID vs full name)

More complexity can be added by putting other fields on that item. Maybe a Role pick list? Add another user field to indicate that person's manager? Allow Group fields to select teams? There are plenty of options out there once you represent a user as an item.