Tell me more about doing a GENERIC field ”handshake” mapping
Question ID: 109098
0
0

I see in this post about an ID handshake

https://eyeontesting.com/questions/18536/we-are-using-connectall-and-want-to-know-which-rec.html

it mentions doing it for other fields, can I get some examples?

Marked as spam
Posted by (Questions: 99, Answers: 7)
Asked on July 29, 2019 4:03 pm
34 views
Answers (1)
0
Private answer

Generic field ''handshake'':

Sometimes customers have issues with trying to map difficult data types or they have very long and changing single or multi-select lists that don't work well for a value map. Sometimes a field like Severity or Priority just cannot be value-mapped since the list on one side is much longer than on the other.

Another issue happens when either of the USER lists in the endpoints (QC and JIRA for example) are different (either different people or different userID patterns, like LDAP in one tool and not in other).

The ''Handshake'' method can work for these cases.

To do this, you must create a custom STRING field in each tool to hold the ''trouble'' field's value from the ''other'' tool (e.g. ''Value-from-long-JIRA-select-list'', ''JIRA-Priority'', and ''QC-Severity'' fields here). Map them one-way as shown to copy the entire comment contents to the ''other'' tool's field (most customers make the comment copy fields read only for users other than the QC-Sync user of the project). When Sync creates a corresponding record for a ''new'' record seen on sync (i.e. new Defect in QC, causes sync to create a corresponding record in JIRA), it then copies the STRING value from the source field over as part of the new record. If the source field's value is MODIFIED (i.e. changing severity in QC or priority in JIRA), it re-copies the value as part of the sync.

When you use a ''handshake'' like this you now have 2 one-way maps (single-select field to string) so, you CANNOT have any direct changes of values like you could do with a simple value-mapped select-list. with a simple list bi-directional map, users in either tool can change the value BUT, here with such unwieldy or dynamic lists, maintaining the value-maps is not possible, so you need to forgo the concept of having a ''bi-directional'' field map. In this case, the string value ''suggests'' the change to the other field or just reports the value for users of other tool to see.

*Example 1* (long single-select list):

Severity (QC) > QC-Severity (JIRA)

JIRA-Priority (QC) < Priority (JIRA) Value-from-long-JIRA-select-list (QC) < My_Long-single-select-list (JIRA) *Example 2* (mis-matched USER lists): Created By (QC) > QC-CreatedBy (JIRA)

JIRA-Reporter (QC) < Reporter (JIRA)

Marked as spam
Posted by (Questions: 4, Answers: 509)
Answered on July 29, 2019 4:47 pm
EyeOnTesting

Welcome back to "EyeOnTesting" brought to you by Orasi Software, Inc.

X
Scroll to Top