With excel export, any "User" type fields would show the user's Name.
With CSV export, only the UserID shows up.
Another example is mentioned above with Time/Date fields.

It's not accurate for Atlassian to be selling the CSV export as a replacement for Excel exports. The functionality is simply not the same.

What is being done to work around or remedy this problem with CSV exports so that we can continue using them in the same way we did with Excel exports?

Also, when you export data, the time fields are in seconds, which means to have a meaningful rendering, I have to convert everything back to hours and minutes and seconds, and do this work manually every time every day.

When you look at the data in the query filter before exporting it, the time shows days, hours, minutes and seconds. Allow us to keep this format, as the query results shows it.

As far I can see, it is fixed now. The HTML export options are back. It worked for me this morning. We use Jira Cloud.

The CSV export feature broke the functionality previously available in the export to Excel-HTML. I have not been able to produce my reports since the csv is not extracting it in the format that I need based on the WebUI. Kindly reinstate the old export option (HTML); this can be an alternative to csv rather than replacing it altogether and ending up with this showstopper. Heaven forbid that I need to recreate my report templates and formulae!

Hi everyone,

CSV export for filters is now available for JIRA Cloud.

Dave Meyer
Senior Product Manager, JIRA

Hi there!

With add-on JExcel, you can export your issues to CSV!

It gives you an Excel-like interface and totally works like the issue navigator but you can* inline edit everything*!

And its completely free!

Download it from the marketplace:
https://marketplace.atlassian.com/plugins/com.moresimp.jexcel/server/overview

Hope it helps.

Cheers, Mark

Jira gives me the feeling of a very amateur tool. At least, compared to Rally, it is. Rally is more expensive but at least it provides logical features one could expect in a system like this.

I am not happy with Jira up to this point to be honest. Import/Export is basic functionality for bulk data processing.

https://support.atlassian.com/browse/JST-169278

