Best way to collect information from all issue team members with JIRA having no table inputs?

[OToole]

Hi all,  I need to collect data that looks like.

Name	Role	Time spent in preparation	Continuing Team Member
Jim Smith	Systems Eng	10	N
Jane Smith	Elec Eng	30	Y
John Smith	Safety Assessor	4	Y
Mary Smith	Software Eng	24	N

With a possibility of up to 10 members on the team.  This is collected for every issue and is needed to compute metrics

Member 1 ______________________________ (user picker)

Start typing to get a list of possible matches.

Member 1 Hours  __________

Time spent in preparation

Member 1 Continuing Team Member _______  (Yes/No Radio Button)

Continuing Team Member

Member 2 ______________________________ (user picker)

Start typing to get a list of possible matches.

Member 2 Hours  __________

Time spent in preparation

Member 2 Continuing Team Member _______  (Yes/No Radio Button)

Continuing Team Member

...  Up to 10

As you can see this gets really ugly really fast.  especially if you want to add a description to each field. Especially if you want a description or use the built ins like User picker which always give you a description.

I know Confluence has tables,  but then how do we pull it back in to include in our dashboard metrics?

There must be a better way!   

The thought of manually going in and creating 30 new custom fields,  configuring them, adding defaults, adding them to the screens,  adding required setting to get rid of None on the radio button....     And this is our sandbox server,  everything will have to be repeated, on the production server.

Thoughts,  suggestions?   And  a plugin won't work.  We have already purchased a number of plugins and management is getting tired of us telling them "you can get what you want,  you just have to buy the plugin"

[Matthias Gaiser _K15t_ · Accepted solution]

Hi @Frank Winkler

I'm Matthias from the Backbone team. I have to admit that I didn't work too much with Scriptrunner's behaviour functionality, but your script fields solution sounds good to me.

My understanding of the solution would be:

• Create a scripted field in the source instance & don't show it on a screen.
• Define a field mapping in Backbone from the scripted field to some (text) field. This target field has to be on a screen so that Backbone can write to it.

As a side remark: Backbone usually only synchronizes changes which are reported in the issue's history. We rely on that to determine which fields have actually been changed. Since a scripted field never appears in the history, we synchronize this always when some other field which is defined in the sync is getting changed, see also our docs.

Does this help? If you want to discuss your use case in private, you can also reach out to our support team via help@k15t.com.

Cheers,
Matthias.

[Frank Winkler]

Hi Matthias,

thank you very much for your answer. Unfortunately - for this matter - I am on vacation at the moment. I will come back to the office on 4.1. and will try this as soon as possible. I'll be back in touch to report on the success.

Best regards!

Frank

[Frank Winkler]

Hi Matthias,

we checked this last week. It works! So, thanks again for your help.

Best regards!

Frank