So, if you had multiple 'sprint' fields, they would be surfaced separately (instead of coalesced) as their own columns in the daily issue field history model. These columns could then be combined by the user outside of the package. Perhaps we can make each column by unique be concatenating the field name with the unique field id (so sprint_10020, sprint_10029)
This is more ideal than the jira_field_grain variable solution because what if the two distinct-but-identical fields have concurrently active field values? Which do you choose? Do you aggregate? etc etc Lots of considerations that are unnecessary if we just keep these actually-distinct fields distinct
Describe alternatives you've considered
keeping the jira_field_grain variable
aggregating potentially totally-different field values together
Are you interested in contributing this feature?
[X] Yes.
[ ] Yes, but I will need assistance and will schedule time during your office hours for guidance.
Is there an existing feature request for this?
Describe the Feature
Address something like https://github.com/fivetran/dbt_jira/issues/90 by splitting fields with identical names.
So, if you had multiple 'sprint' fields, they would be surfaced separately (instead of coalesced) as their own columns in the daily issue field history model. These columns could then be combined by the user outside of the package. Perhaps we can make each column by unique be concatenating the field name with the unique field id (so
sprint_10020,sprint_10029)This is more ideal than the
jira_field_grainvariable solution because what if the two distinct-but-identical fields have concurrently active field values? Which do you choose? Do you aggregate? etc etc Lots of considerations that are unnecessary if we just keep these actually-distinct fields distinctDescribe alternatives you've considered
keeping the jira_field_grain variable
aggregating potentially totally-different field values together
Are you interested in contributing this feature?
Anything else?
No response