Sometimes an issue isn't resolved in the moment of the pressure of the "Resolve Issue" button, but it could be a user resolves an issue in the day T and he presses the "Resolve Issue" button after 2 days. The Resolution Date showed is T+2, but I'd like to register T.
Is there a way to obtain T or must I create a custom field?
In JIRA Cloud it is possible to update the resolution date by doing a CSV import.
Just export a CSV of the issues you need to update. Add a "resolved date" column, populate dates, then import into JIRA as Admin via External System Import.
Make sure to set the date formatting to match in CSV and import tool. Also include the issue-ID and summary in tour CSV. If the issues are also missing a "resolution" you will also need to update the "resolution" in the same import, otherwise the "resolved date" will not change.
It looks like it is Issue Key (as opposed to Issue ID), that needs to be used to map. When you do so in the wizard a message appears at the top saying "You have selected Issue Key mapping. Please note that importer will update existing issues matching the Issue Key from the CSV file."
The problem is: it does not work for "Date Resolved" for me...
@Francois Toubol CSV file shuld contain four columns: they are Issue Key, Summary, Resolution and Date Resolved.
You should map Issue Key, must map Summary, and then choice the Resolution and the Date Resolved opposite other fields. Also you should type correct Date format on the previous step.
It is also possible to use export/import in self-hosted instances:
I'm trying to add issues via import button, I just want to change the resolution time of the ticket (resolved) and nothing else, the page map issue key I don't think I can understand, do you have steps that I just have to change the fixed date that it doesn't change for me the fixed date that creates a couple of tickets in the same project.
1) Yes, i have all the four columns in my CSV.
2) On the map fields i also have these four CSV fields listed, but i think i am not understanding here what is the Jira field please see the image attached. For example for the issue key i have to select which field? for the resolution date which field? i have tested once and it created a new 5 tickets on the same project rather than changing the old ticket resolution time. May be i am doing something wrong.
You need to select the same field - so in the first drop down, find "Issue key", in the second, find "Resolution" etc.
The reason it creates new tickets is because the Issue Key is not mapped - the import does not know that the lines in your CSV correspond to existing tickets and which ones.
Thanks for the screenshot @Muhammad Bilal !
So, the problem here is that you are importing issues from CSV from the search page, as explained in: Creating issues using the CSV importer
- From the Jira Cloud application header, click Issues > Search for issues.
- Click more ( ••• ) > Import issues from CSV.
While you should use the CSV import from External System Import in the administration section of your Jira instance as documented in: Importing data from CSV
- Choose the Jira icon (, , , or ) > Jira settings > System.
- In the Import and Export section, click External System Import and then click CSV.
The first functionality can be used to bulk create issues from CSV into an existing project also by non-admin users that have create issue permission in the destination project and it is therefore limited compared to the other one.
I hope this explains.
Hi @Dario B
Thank you so much, i have successfully used the CSV import and it shows me the exact map fields. I am still having error while changing the date. Please confirm if the date format is correct. in my import file i am using like this: 16-12-2019 11:20:00 AM
2020-01-17 07:43:46,605 INFO - Import started by muhammad.bilal using com.atlassian.jira.plugins.importer.imports.csv.CsvDataBean 2020-01-17 07:43:46,750 WARN - Unable to parse datetime: 16-12-19 11:20
Hello @Dario B, I'm almost there. However, The issues are not created nor updated:
2021-01-27 19:06:58,514 INFO - ------------------------------ 2021-01-27 19:06:58,514 INFO - Importing: Issues 2021-01-27 19:06:58,514 INFO - ------------------------------ 2021-01-27 19:06:58,514 INFO - Only new items will be imported 2021-01-27 19:06:58,631 INFO - Importing issue: [externalId='autoid-3702845111255600032', summary='XXXX'] 2021-01-27 19:06:58,713 INFO - 0 out of 1 issues successfully created 2021-01-27 19:06:58,717 INFO - ------------------------------ 2021-01-27 19:06:58,717 INFO - Finished Importing : Issues 2021-01-27 19:06:58,717 INFO - ------------------------------
Do you know what might be happening?
This is what I have in my csv file:
For the rest I am exactly following your instructions.
Hello @hugo_campbell ,
Can you confirm you are using External System Import and provide a screenshot of how you configured the time format?
Also, can you confirm the resolution date has not been actually modified, since I don't see any error in the logs, it just says it did not create any issue (but it does not say it did not modify the given issue)?
Surprisingly, this is a real issue. We decided to do something about it and released a resolution checker as part of our free addon (Quantify).
1. You can use JQL-powered search to lookup issues
2. Because we deal with things like time in status, throughput and other Kanban metrics we already know what resolution dates to suggest
3. Then selected items are available in the correct CSV format to use in the "External system import --> CSV"
If you were running the self-hosted version, and you had reliable backups, and you took the service offline first, you could edit the SQL in the underlying database, in which case it's the jiraissue.RESOLUTIONDATE field, but for OnDemand you're probably on your own.
@Dario B appreciate the reply, but having to modify the DB each time you want to change a date is very unproductive. We also would need to ask the Jira Administrator to do this as a lot of us don't have access to this. I just want the resolution date to be editable just like due date. This is not a question of how to do this, as it's clear it's not possible to do it easily, but rather a feature request.
I would say this is by design.
Enabling editing the date at whim (even by admin) just encourages users to change data later as opposed to implementing both technical (correct workflow) and procedural (set your damn task to done when you actually do it) ways to have the data correct.
If you are an admin, make sure the "check the resolutions are set right" is in your definition of done when creating/editing workflows.
I am not not saying I have never done the mistake - that's why I am here :D But I would not be happy if me and other admins could just edit any issue's resolved date anytime easily.
It is possible to use export/import in self-hosted instances as well:
Hi @Chris ,
Please notice you added a reply to a thread from 2012 and this is usually not advised.
I am not sure whether you are using Jira Cloud or Server, however, the way to export to CSV is showed in below screenshot:
I hope this helps. If not, please create a new thread for your issue.
This issue happened with me in a critical project when i had bulk changed the Resolution using script runner built-in functionality. The solution is for Jira DC and PostgreSQL. Please try the same on Lower environment before doing it Live. It works.
The steps are:
\copy id, resolutiondate FROM jiraissue WHERE project = "PROJECT_ID" AND resolutiondate IS NOT NULL) to '/tmp/output-dev.csv' with csv;
\copy id, resolutiondate FROM jiraissue WHERE project = "PROJECT_ID" AND resolutiondate IS NOT NULL) to '/tmp/prod-backup.csv' with csv;
CREATE TABLE tmp_issues (id numeric(18,0), resolutiondate timestamptz);
\copy tmp_issues(id, resolutiondate) FROM '/path/to/output-dev.csv' DELIMITER ',' CSV HEADER;
SELECT * FROM tmp_issues limit 50; <two columns with id and resolutiondate> \d tmp_issues Table "public.tmp_issues" Column | Type | Modifiers ----------------+--------------------------+----------- id | numeric(18,0) | resolutiondate | timestamp with time zone |
UPDATE jiraissue SET resolutiondate = tmp_issues.resolutiondate FROM tmp_issues WHERE jiraissue.id = tmp_issues.id;
DROP TABLE tmp_issues;
There is a way to do it in Jira Server. I know because I just did it, and it took a long time to figure out a viable solution. It is a little tedious, but you don't have to touch the backend database.
1) Create a new custom field as a placeholder for the resolution date. We used a Date Time Picker field.
2) In your CSV file, include a column with the resolution date for each issue you are updating. I set the format to "yyyy-MM-dd HH:mm:ss" (using the custom format function in Excel). I have found Jira to be very sensitive with the date format when doing CSV imports.
3) Via the External System Import function, import the CSV file. Be sure to set the date format to "yyyy-MM-dd HH:mm:ss". I match the Key and Summary, and match the Resolution Date in your CSV file to the new custom field you created in Step 1. Check the "Map Field Value" for the Resolution Date field.
4) Confirm the CSV import worked and your new field is populated
5) In your work flow, create a new recursive transition. Since these are all resolved issues, it should be from "Done" to "Done" or something along those lines.
6) On the new transition, add a post function where you copy the value from your new custom field created in Step 1 to the "Resolved" field. (Resolved is the system field that captures the data of resolution). We used the JSU add-on, and the post function "Copy Value From Other Field (JSU).
7) Do a bulk update, selecting all the issues you want to update the Resolved date. Execute the new transition you created in Step 6.
If you have any questions, feel free to reach out. This was a huge pain to figure out, but the solution is relatively simple (assuming you get the date format correct :) )
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events