-
Suggestion
-
Resolution: Unresolved
-
140
-
263
-
Hi everyone,
Thank you for taking the time to share your feature request with us. Your input is greatly appreciated, and we understand the effort and dedication it takes to provide us with your thoughts and ideas.
We are actively working on a solution for this feature request. Our team is committed to thoroughly investigating the best way to address this need, and we will keep you informed as we get closer to a possible release date.
Thank you to every person who provided feedback on this issue. We will update you as soon as we have more concrete information to share.
Joe Nguyen
Product Manager-Jira Cloud
jnguyen2@atlassian.com
Currently the option to see the storage is on a site level, and there is no way to verify if this is caused by a single project with a large number of attachments, or one single ticket, or whether it's caused by many attachments, etc.
The suggestion is to add more detail to this report so it is possible to drill down and see a list storage consumers on each product, with Jira showing it per project, and then per issue.
This allows administrators to detect when something is using more space than normal and also from using more resources on Atlassian side.
- is duplicated by
-
- Closed
- is related to
-
- Gathering Interest
-
- Gathering Interest
-
- Gathering Interest
- mentioned in
-
Page Failed to load
-
Page Loading...
-
-
-
-
[JRACLOUD-75922] Provide more granularity to storage usage
I support the inclusion of more detail in the storage usage, as it is important being able to detect what size and type of files the accounts of Jira are uploading, and due to the amount of individual tickets it is not possible to keep track of what is there.
Thanks!
It would help to have this feature to manage projects boards more efficiently, I think it would encourage better administration on boards, and also can be used as a good indicator to decide to go for a better plan if my projects are equally balanced in storage consumed. I think it is a win win
Yes, I would like to see the details.
On Confluence, when I remove objects, or empty trashcans, I have the impression that the disk space is not given back to me.
This will be a useful feature and it would be nice to be able to manage storage.
Stop threatening that we are over the storage limit, and stop trying to get us to buy 'premium' without giving us a way to manage our storage useage. From what I can tell, you are using fear tactics and aggressive marketing schemes to try to get people to upgrade their accounts and, frankly, its disgusting.
Since there are limitations on storage in certain plans it would be nice to be able to manage it. View of attachments which you can filters such as dates, project, issue type, attachment type, etc., and be able to bulk select and delete if needed. Or download zip files.
Hi, At present a very basic information about storage is provided. It is a must to have feature for Jira admins to analyse Jira storage in details and plan cleaning actions.
We need to get this feature ASAP in the standard lisence version so that we control storage
Instead of threatening us with blood-red coloring and impending doom for not upgrading, can we get a more detailed explanation of what is consuming so much data on our sites?
We would like to have the capability. Please add it. Like another comment said, if Atlassian wants to start billing for storage used, this will be an absolute requirement for customer understanding of their spend.
Currently my understanding is you are not billing for storage but this could change in the future. If you start billing, you absolutely must have a tool like this in place before then or else you will have a lot of unhappy campers here.
It would be very helpful to find out where the attachments are located, that are taking up the most storage space, in Jira. Currently you need to use a script or 3rd party add on to be able to perform basic maintenance on Cloud.
Please update this. We seeking to get alerts on this storage limit matters. If anthing goes down because of this who will aware