We have released a new version (1.3) of our Exporter (https://marketplace.atlassian.com/plugins/com.deiser.jira.exporter) plugin that resolve this issue. The new CSV Export feature enables you to export all your issue data (including comments, links and custom fields) from Issue Navigator into the most commonly used exchange format. Data is organized by columns separated by semicolon character (";"). Also is 100% compatible with JIRA CSV file import wizard to ensure that you can import the .csv files into any JIRA project or instance.

We hope you like it and fit your needs. All your feedback will be very appreciated.

Cheers.

Ferenc - This issue concerns re-importing the exported file. This would allow you to update issues offline with Excel.

Better Excel Plugin avoids most of the problems mentioned in this thread, simply by exporting a real XLSX format file (not an HTML with the "xls" extension).

For instance:

• if you don't like the format of the exported data (number formats, date formates, prefixes), you can freely customize that in the export templates
• Excel opens the exported file faster (no need to data conversion, file size is more compact)
• Open Office, Libre Office, Google Docs, Apple Numbers can open the exported file (as it is a standard XLSX format file)
• you can use or omit hyperlinks with the <jt:hyperlink> tag in any cell
• you can use or omit the first header row, and possibly anything else supported by Excel (frozen top rows, frozen left columns, look, layout, etc.)
• you can use or omit footer rows (even using formulas to compute sums, averages or other aggregated metrics)

Bonus: here is a short comparison between the built-in HTML exports vs. the XLSX ones

Bonus #2: automate your Excel reports without any programming

I was shocked it wasn't there.
+1.

CSV is such a transportable output, it is the lowest common failsafe for excel,numbers,libre/openoffice. I can't do any reporting on OSX 10.9 with the current output of excel.

@Peter Maresh - That is true. I would really like to have the Excel issue fixed. I voted for all three issues.

@Michele Grimm - The nice thing about "real" xls is the use of hyperlinked text in the fields, which may not work as well in CSV, as well as simplifying the use of commas in fields (obviously). I still consider them both useful options, but "real xls" is probably a lot more powerful and easy for people working with spreadsheets.

These 3 similar issues have been open for some time. I like the CSV option (this issue, JRA-8580). Please vote and ask your colleagues to vote.

• JRA-8580 (CSV Export from the issue navigator) - New Feature, 63 votes
• JRA-27567 (Export to Excel in real xls, not in HTML) - New Feature, 18 votes
• JRA-32352 (Excel Export Is Broken With Office 2010 or 2013 / LibreOffice 4.2 / Numbers) - Bug, 10 votes

That's a must have!

Can't believe this issue is created in 2005 and there isn't any progress since.

Are there any plans to implement this feature? If yes, when? This ticket is opened for 9 years now and has no assignee yet. I was wondering why.

Any plans for implementing this feature Atlassian guys?

+1, for two reasons:

1. the XLS format used does not work with a number of XLS-compatible spreadsheets, notable the current release of Apple's Numbers
2. CSV is a lot simpler to post-process

Have users really been asking for this feature since 2006? It seems like seven years is a really long time to wait for something really simple.

This would be so helpful, particularly since the Excel export is actually HTML.

It is still a missing feature in may 2013... I really hope this will be available soon.

The CSV should be ready to use with Jira Import.

See JSP-138489

Currently the excel export is not suitable to being reimported itself because of differences.

For example, the summary of subtask are getting a prefix which is the issue key of the parent + <Space>.

So I am voting for a proper csv export.

We're also eagerly looking forward to this feature. The current work-around of exporting to Excel first and then converting to CSV is inconvenient due to the following reasons:

1. The limitation on being able to export only one thousand issues from JIRA. We need to employ the work-around of changing tempMax=1000
2. Opening this Excel file takes up to a minute
3. Then saving it to CSV takes a little longer
4. Then the CSV file has the extra header, footer, blank rows

Bugzilla had the capability to export to CSV files, so it shouldn't be hard to have this in JIRA, right?

This feature would provide the following benefits:
(1) The company could provide templates for project types with reusable stories, defects, etc.
(2) Import could occur at "project-scope" by Project Admins as opposed to via the JIRA system admin
(3) Users could export data, edit it offline (when on the train, with clients, in bulk, etc), and reimport successfully (at least at our company this is a very common scenario, especially in the case of estimation)

JIRA currently exports the data in a WYSIWYG way that does not provide the data required for re-import. For example for Assignee, JIRA exports the user's full name, but on import, expects the user's username. No mapping occurs. There are other issues with date fields. The HP Import plugin - https://plugins.atlassian.com/plugins/com.palm.jira.plugin.palm-import-export-plugin- (one of the better ones) is therefore challenged in this scenario and requires a lot of manual scrubbing of the data.

The Bulk Issue Creation plugin tries to make field mapping simpler for the user but throws exceptions in JIRA 4.4 and is unsupported for this version. https://plugins.atlassian.com/plugins/com.atlassian.jira.plugins.jira-importers-plugin

That leaves us with the temporary workaround of providing the HP Import plugin on production to Project Admins so that they can import to their projects, but with very high-touch communication and documentation on how to handle the edit/ re-import scenario. The risk for error and dissatisfaction is high, but would be even greater if we provided no such capability.

A stable CSV Export capability would be really great in helping us to provide the value defined above.

Btw - I released the CSV View plugin at the end of last year, and v0.3 today:

http://confluence.atlassian.com/display/JIRAEXT/CSV+View

Steve,

Due to a a large number of other popular feature requests were are not currently planning to implement this feature.

OpenOffice should be able to open JIRA's Excel export file. If you are having trouble with this please create a support request in our support system:
http://support.atlassian.com

Cheers,
Anton

Hi,

I see this issue is over two years old now - is there likely to be any update on this at all?
As an open source company we try to use open source products like Openoffice and NeoOffice, neither of which handle the Excel export of Jira.
Thanks!
Steve

I've started work on a plugin for this:

http://outlet.googlecode.com/svn/trunk/jira-csv-view/

My current problem is figuring out how to turn the layout keyword of something like 'issuekey', into an issue.getIssue() or an issue.getString("key").

Hello,

I just found out that in jira 3.8 (don't know about 3.7, I upgraded from 3.6.2 directly to 3.8.1)
you have separate header and footer vm files containing the blocks above. The files are:

$JIRA_HOME/atlassian-jira/WEB-INF/classes/templates/plugins/searchrequestviews/searchrequest-excel-footer.vm

$JIRA_HOME/atlassian-jira/WEB-INF/classes/templates/plugins/searchrequestviews/searchrequest-excel-header.vm

Cheers

Bettina

Hello Neal,

it works! Thank you!
For the formats I also decided to use Excel format options.
I have a template .xlt file with my desired formats on a column name row, I then copy all the selected rows into it,
mark the column name row and copy the formats of all columns at once by sweeping the brush on the row's ruler.

Cheers
Bettina

Bettina - I'm still running 3.3.3 so I haven't investigated whether the changes to 3.4 and higher would be exactly the same, but it looks like it would be. The line numbers will be different
Here are my customizations:
In the file ... /secure/views/navigator/navigator-excel-current.jsp
Removed lines 50-69 (1 table tag, 3 tr tags) (lines 77-96 in 3.6)
and lines 99-105 (1 table tag) (lines 126-132 in 3.6)
Here's the first block to delete:

<table border="1">
<tr>
    <td bgcolor="<%= topBgColour %>" colspan="<%=colCount%>" height=30>
        <img src="<%= jiraLogo %>" width="<%= jiraLogoWidth %>" height="<%= jiraLogoHeight %>" border=0 alt="<%= AP.getDefaultBackedString(APKeys.JIRA_TITLE) %>">
    </td>
</tr>
<tr>
    <td bgcolor=ffffff colspan="<%=colCount%>">
        <a href="<webwork:property value="applicationProperties/string('jira.baseurl')" />"><font color=ffffff><webwork:property value="applicationProperties/string('jira.title')" /></font></a>
    </td>
</tr>
<tr>
    <td bgcolor=ffffff colspan="<%=colCount%>">
        <webwork:text name="'navigator.excel.results.displayissues'">
            <webwork:param name="'value0'"><b><webwork:property value="/searchResultList/size" /></b></webwork:param>
            <webwork:param name="'value1'"><b><webwork:property value="/outlookDate/formatDMYHMS(/outlookDate/now)"/></b></webwork:param>
        </webwork:text><br>
    </td>
</tr>
</table>

Here's the second block to delete:

<table border="1" >
<tr>
    <td bgcolor=dddddd colspan="<%=colCount%>"><font size=1>
        Generated at <%= new Date () %> <webwork:if test="remoteUser != null">by <webwork:property value="remoteUser/fullName" /></webwork:if> using JIRA <%= BuildUtils.getCurrentBuildNumber() %>.
    </font></td>
</tr>
</table>

I'm not sure what you're after with regards to date/time formats, but I just use Excel's format cells option to convert the date fields to the format I want (i.e. highlight a column and change the cell format for the column).

From my recollection, you don't need to restart JIRA for these changes to take effect (at least in my environment in standalone testing). Depending on your live environment, you might need to.

By the way, does anyone actually like that stuff in an Excel file?

I've also got customizations (in JIRA) to not export the "Tools" column from the Toolkit, and a macro (in Excel) to remove issue hyperlinks. Let me know if you want those too.

Hello Neal,

I need either a clean csv export of my jira issues, or else
a customised excel which does exactly what your excel does:

1. not generate header and footer
2. not create the image

And additionally but most importantly:

3. not change the date-time and number formats!

I'm somewhat struggling with excel (2000) though.
How do I customize my excel so it is like yours?
I think if you give me some advice for 1. and 2. I then will
find a way to get also 3., but for now I'm quite clueless.

Cheers

Bettina Zucker

Hi,

Neal does have some good points, but I can see for a few ocassions that an csv view would be better.
Unforetunately, we have not yet scheduled this issue.

I think our future goal for the Issue Navigator Views is to pluginfy it so that users can create their own views.

Cheers,
Nick

That (the extra rows) was a bug in the latest Excel export which was fixed for 3.4.3 in issue JRA-8922. There's a patch (or 3) on that issue you could try. You can watch your user wince from all the effort made in fixing it as you install the patch . And I've also customized my Excel to not generate those header and footer rows which span cells, not create the image at the beginning. I don't know who likes that I also have a macro to remove hyperlinks from the generated Excel output. I was thinking that if you created a filter with just the fields you want for import, it should work. What am I missing?

I don't know about others, but we've periodically seen some issues with
the Excel Export. As an example, just recently since upgrading to 3.4.2
one of our heaviest users has indicated that the Excel Export is
producing more rows than needed, wasting the upload process. So he had
to write something to strip out the blank rows. Seems like a CSV export
would eliminate all of that headache, and probably would be less
error-prone in general. I mean, it seems like a much simpler
protocol/mechanism to me, but what do I know.

Just out of curiosity, why couldn't you Export to Excel and then save from Excel as a CSV file, and then import? I was thinking of doing that if I wanted to merge data from a test system to live.

Any status on this?