-
Suggestion
-
Resolution: Unresolved
-
73
-
77
-
Exporting issues using Export excel CSV(Current fields) creates duplicate columns when the same custom field name is used in both Company-managed and team-managed projects.
How to Replicate
- Have a customfield in the classic project.
- Use the same name(Filter-duplication) and type. For Eg: Text Field (single line) in classic/Company-managed project and Short Text in Next-Gen/Team-managed project.
- Now create a filter to list issues for the classic project and save it.
- Select the column section and select this custom field Filter-duplication so that it is displayed in the GIN.
- Now export these issues using Export excel CSV(Current fields).
- Even though you have selected just one field, it will show up two columns for the same custom field wherein, one custom field will have the values as provided in the Company-managed project however, the other column will be blank with no values.
Video replication - https://www.screencast.com/t/RcVfrzQfU
Expected result
- Only one column for the custom field(which is present both in Company-managed and team-managed projects) should be visible when we select only that field and use export current fields
Actual result
- Rename the customfield from TMP to fix the export problem.
- Even though we select to export only the selected field, still it creates a duplicate column where one column will hold all the values and the duplicated column will be empty with no values.
- duplicates
-
MIG-1116 When "Exporting with current fields" using custom fields for a team-managed project, the column configuration is not respected.
-
- Closed
-
-
- Closed
- is related to
-
-
- Long Term Backlog
-
-
- Gathering Interest
- relates to
-
-
- Gathering Impact
-
-
- Gathering Interest
- is addressed by
-
ENT-2311 Loading...
[JRACLOUD-77919] Exporting issues creates duplicate columns when the same custom field name is used in both Company-managed and team-managed projects
It is due to the fact that the Issue Search UI intentionally combines fields with the same name across the instance in order to make the user experience more straightforward, while the Issue Export does not do this in order to make each separate field more clear if it's being used programmatically.
The workaround here would be to change the name of the other custom field to something distinctly different.
OR
Use Jira Cloud for Excel add-on or Jira Cloud for Sheets app. Both allow you to specify the exact field you are using on your project.
All comments
It is due to the fact that the Issue Search UI intentionally combines fields with the same name across the instance in order to make the user experience more straightforward, while the Issue Export does not do this in order to make each separate field more clear if it's being used programmatically.
The workaround here would be to change the name of the other custom field to something distinctly different.
OR
Use Jira Cloud for Excel add-on or Jira Cloud for Sheets app. Both allow you to specify the exact field you are using on your project.
It is due to the fact that the Issue Search UI intentionally combines fields with the same name across the instance in order to make the user experience more straightforward, while the Issue Export does not do this in order to make each separate field more clear if it's being used programmatically (for example, if it's being used to import back into Jira).
This is a bad solution to a self-inflicted problem. Don't get me wrong; it is confusing that we have seven "Story Points" fields. However, pretending that we don't in one place while not doing so in another isn't a path to clarity. These are different fields and if we can't tell which fields are the instance-wide ones and which belong to what TMP, fix that.
If you designed something with the intention of making the user experience more straightforward, and it does not make the user experience more straightforward, then it's not "working as designed".
Hello Team,
We have an enterprise customer who is not happy with the issue not being picked up for fix. The contention is that any field in one project should not have an impact on another field from a different project. The expectation is for Atlassian to fix the issue instead of customer having to delete all the incorrect columns after export.
Reference ticket - https://getsupport.atlassian.com/browse/PCS-239370
Hi Everyone,
Thanks for all of the feedback and interest in this report. We are changing this to a "Suggestion" instead of a bug because this behaviour is expected.
It is due to the fact that the Issue Search UI intentionally combines fields with the same name across the instance in order to make the user experience more straightforward, while the Issue Export does not do this in order to make each separate field more clear if it's being used programmatically (for example, if it's being used to import back into Jira).
That being said, we do understand that it is a pain point for many users, which is why we are keeping this open to allow it to gather further interest and hopefully be prioritised in the future.
Cheers,
Tyler
Good Afternoon Atlassian Team,
Ref: Exporting To Microsoft Excel Causes Duplicate Fields:
I Trust This Message Find's You All Healthly & Well.
We Are Experiencing The Same Issue(s) As The Tickets Raised Below:
In Regards To Your Two Tickets:
Please Could You Advise When This Will Be Planned Into A P.I Or A Sprint? This Is Something We Need Fixed As It Does Create More Work To Tidy The Microsoft Excel Export, Time Which We Cannot Afford.
Is There A Work Around That Would Help Us, Until You Resolve This Ticket?
I Look Forward To Hearing From You Soon.
Kind Regards,
Bas©
Hi,
I just wanted to clarify that we have multiple projects with custom fields. Each field is called the same in each project. There is no difference in the naming convention however due to the fact that it's another project the column in the export is different for each project, which makes it extremely manual to run reportings.
This occurs in our environment because we have a test and production project which have the same set of columns. Changing the name of a column in one project will break the integration.
Worth noting that a user that doesn't have access to both projects will still get duplicate custom columns in the export.
This same issue is happening with Asset Reports being exported. Duplicate columns are present in the export when the asset only has one attribute of that name.