Archiving classic projects by moving issue to a read only project.

[Aaron Geister]

We have add a 2nd read only helpdesk project. I have been moving issues to that project but have not found one great solution. 

Automation for jira is amazing because you can schedule it but then it will not clone the attachments and it sometimes misses the reporter and assignee of the original issue. 

DeepClone was nice cause you can bulk so much but doesn't give the assignee and report of the original issues. 

Clone Plus works amazing and all things clone over but doesn't so far provide away to schedule the clone or bulk clone issues. 

What have others come up with or how do you handle this. I am thinking Project Automations needs to add the ability of the attachments. 

[Dirk Ronsmans]

Hi @Aaron Geister ,

I'm wondering in the first place why you would archive them by moving the issues to another project?

If they are Closed (or in a different state that you define as closed) there are other ways to make the issues read-only.

You could simply block the edit permission on that state by user a workflow property.

is there a specific reason to move them to that other project or could you elaborate a bit on your use-case? That might help in perhaps suggestion alternatives.

Also project automation is still developing so i'm sure that will become a feature in the future :)

[Deleted user]

Hi @Aaron Geister ,

We are the Bobswift Support team, we have created a support request in or portal to discuss more on Clone Plus for Jira app and your requirement.

We request you please sign up for our portal using this link and try to access the support request https://bobswift.atlassian.net/servicedesk/customer/portal/1/SUPPORT-4359 to discuss more on this issue.

Thanks,
Sravya

[Deleted user]

Hi @Aaron Geister ,

Using Clone Plus for Jira app, you can clone the issue to different projects where you will be also able to customize the fields you want a clone. However, Bulk cloning of issues and scheduler doesn't currently support Clone Plus for Jira app. We also have an improvement request https://bobswift.atlassian.net/browse/JCPP-1249 for the same. We request you to vote and watch the request for further updates on this request.

We do have a Jira Command Line Interface (CLI) app, which helps you to clone all the issues in bulk with all the field values like reporter, assignee, attachments. Please check the CLI will work https://bobswift.atlassian.net/wiki/spaces/JCLI/pages/91881490/User+s+Guide.

The above command will clone the issues based on the given JQL results to the project ZJIRACLICLONEX. Refer to the page for more parameters like copyAttachemts. Also, please make sure that users have all the required permission to clone the issues to other projects like create permission and browse project permissions.

--action cloneIssues --project "ZJIRACLICLONEX" --type "improvement" --copyAttachments --copySubtasks --jql "project = ZJIRACLICLONE and issuetype = bug "

To execute the CLI commands based on the scheduler, we need to write the scripting for the same, which will execute the commands from a file at a scheduled time.

Hope this information is helpful. Please comment on the support request https://bobswift.atlassian.net/servicedesk/customer/portal/1/SUPPORT-4359 for further discussion.

Thanks,
Sravya

[Aaron Geister]

@Dirk Ronsmans Currently there is no way to archive issues or projects in classic service desk cloud version. So I have build a read only project to move issues to be read only to help clean up our current support desk and keep old issue out of the project. This is the reason for what I have set up. If there was a built in way to archive I would be doing so. I hope this helps you better understand why I have done this. My understanding is that the next-gen is going to have the ability to archive issues and projects built in with premium service plan. Until we are able to move to a next-gen project we will continue to try and archive old issues this way to keep the project cleaned up. 

[Dirk Ronsmans]

Sure, but what do you with the issues afterwards?

Do you keep them to consult them or if it is to clean up the current project do you just move them and never look at them again? If so, why not just delete the issues?

If they still need to be available but in a read-only fashion you can just set it up so that the issue remains in your main project but with read-only (by setting a property on the status).

Also just adjusting your queue's to have filters that only show items still in an "open" state and older than x months could already do the trick and save you all the hassle of moving them.

I feel a bit like you are creating an issue where there shouldn't be one to start :)

I'm not fully

If you want them to be available but to a subsection of users perhaps a security level is the way to go? 

When i look at how Atlassian thinks about archiving:

What happens to an issue after you archive it?

Here's a few things you should know about:

Issues

• Issues will be read-only and accessible only with a direct link, mentions in other issues or applications, or on the Archived issues page (Issues > Archived issues). You won't be able to modify them but for audit purposes you can view or, if you're a Jira system admin, export them to a CSV file. To export archived issues with all their data, go to Issues > Archived issues, open the Export drop-down and click to export all issues or only the selected ones.
• Issues will no longer appear in the list of issues in projects, search results, JQL auto-complete, dashboards, or reports.
• In Jira Software, archived issues will also disappear from the Scrum and Kanban boards and backlogs.
• In Jira Service Desk, archived issues will also disappear from the customer portal, queues, and all other places they previously appeared.
• Archived issues are deleted from Jira index and because of that Custom Filed Optimizer does not have the full set of information about the issues which use a particular custom field. This can result in some unwanted behaviour such as custom fields not displaying for archived issues and for the issues that have been restored. For more information, see Jira Knowledge Base.

Index

• Issue data will be ignored and removed from the index. This enhances Jira performance because Jira stores less data.

Then I think you even "fake" this functionality just by adjusting your filters.  By default they are archived when they move to a done state + 14days. So even if you just add this to your filter (or even add a new State "Archived" after your Closed state)

While moving things to another project works, I feel that will cause more issues down the road.. you lose the links you have between issues, your Key is different, you have to manage multiple projects..

Imho, just add a new state to your workflow and "Archive" them after the time you want with an automation. And just adjust your filters/queue's to exclude the Archive status.

If you want to remove them from the customer portal you can even remove the request type and they won't see it anymore.

But of course it all depends on how you like to work in your environment :)

[Marlene Kegel - codefortynine]

Hi @Aaron Geister ,

Thank you for evaluating our app Deep Clone for Jira.

I have some some questions regarding your feedback.

• It is possible to clone (or bulk edit) the assignee. Are you looking for a different feature regarding the assignee?
• Can you elaborate a bit more on the report you need when cloning? We link the "cloned issues" as a list. Would you need the same feature for the original issues or something else? 

Thank you!

Marlene

[Aaron Geister]

I think I got it figured out it was actually my mistake. It does carry over the original assignee and reporter as long as you have it set up and it is a editable field in the other project. 

[Marlene Kegel - codefortynine]

Thank you for letting me know, @Aaron Geister . It's very important for us to know, that your use case is possible. 

We're still working on updates and are very thankful for your feedback. 

Don't hesitate contact our support, if there's anything else what's missing for your use case. We are always eager to improve our apps.