Capturing 2 values for the same set of fields by different users

[Yatish Madhav]

Hi all

I am curious to know how the community would or have handled this scenario.

We have a set of fields that are populated in a screen. Up until now, it was mainly developers setting these fields. We now have a requirement to have the developers set it and then have QA users set their values on those same fields.

How best can this be achieved still keeping the information captured report-able?

My current best thought is to have duplicate fields (OUCH I know) but 2nd best, which would include development, that I am considering of using REST API to pull the work item history and who set the value.

Looking forward to your responses.

Thanks
Yatish

[Marc -Devoteam-]

Hi @Yatish Madhav 

Yes API is an option; /rest/api/3/issue/{issueIdOrKey}?expand=changelog

Or have indeed separate fields, don't use duplicate names, but refined them so it's clear what field is for Dev and what field for QA.

You could also look to have QA do this on a specific transition, that only they can trigger.

[Yatish Madhav]

Thanks @Marc -Devoteam- 

Yea, I have considered the workflow, but we were trying to minimize the changes to the workflow and I agree on naming the fields based on who is populating it (if we go that route)

Also, thanks, i forgot that you can use expand=changelog on the get issue endpoint

Thanks again

[Marc -Devoteam-]

Hi @Yatish Madhav 

Please accept my answer as a solution, if my answer helped to solve or provide a workaround to your request.

This will help other community member trying to solve the same or provide them with a work around

P.S. If the answer is very valuable to you, please share some kudos.

[Stephen_Lugton]

HI @Yatish Madhav ,

I haven't thought this all the way through, so it's just an idea to explore.

• Create a sub-task type that includes the fields you want to capture
• Create automation that triggers when any of those fields changes on your work item
  • Create a sub-task if no existing sub-task of that work item 'created' by current user exists with the field values from the work item
  • Update a sub-task if one was already created by current user with the field values from the work item
• For your reporting use the sub-tasks

This won't change your workflow; it just needs a new sub-task type created (or add those fields to existing sub-tasks) and automation to copy fields from the parent work item to the sub-task.

Alternatively, you could use automation that triggers on a status transition to create the sub-task from the current field values (which will have been updated in your screen).  I know you're trying to minimise workflow changes, but you could modify the workflow to show that screen at the appropriate places.

You could even just miss out the automation and get your users to create a sub-task and fill in the fields there, that way you could track the reporter.

[Dave Mathijs]

Hi @Yatish Madhav

First, start with "Why?". Why would different users need different options for the same field as the field options are associated with the work item?

You can create a different context (configuration scheme) for a custom field, but this only relates to the space and the work type, not to the space role.

You cannot create 2 different contexts (options) within the same space for the same work type.

[Yatish Madhav]

Thank you @Dave Mathijs - We are looking at the why. We used it to capture details on a ticket as part of the Developers' experience on a specific category as they completed the ticket ... But we now require the same answers by QA users (potentially others if other use cases do come up)

I did think of context but by that fact, it wasn't an option. It would be great though if field context allows for role/group/user huh?

Also considering comments as that does allow anyone to add their answers in a recorded comment, but this makes it slightly less reportable