Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
How many have been in meetings where the person is taking notes and creating tasks in a Spreadsheet only to then transcribe it into Jira later?
There is opportunity here to make Jira as responsive as the speed of thought so that it can replace spreadsheets. This is where Jira Work Management could help, in addition to deferring/batching whatever internal operations Jira is doing why the user is waiting for their issue to be saved.
I also strongly agree with the previous comment on "upgrade the overall look and feel" of Jira. As more new folks enter the workforce, their previous usage of other contemporary products is going to raise expectations of what a PM/Task tool should feel/look like, and how responsive it should be.
Currently load balancers need to implement sticky sessions in order to maintain user session data. This means that if a node goes down for any reason the user loses their login session when they get bumped onto the next node and are forced to log in again. With SAML this happens quickly, but not seamlessly, and the user can lose any unsaved data in the process.
It is still experienced as an outage by the user, and thus doesn't really live up to the 'eliminate downtime' promise.
Are there any plans to implement a shared cache system like Redis or Memcache, specifically to share login and session data between nodes?
In large Jira instances the integrity checker takes a very long time to complete. In our instance with an HTTP timeout set to 15 minutes, it’s not possible to complete an integrity check in that window, meaning the integrity check will fail after 15min with no way to see if it found anything, nor a way to fix anything it found.
Are there plans to make this system better with background processing that doesn’t fail if you don’t have excessively long http timeouts?
Relating to Confluence: What are your plans concerning accessibility features? For example, navigating the edit mode via keyboard it's impossible to configure macros. Do you have kind of a roadmap for those issues?
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
May 18, 2022 edited
Relating to Confluence: On the Data Center roadmap, you are talking about "Index and search improvements" for Q3/Q4 '22. Can you provide any insights here as to what exactly those improvements will be? As app developers, can we also make optimizations towards search and index performance?
Q: What are the plans to increase Confluence collaboration scaling from the current 12 editor limit?
More detail: We've had great adoption of Confluence during the pandemic, including for some high profile senior management meetings. However, we consistently hit pains with collaborative editing in terms of stability and the current 12 simultaneous editor limit. As much as I love and advocate for Confluence usage, particularly because of its interconnection to Jira, I will have to encourage investiation of alternatives such as Microsoft solutions if Confluence cannot operate confidently at a higher collaborative scale.
Q: What are the plans to make Jira and Confluence interoperable workflows smoother and more powerful?
More detail: It still feels in places like Jira and Confluence are developed by two silo'd teams with reluctant cross-connections, who treat the other product as a 3rd party. I'm glad to see that the people on the AMA all have titles are are about Data Center and not about a specific topic. I'm hoping that means that Product Management is looking at how to reduce friction and increase capability for user workflows that seamlessly move between products, and particularly these two flagship products. We shouldn't need a third-party add-on to get two Atlassian products to play nice together. :)
I'm really curious (as is my team) about How Atlassian is looking to handle the open tool chain issue.
Essentially, maintaining in house custom integrations is typically costly, and they typically fall out of date rapidly.
Is there anything that Atlassian is planning to do to make it easier to integrate with other ITSM tools like service now?
Would it be possible to allow JSM portal tiles that will redirect to other tools / URLs? This would greatly assist in the ability to direct customer traffic and actually leverage the benefits of using confluence and JSM together.
I could see a solid reason why Atlassian would have strategically avoided heavily getting into the integration space, but this is a place where the very large enterprise customer sees the most pain due to the sheer volume of tools that a company can come to use for similar functions in their organization.
That being said, understanding the strategy will help teams in these environments make more sustainable choices going forward.
Please review my comment and let the forum know what we can expect from the DC Roadmap.
Thank you,
Debbie
================= ===================
Hello,
I am interested in a roadmap that details a timeframe where the products announced for the Cloud at the April 2022 Summit will be ported to DC.
The roadmap should include at least JIRA, Confluence and Bitbucket.
For example: JIRA Product (product roadmap module), Atlassian Analytics.
I feel that Data Center is becoming an orphan in Atlassian's product offerings and this would help the DC customers understand Atlassian's approach to this product suite.
Will there be some form of Live Chat being available in JSM in the future?
Live Chat is a key service desk function and is more popular than ever in the last few years to receive quick support.
A simple Live Chat feature integrated into JSM should allow a Service Desk Team role access to use it if it is enabled. This subsequently creates an issue and all comments are added to the issue. This can then be actioned by the team as usual.
2. Pricing
Jira, JSM and any plugins seem to be getting more expensive by the year. I recall a recent increase in the cost of licences. With Data Center options, you host applications yourself which if you use AWS like we do, the cost of running any Atlassian Data Center platform is running high. Is there any room for improvement on the pricing for Atlassian Data Center products?
3. Dark Mode
Goes without saying, Dark Mode is very popular for many reasons. When will Data Center options get this?
4. Granular Permissions
Is it at all possible to improve the global permission structure? For example, Jira System Admins and Jira Admins have slightly different permission levels. When it comes to Jira Admins though, can the creation of projects, editing schemes etc. be restricted further? It would be useful to even have a permission level that allows access to user management but nothing else.
5. Sharing Configuration Between Projects
This has been mentioned a lot and I completely agree, The ability to share or copy configuration between projects specifically JSM projects is vital! Having to create new request types and QUEUES is such hard work! Some JSM projects have maybe 10-15 queues which are a pain to recreate to a standard! Please implement some copying features!
6. Archiving Features
It's easy enough to archive a project as a whole but why is there no feature to archive individual issues in bulk? Is this something that can be improved on? I'd also like to see a better export of archived issues including a deeper dive into custom fields. At least if there was an option on Jira Automation to archive issues on a cron job, that would work nicely!
I would love for Atlassian to comment on their strategy around identity management for data center customers. Long ago, I was really hopeful that Atlassian would just give everyone crowd for free because you really needed to have a central place that identifies the team, the team roles, and the role members. Within each application, you could then map the roles to specific permissions within the app. Sadly, Atlassian went a different direction and embedded parts of crowd into each application, which solved authentication but didn't address the need to coordinate the team's role-based authorization across multiple applications.
Just focusing on authentication for a moment: Multi-factor authentication is commonly required and and since Atlassian hasn't provided this as native functionality, we've been using SAML-based authentication. It's difficult to manage this when multiple identity providers are needed to handle different groups of people though. At one point, it looked like crowd might become the single identity provider needed (see CWD-677 and CWD-1822), but months and even years slip by after we're told Atlassian is working on something there, so it's not clear if anything will ever see the light of day.
On the cloud side of things, it looks like centralized authentication and authorization across the different applications is a reality (or at least much further along). Is there a strategy for data center customers or are we doomed to use groups and other workaround to achieve centralized multi-factor authentication and role-based authorization?
Why isn't Atlassian supporting/developing any feature or functionality updates in DC? There is a 20 year backlog of feature requests and functionality improvements that is being completely ignored.
Are there any plans to provide out‑of‑the‑box knowledge base in Jira Service Management Data Center as it is available for the Cloud version? If not, why you do not offer a lower tier version for Confluence (Data Center) which can be used as knowledge base only?
Following questions with JIRA Datacenter in mind: Regarding the long term support and development of Datacenter products, how would you describe your thoughts from atlassians perspective in comparison the the cloud products? Why do you keep up support for the Datacenter versions of your products?
Are there future plans to provide customers from DACH/EU region with privacy (DSGVO) compliant cloud instances hosted in europe? If so, what would be your approach in detail?
Obviously the gap between the development of features for the cloud services in comparsion to the data center versions is increasing. Will Atlassian change that?
When will all the features of "Automation for Jira" be added to Jira DC which at the moment are only included in the cloud version and are missing in the DC version?
Being able to share more objects between Jira projects (like request types in JSM) will help with re-use and encourage best practices.
Even when supporting a small number of service desks, there's often very-similar request types, yet admins need to re-create these request forms over-and-over.
Are there plans to improve JSM administration, and gain some of the admin features from JSM Cloud?
Are additional ways to manage global objects (like the custom field optimizer) in the works?
@Dave Liao Agreed on shared objects. The one that I think was most striking to us when we first adopted Jira, and still impact us since is that lack of the ability to have shared Releases across projects. We've made a homegrown solution, but users can still accidentally mess things up. I understand in the early days perhaps Jira users were small groups, but once you put the Enterprise label on something you'd kind of expect they might be working on substantial, multi-team commercial products.
I would like to know from Atlassian, if Data Centre isn't going anywhere why are the product support teams heavily trying to push teams the require Data Centre to switch. There are several admin functions that are not supported in Cloud that we require and when we explain that to Atlassian (mainly from the ELA purchasing side) they continue to tell us Cloud is better. I would, like many of us in the AMA would like to know what are the plans for new features coming to Data Centre to make our lives easier, and since the push to Cloud is apparent are there features that will never get touched?
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Will we ever have an integrated tool that will allow us to deploy a request type from staging to production.
In an enteprise size cie, the best practice is to develop a new request type (or a workflow, etc) in a staging environment and when everything is done, approuved and a change is also approved, we can deploy this new request type in the production environment.
As of today we have to use an addon to do this. And there is no addon that is able to that in a granulary way and if you don't use an addon, you have to recreate EVERYTHING mannually. That is nonsense.
If you want to attract big cies, there must be an integrate functionnality allowing us to do that.
128 comments