You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Hey Jira Software & Jira Service Desk admins! I'm Alyssa from the product marketing team here at Atlassian.
My team is curious to learn how you think about archiving issues when you no longer need to reference them. For those of you who can't archive entire projects, what are the types of issues you'd like to archive and why?
As some of you know, we released our first milestone of issue archiving for Jira Software Data Center back in April as part of 8.1 (you can read more here). If you've used this feature, how's it going? Any lessons learned?
Looking forward to hearing from you!
Hi Jimmy, that’s great to know. Glad to hear read-only projects suit your needs right now. How many issues does your Jira instance currently have?
I believe we are on the smaller end of the instance scale with around only 50,000 issues.
would be great, but as it's only available on DataCenter, it's not really worth thinking about.
Sorry to be so rude, but the Altlassian product management just seems to be a little greedy. More & more features are DataCenter only. A subtle hint for the customer to change to the software rental model. I always thought, that Atlassian doesn't $%# the customer. You should be much more honest to the thousands of paying server customers and finally tell us that we should move over to DataCenter & pay twice the price.
To be a little more in detail on the topics:
We would like to archive issues after a certain amount of time especially in Service Desk projects. Archiving should be done by setting JQL filters to determine the issues to archive (eg. no unresolved issues, no open subtasks or linked issues,...)
I really don’t see too much value in this personally. What I do see value in, and wish it would come to cloud, is project archiving. While I use the common workaround (category and permissions scheme) the project can still appear in the UI.
Personally I have many clients asking for issue archiving like what @JP _AC Bielefeld Leader_ described.
We have CLOUD ver.
I agree with Mohammed/Jack, time and time again we are seeing that we want to have issue archiving. We have migrated away from Rally, and coming with that we needed to keep continuity - and therefore migrate all projects across as-is to Jira projects. what we observed was alot of project were also archived, which (as a workaround) we simply made them read-only from a permission point of view.
internal users and external users still want to have access to that data, even though they cant do anything to it. We have also had issues where somehow an issue was deleted, but there is NO Audit of this delete, and the cloud backup mechnism is far from adequate. I thought the Cloud version should be just as good as on-prem in the core functionality??
What we would like to see is:
a) a way to archive an issue, which stops any user from doing anything to it apart from make a comment, (technically is bit flag), and can be searchable in the "issues and filters".
b) the projects main UI to NOT show archived projects, but have a filter (like every other filter) for Projects (something like Project Filters).
@JP _AC Bielefeld Leader_ thanks for the feedback - we're grateful to have passionate customers who share candidly! Any chance you'd be up for a call with one of our PMs (and me too if scheduling works) to share more about your perspective? If so, let me know and we can get something set up.
@Richard Clarke @M Amine @Jack - thanks for adding your voices to this topic. There’s an open ticket here where you can give your input on what to build next: JSWCLOUD-17064 - Ability to archive projects in Jira Cloud OPEN
We are on data center and have been very excited to use the issue archiving feature. We have some long-standing issues that have a long history and as most of us know that causes some performance issue when accessing those issues. Sure we have "archived" those issues, by closing them and making them unable to edit, but that doesn't mean they were off our index. We plan on using the issue archiving feature to archive these long-running issues that we have since closed. These vary from time tracking issues like PTO, Meetings, etc. This should help with system performance overall, along with providing an actual solution for what to do with these issues that may only need to be referenced maybe during an audit.
Hi @Bryan Trummer ,
I wanted to circle back and let you know that issue archiving has been released in Jira Software 8.4 and Jira Service Desk 4.4! You can read the blog here to learn more about it including some exciting performance improvements.
We have about 500,000 issues in retired projects where we will just archive the whole project. We have a few projects with 50,000 to 200,000 issues where we will archive issues that have not been updated in the last two years.
We are on Jira Cloud, and we want to have the ability to archive whole projects. This is more important to us than archiving single issues. I can see issue archiving being more important to us as our company grows and scales.
Hi @Christina Trocco! Thanks for your reply - makes sense that being able to archive an entire project would be more valuable than archiving individual ones at this point for your company. I know project archiving isn’t currently available on Cloud - have you found any workarounds?
We’re very open to input from our customers on what to build next. There’s an open ticket here where you can add your voice: JSWCLOUD-17064 - Ability to archive projects in Jira Cloud OPEN
Hi @Alyssa Warren . I've actually been watching that issue that you mentioned. We haven't really found a workaround for archiving projects. We simply leave the projects there when they are finished. Once it gets crazy, I may just move them to its own board of finished projects. That's probably the only workaround I could think of to do. Thanks to you and Atlassian for constantly getting feedback and making improvements.
Let me just chime in and say that as far as workarounds go, there is another viable way we see teams go: it's connecting Jira with a document management system and move issues/whole projects out there. Here is a story about how an Atlassian Solution Partner built such a system for the EU Commission.
Advantages are that it takes pressure off Jira and its users by moving stuff out and also keep information searchable and indexable, since a format like PDF can contain text, files, etc.
A big disadvantage is that it involves another software tool and issues can't be restored anymore.
We do not use the data center but the archiving function may be useful in Server and Cloud too. As a business analyst and project manager of IT and non-IT projects, it seems to me that archiving should work like this:
1) It should be possible to enable/disable task archiving that has a resolution of more than a week / two / month.
2) There should be a search for archived tasks. I understand that the search will be very difficult if you do it through, so there should be a check-box or switch during the search: "search in archived tasks"
3) It should be possible to manually archive tasks (like in Trello). This should be a separate property in the permission scheme. This removes the need for a clear definition of the role that should decide what to archive and what not
It is basic, maybe I can create deeper requirements, but later, if you need this)
Hi - I hope this topic is still open. We have a huge Data Center (1500 projects, 1.7 million issues and tons of custom fields/issue types) instance as well as a few smaller Server (45,000 to 60,000 issues each with fewer projects but still lots of customer fields) instances.
Our primary goal for archiving is to not just 'set aside' but to remove entirely. This lets us do field/issue type etc. cleaning. During our last round of project deletes on the primary Data Center instances we performed our normal steps for archive/removal prep but added in the Project Archive. This improved the time of our weekly background re-index but at a cost. We can't do any scheme cleaning because we are fearful to remove what appears to be an unused field or issue type but may be in one of the Archived projects.
Quick summary of the Project archive and delete process:
This process allows us keep the number of projects and schemes limited to only those that are active. The only problem is the limitation for doing house keeping while projects are in the Archived state. We may consider not doing this step in the next cycle so as to allow for house keeping during the lock down. We have many many fields (started about 900+ and down to about 600) to remove that are very niche and used sparingly - or that are global and we need to make project contexts. All of this is quite a monster to deal with at the same time as well grow the project could for new users.
In summary I have mixed feelings about the project and issue archive options in Jira. I'd like for other items, like fields and scheme to not be 'hidden' away. I will be contacting the app vendor for Optimizer to see if they have a way of configuring an option to 'show archived' schemes. This may help our team with our dilemma.
In a simple world with generic projects and limited, well managed, fields and issue types I believe the Issue Archive option will be very helpful for performance and re-indexing times.
I think these are excellent points. I'll discuss them with our TAM this week.
1. How can I delete a custom field if I don't know whether there is data in it in archived issues?
2. How can I modify or delete a scheme if I don't know whether it is used by an archived project?
Discussed and we're drawing up a list of questions like this for the DC and doc teams. E.g. can I delete a workflow scheme that is only used by an archived project? (I would expect this to be the same as for a non-archived project)
The bigger issue is not knowing which Custom Fields or Issue types are actively used. Therefore housekeeping is impossible. I'll see if I can do some tests this week to see what happens.
We use the Optimizer App which only looks at issues in the cache, not the archived ones. I wonder if the Optimizer team could have an option to 'look at the database' vice just issue cache.
I think with archiving you now have to use SQL to check for custom field usage
Thanks for using Optimizer,
Recently we've received multiple requests for improvements in the area of archived projects and are working on improvements to archived projects support.
Optimizer V4 will perform database checks for certain custom fields fallback for when the field isn't searchable.
We're currently working on a configuration feature, one of the configurations we've got on the list of initial options is a toggle to enable Database only querying for usage, this will ensure you always get the correct issue count when archived.
We're also considering different approaches for tracking configuration item usage to ensure compatibility while at the same time maintaining correctness.
If you have any feature requests, ideas for improvements or issues the easiest way to contact us is through our service desk.
It's just one Tanya... :) I have a regular account and a Community Leader one. I appreciate all the quick feedback and efforts on Optimizer. It's a vital product to our team.
Thanks for sharing your thoughts on archiving. I wanted to share that we just released issue archiving in Jira Software Data Center 8.1 and a new browse archives page in 8.4 (Jira Service Desk 4.1 and 4.4). Here's our announcement and blog with all the details, including performance testing results showing a reduction in JQL searches, backlog loading, & re-indexing:
Hi Team, when you can support issue archive on JSD server host version? not all for DataCenter? We have a lot of issue in the instance, and 8 hrs are required for re-indexing now. BTW, any way to ignore one jira project re-indexing when we do whole indexing?