The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Hello Community Members,
Thank you for all your comments and feedback. It's great to see so many questions being asked and upvoted. We will be posting the answers over the course of the day today. There is a lot to cover, but we will make sure we cover all of the most burning topics. Thank you for your engagement!
Let me kick off by answering some of the questions related to ProForma. @Dan C and @Troy Chaplin asked about our plans around ProForma's future in Data Center.
ProForma Server and Data Center will remain on the Atlassian Marketplace and will be supported by Atlassian. There are no immediate changes planned for ProForma Server and Data Center customers and there is no action needed on your part.
As a reminder support for Atlassian Server products, including ProForma Server, ends on February 15, 2024 PT. Users with an existing license of the app version of ProForma can continue to renew and use it until its end of life on February 15, 2024 PT.
There will be support for Insight data in ProForma coming in the next couple of quarters. We’re also working on improving Insight’s import and index performance, auditing coverage and UI/accessibility.
@Carmen Nadeau asked about translations in ProForma.
Hi Carmen, this can be achieved by creating a request type and request groups for each required language, then building a ProForma for each language required and linking it to the relevant request type. When building the form, make sure to set the form language to the correct language. If the request types share a common workflow they can be processed in the same queue. I hope it helps!
I agree with you @Carmen Nadeau if we want to be true Dev Ops we need a pipeline that allows us to move changes from non-production to production natively. Right now I use Configuration Manager for this. But the way I see it is this, if a third party company can do this, why can't it be done natively.
You are missing the point. We do not want to create 2 versions of the same request types, that is not how this is suppose to works.
Every other ITSM tools allow you to translate a request types to the language of your choice, NOT create as many request types as there is languages used in the cie. You double your work load, double everything else and your portal will display 2 forms for the same request type.
There were a few questions about dark mode. Dark mode for Data Center is not in our short-term roadmap. We are focusing our investment on what customers have told us are the most important areas for them: performance and scale, security and compliance, and infrastructure and operations. This does not mean that features outside of these bounds will not be added, it is just not our focus for development right now. We would love to learn more about what the most important reasons for dark mode are for your organizations.
Thank you for sharing your use case with us regarding content lifecycle management, and for the suggestions on how these could be solved. We know archiving is a useful tool for admins and users to manage scale and clutter in their instance, and recognise that Page archiving is available in Confluence Cloud. We have tended to focus on managing Confluence scale at the space-level, but also acknowledge that having ways of managing excessive content on the page-level would address the problem you’re experiencing.
We currently recommend that customers create an “archive” folder or parent page for outdated content. Users can then move old and outdated pages under the archive’s parent page so everyone on the team knows to ignore them. When coupled with page restrictions this can largely solve your use case. Another option is to move pages to an archived space.
We have also shipped cleanup features in Confluence DC that help to identify and manage clutter in your instance. Analytics data can be used to identify spaces that have not been viewed or updated recently. This helps you decide which spaces to archive. Retention rules also allow you to automatically delete historical versions of pages and attachments and purge deleted items from the trash.
Thank you for your feedback on Confluence Analytics. We don’t have plans in our current roadmap to extend analytics functionality. There are some options available when administering analytics to determine who has access to analytics, and whether you want to use “increased privacy mode” to minimise the amount of personally identifiable information (PII) that is collected and displayed to users. Space admins can also limit who can view analytics reports for specific spaces.
It would be great to know more about your use case. Are you able to elaborate on how you would like the data to be obfuscated in the UI? Which screen/s are you referring to?
Thanks for all your feedback.
@Gosia Kowalska what’s the justification to keeping proforma as a plugin? Why is this not being merged into core like it is in cloud? Will it become a free app, or are we going to continue to pay for it?
Hi @Matthew Martin
Thank you for sharing your use case with us. We know archiving is a useful tool for admins and users to manage scale and clutter in their instance. We have tended to focus on managing Confluence scale at the space-level, but also acknowledge that having ways of managing excessive content on the page-level would address the problem you’re experiencing. We recognise that Page archiving is available in Confluence Cloud.
Have you looked into Audit Log Events as a way of tracking cases of data deletion? There are a handful of events that track when certain data is deleted across pages and blogs, templates, users and groups, and spaces. Our intention with Advanced Auditing is to improve security and visibility and help drive compliance across your Data Center products.
We have also shipped cleanup features in Confluence DC that help to identify and manage clutter in your instance. Analytics data can be used to identify spaces that have not been viewed or updated recently. This helps you decide which spaces to archive. Retention rules also allow you to automatically delete historical versions of pages and attachments, and purge deleted items from the trash (acknowledging from your message that this might not be desired!).
On the topic of page complexity - thank you for sharing some of the challenges you are seeing with certain pages growing larger and larger. As I have already mentioned, performance and scale are primary focus areas for our Data Center product teams, so this is valuable feedback for us.
We have tended to focus on managing Confluence scale at the space-level, but also acknowledge that having ways of managing excessive content on the page-level would address the problem you’re experiencing in your instance.
We are currently working towards sharing Guardrails with customers, which will help admins manage attributes that excessively tax product performance. Guardrails will provide data dimension recommendations to identify and manage performance and scale risks. This is on our public roadmap for delivery in Q2-Q3 this calendar year. While the first iteration of Guardrails is unlikely to include page-level recommendations, this is something we will look into for subsequent updates.
The first Guardrails version will include page-hierarchy recommendations, which should help you optimise page trees and in the process, create opportunities for archiving or removal of dated content.
This information architecture strategy for Confluence is a great resource to help keep content organised and easily accessible in Confluence.
I hope it helps!
@Gosia Kowalska you mention that the focus is on what the customers want the most. If that’s the case, why are there such an incredible amount of open issues with a significant amount of watchers, votes or comments that have been sitting in the Gathering Interest status? For many many years, may I remind you.
@Troy Chaplin at the moment ProForma continues to be offered as a paid app on Atlassian Marketplace. But we are actively evaluating other possible approaches, and considering potential customer and business impact if we changed this model.
Answering Jira Service Management questions from @Carmen Nadeau and @Dan C
The ability to move/use the configuration of a request type to another project isn’t currently possible in Jira Service Management Data Center. The ability to duplicate request types within a project was recently shipped in JSM Cloud, and our Cloud team is actively working on shipping the ability to copy request types across projects. There are no current plans to bring this across to Data Center, but we will keep an eye on adoption of this functionality in Cloud and can look at this as a potential feature for DC in the future.
Jira Service Management Data Center works on a Project : Portal relationship, which is reflected in the way request types, groups, Knowledge Base, and SLAs are all structured. We do not currently have plans to change this association. The Help Center provides the aggregate ‘portal of portals’ level that acts as the central catalogue for customers to land in and browse all the portals they have access to. There are options to customise the Help Center.
We have recently invested in further customisations and enhancements to the portal, such as displaying SLAs, @mentions, toggling the portal search bar toggle on/off, auto-populating fields and customising the Help Center requests lists. We will also be shipping Help Center column sorting and Help Center announcement improvements in the near future (please see our public roadmap for further details).
It strikes me as a bit odd that this is an AMA to try and alleviate customer concerns about the future of DC yet some of the answers are in a way promoting features of cloud that are not coming to DC.
This does nothing to give me confidence, it just gives me more cause for concern.
Hi @Dan C . Forge is a platform for Atlassian’s cloud products and all apps developed on this platform are fully hosted by Atlassian. We have no plans to make Forge available for Data Center products nor build a similar tool for app development on Data Center.
We believe that the current Data Center app development framework offers vendors the right level of flexibility to solve even for the most complex use cases.
With that said, we are continually investing significant time and effort in Data Center to better understand how your apps behave on Data Center instances leveraging improvements across the DC Apps framework to app diagnostics.
A recent example can be seen in the App Monitoring tool that shipped in Confluence Data Center and that is coming to Jira Software Data Center soon. Moreover, we continue to invest in Data Center Apps certification program with focus on app performance and security.
If you have any suggestions regarding further investments in Data Center Ecosystem we would love to hear from you.
Agree with @Troy Chaplin
The mentality of holding the arguably "better features" and promoting them to Jira/Confluence Cloud doesn't exactly scream "come and pay for Data Center". Data Center products are very important for so many customers!
I'd at least expect the highly upvoted requests be included in a roadmap so we have confidence these features will come to us.
Hi @Troy Chaplin
Thank you for your initial question and a follow-up comment about issues sitting in "Gathering interest" status. We understand that it is disappointing to see requests waiting without an update or not being resolved for many years. We are constantly trying to improve the process and be more effective in closing our communication loop with customers, but we recognize there is room for improvement.
Our public instance of Jira (jira.atlassian.com aka JAC) is just one of many sources that we gather customer feedback from. Data Center product teams regularly meet with customers, and field teams, we work very closely with Atlassian support organization, we are active participants of Atlassian Customer Advisory Board and we engage with customers on Community, e.g. through conversations like this one.
Over the years we have shipped many impactful features that have been requested by customers through JAC e.g project and issue archiving, improved custom field experience, improved email notifications, future sprint dates, and flexible nomenclature, to name just a few.
We continue to regularly review and prioritize customer requests coming from all the above-mentioned customer feedback loops. With a multitude of customer requests and multiple feedback loops, prioritization decisions are never easy.
My team is currently looking into ways to more effectively close the communication gap loop with customers and be even more transparent about what we are currently focusing on and which requests are not on our radar.
Please, make sure to review our Data Center public roadmap for quarterly updates on which problems we are focusing on.
Cross-posting my comment https://community.atlassian.com/t5/Data-Center-articles/The-Future-of-Atlassian-Data-Center/bc-p/2036340#M374 thanks to @Dave Liao 's prompt
Prior to Atlassian's acquisition of Code Barrel, Automation for Jira for DC was released every two weeks, with features pretty much on par with Cloud. That Automation has gotten so far behind on DC is puzzling. Not only is no code "the modern way", providing it also on DC is surely is the easiest way to ensure that customers on DC build with the least barriers to move to Cloud.Yet, why do we see no user smart values on DC? How about processing 4XX web request replies? Both of these have existed on Cloud for more than 6 months. Without DC-Cloud parity on Automation, your no-code message gets hazy, and more customers need more app-based Scripting, with further cost and later resistance based on script-based investments to take the leap.Automation is vital to automated housekeeping. So, it would be really good to get Confluence Automation on DC, again easing progression for those who choose to go to Cloud.
It's important to remember that no-code platforms have limits. Even platforms like Zapier provide the means drop into code in your choice of language in a Functions-as-a-service system such as AWS Lambda. Supporting Python and Node.js would be awesome.I would think Atlassian's value proposition would be stronger by supporting an official code container accepting webhook REST calls with optional callbacks for long-running asynchronous processing. Given the commitment to Kubernetes this could be reasonable.
Regarding @Troy Chaplin about SEO for Data Center documentation.
Generally, we hear that people looking for Cloud docs are finding the Data Center versions, but it sounds like you’re having the opposite experience.
One change we have made in the past year is to include the deployment type and version number in the link title, so Google search results should always include whether the page is for Data Center (and which version), or Cloud. The Cloud and Data Center docs are also published to different domains, so restricting your search to site:confluence.atlassian.com can help exclude Cloud results (that are generally published on support.atlassian.com).
We know this workaround is not ideal. A replacement search implementation is on our backlog however it has not been prioritized to be addressed in the near future. Thank you!
Jira Cloud Migration Assistant is a bundled plugin that is shipped with every new version of Jira Software/Jira Service Management Data Center and Server. Migration to Cloud is a priority for many self-managed customers and by shipping migration functionality directly with the core product, we make sure it is easily available for anyone who decides to migrate to Atlassian Cloud.
We believe that with the current user experience we are not forcing migration assistant on anyone, but we want to make sure that it can be easily found when needed.
Thank you for your feedback about Jira Cloud Migration Assistant causing upgrade issues, we will look into it and make sure that migration functionality does not negatively impact your upgrade experience.
I hope it helps.
Anyone else seeing the trend I am seeing?
Atlassian: Ask me anything about about Data Center and we will answer
Customer: Asks pertinent questions looking for answers
Atlassian: Responds to every question with the same answer - Move to Cloud
Gosia, As a manager of the Jira Support team at our organization, having our implementation as clean as possible is very important. I understand wanting to make the Migration Assistant easy to find; however, constantly placing it on a server after every upgrade is not necessary as the Marketplace has a very easy search engine that allows anyone wanting to migrate to go get the assistant plugin.
Forcing those of us to have to remove it from our implementation because we are not migrating to cloud is causing issues. As someone who has performed upgrades in our Data Center environment and seen the errors in the Log files caused by previous versions of the migration assistant, and then requiring to perform more steps to help get our servers running optimally, I think removing it form the build makes much more sense than always putting it into the upgrades.
Why not include code that looks to see if the migration assistant is already installed, and then provide it's upgrade versus always putting it back on the server, making us uninstall it manually.
Where is the dislike button when you need it?
Hi @Gosia Kowalska I know you mention that Dark Mode is not a feature that is on your short term goals, I can assure like most here on this AMA, I hear HOURLY why can't Jira do dark mode out of the box. So much so that we have to pay for a plugin to do this, it seems like this is a trivial task, and it sounded like it was coming in Jira 9. Is this no longer the case? Why would something as Dark Mode not be an easy win for Atlassian.
On the topic of Cloud vs DC. Atlassian seems to want to push users to that, yet core functionality is lacking in Cloud. DC I have the support structure I need to get my job done, for Cloud I would have to pay for the premium tier, which is almost double the cost of my entire instance of DC (Confluence, Jira and plugins) to have that same level of support. Things I'm referring to Cloud :
admin rights to adjust restrictions,
raising a support ticket
These are basic features in DC. Should we worry that DC will also end up going into the same path as cloud and have tiers?
Agreed @Jeanne Howe , I was expecting better answers but I too get a feel that most of our questions are “Gathering Interest”
I also have the feeling that Atlassian mainly is doing everything to push customers into the Cloud. Why? I have an assumption.. ;)
Example: Confluence Knowledge base is out-of-box in the Jira SM Cloud version but not in the Jira SM Data Center version? Why? Is it to complicated to implement this into the DC version.. ?
Hi @Dan C . As of right now this is not something that is currently on the roadmap. I understand that it is frustrating to not see this problem addressed for many years. This has not been prioritised due to the extensive architectural change that would be necessary. Instead we have chosen to provide customers with a workaround that we know is working for many customers and focus on other major problems that require significant engineering investment such as: Front-end re-architecture for improved performance, automated clean-up, index management, support for Kubernetes, App Monitoring etc.
Head of Product Data Center
26 total posts