Skip to main content
1-Visitor
February 10, 2015
Question

Pick List with Properties

  • February 10, 2015
  • 1 reply
  • 3347 views

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?

    1 reply

    21-Topaz I
    February 11, 2015

    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

    1-Visitor
    February 11, 2015

    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.

    21-Topaz I
    February 11, 2015

    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
    User1User3User6User7
    User2User4
    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.