Now available: UI modifications allow you to change the Jira UI in the runtime

We’ve just launched the first release of UI modifications, a Forge module that allows apps to change how Jira fields behave on the Global Issue Create view. Unlike other Forge modules, which allow you to inject content, this actually lets you customise the behaviour of the native Jira UI.

This module makes it possible to build new, innovative types of apps for a range of exciting use cases, including: personalisation, interactive forms, and web apps.

Check out the developer blog and the docs for full details.

UIM-1

UIM-2

This release is currently in its preview phase, and there are a few limitations to be aware of. That said, this is a powerful new capability and we’re excited to see what developers begin to build. We’re moving quickly with development, and you can see what’s up next in the FRGE project.

Use this thread to ask questions and share your feedback. Our team will be keeping an eye out for questions.

11 Likes

@MichalMichalczuk - is this coming to connect as well?
If no, any particular reason?

13 Likes

This is Forge only module.
We bet with this one on Forge, since this is the future platform of Atlassian ecosystem. Our important reasoning was also the fact that in Forge we have the most control over the permissions which user grant to the app.

This API is pretty powerful - and it can read a lot of user input, so we’d like to explicitly ask users to grant those permissions to the app. To let them be aware of that.

Please check https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-ui-modifications/#scopes for complete list of scopes, we’re requiring from Forge app to use this module.

1 Like

That is a wild statement. We all know that it is true, but this is the first time Atlassian is actually admitting as much. Can you now go on and also confirm that Connect is deprecated?

If so, please make sure to also update all documentation to make sure that new developers do not spent time learning a platform that Atlassian has deprecated.

Seriously, I’m not kidding. This is the first time an Atlassian staff member has openly admitted what we all have expected for some time now. Can you please confirm that you’re in the position to make this official announcement?

15 Likes

Now for commenting on your reasoning:

We all know this is utter horse crap. There is no technical limitation that prevents you from building the same control of permissions in Connect. You chose not to, but that is a strategic business decision, not a technical one.

So can you please provide a proper reasoning for not building this in Connect?

7 Likes

@MichalMichalczuk - I am with remie on this one.

Atlassian keeps telling us that connect isn’t dead, and that it plans to continue investing in connect, and blah blah blah. Yet here we are again, with yet another feature that is forge only.
If you’re going to continue investing in Connect, then actually do it. If you’re not going to, then fine, at least admit it.

5 Likes

Also, I’m confused to see user consent being highlighted here in this way. I was under the assumption it is going away and replaced with admin consent?

5 Likes

I share the frustration other partners have expressed above. I wish Atlassian would spend the resources invested in building this and other features (e.g. Forge mobile) to fix or speed up the fixing of fundamental issues with Forge instead. In my eyes, the whole issue with Atlassian pushing Forge as much would not be as bad if the fundamental issues were addressed faster. Probably the most important ones in this context: a clear and easy migration path for Connect apps and Connect on Forge (currently this seems to be at least a year away), or developing Forge apps with multiple developers.

Reading about new Forge-only features just sounds so ridiculous if the majority of the ecosystem partners are deeply invested in Connect and have no means to make use of them until Atlassian starts prioritizing projects like Connect on Forge. It feels like Atlassian decided to move on to a new platform without thinking of bringing the ecosystem partners with them. Ultimately I keep asking myself: Who is Atlassian developing these features for?

7 Likes

Even if we would use Forge to build a new app (which we have already done and found lots of issues with), these are not “a few limitations”. It’s a blocker to build any production-ready app with it IMHO.

We’d probably get a constant stream of support tickets with the following questions:

  • Why can it not be used in team-managed projects? When will you support it?
  • Why can it not be used in JSM projects? When will you support it?
  • It doesn’t work (because they have another app installed using the same tech).
  • It doesn’t work (because they use another way to show the “Create issue” dialog, e.g. opened by a connect app which doesn’t seem to be supported).
  • Why doesn’t it work with custom field X?
  • Where is field X? It’s supposed to be shown according to “Find your field” (but someone configured it to be hidden).
  • And probably some Forge bugs will also surface, like with our first Forge app.

I’d say these are more than just a “few limitations”. It’s a shame since the UI modifications look really powerful, but I’d say it’s not yet worth our time to invest building an app for it just to get 1-star reviews because of missing Forge support.

4 Likes

Thanks for raising valid concerns here. Let me chime in to share a bit more context. As you know, Atlassian is on a cloud transformation journey. We are spending a lot of time and effort analysing and remediating blockers to cloud adoption of our products, and several of these blockers relate to ecosystem. As you all know, Apps are critical to bring our products to the final mile to meet the requirements of many of our customers. With this shift, we are seeing strong evidence that migrating enterprise customers have difficulty assessing the security posture of cloud apps. Bringing apps onto Atlassian’s infrastructure allows partners to leverage Atlassian’s investment in security and privacy, and assures customers that apps offer the same level of security as Atlassian products. Forge is not the only investment we are making; other programs such as Cloud Fortified also help customers understand apps’ security postures and simplify selection of apps that fit their org’s needs. In the longer run, we are aiming to have one platform across Atlassian products, as stated before - we are working on unifying connect and Forge. We have teams working on building a bridge to merge Connect with Forge. This is a long journey and we are making incremental progress towards that. As we have also stated, we intend to deprecate less secure parts of Connect including JWT Auth and remote iFrames in the future and will provide sufficient consultation and notice.

As to how we’re prioritizing new features in Forge, we have a number of streams executing in parallel, and in the spirit of continuous delivery we attempt to ship new features incrementally as they become available. This particular feature was enabling a use case to allow apps to implement a specific use that will allow some large enterprise customers to move to cloud who had very strong security and data privacy posture.

Forge isn’t ready for all Marketplace apps yet, as it is still missing some features that some of our more sophisticated partners consider table stakes. There are quite a few Marketplace apps that are built on Forge these days and some of them are quite successful. However, we’re working on delivering features like multi-user app ownership that we know partners need, and our ambition is for Forge to be able to support every app use case - that’s why we’re putting so many of our resources towards Forge while also continuing to dedicate resources to Connect.

Hope this provides a bit more context on the topic. Happy to have a zoom call to chat about this more, feel free to drop a DM, and we can take it forward from there.

2 Likes

Dear Atlassian (as this is not a personally directed at you @asridhara),

You. Are. Not. Listening.

We know the context, we don’t need another marketing message with rehashed talking points on how great Forge is compared to Connect (esp. because you should Stop saying forge is more secure than connect)

You have an Atlassian Marketplace GOLD Partner telling you:

Reading about new Forge-only features just sounds so ridiculous if the majority of the ecosystem partners are deeply invested in Connect and have no means to make use of them until Atlassian starts prioritizing projects like Connect on Forge. It feels like Atlassian decided to move on to a new platform without thinking of bringing the ecosystem partners with them. Ultimately I keep asking myself: Who is Atlassian developing these features for?

And you have an Atlassian Marketplace PLATINUM Partner telling you:

I’d say these are more than just a “few limitations”. It’s a shame since the UI modifications look really powerful, but I’d say it’s not yet worth our time to invest building an app for it just to get 1-star reviews because of missing Forge support.

Please tell me, how are you going to resolve your problem of hampering Cloud migration because of blockers related to the Atlassian Ecosystem if you are not listening to the people that you depend on to resolve this issues?

You are loosing the confidence of the people on whom you depend, the people that are cheering for you, your greatest promotors, the people that want you to succeed. If you can’t listen to their concerns and address them properly (you know, like, in correspondence with your explicit company value) you are setting yourself up for failure.

This is not a technical topic, this is a topic about stakeholder management, and despite all the nice white papers you can write about this, I’m sorry to say that you are really doing a shitty job.

cc: @Bentley @tpettersen @amardesich

5 Likes

Thanks for your reply @asridhara. To be honest, there is nothing new in your post that we do not already know, and neither does it address any of the concerns raised. I do not want to divert too much from the main discussion here but will comment on a few items from your post:

Yes, I fully understand this but there are many things that could be done in the short term (example) to help with this apart from developing a whole new platform which is a multi-year journey and not a short-term fix. As Remie alluded to above, improving the Connect platform in that regard seems to be the much lower hanging fruit.

This is exactly my point. This feature is addressing a very specific use case that may benefit a few selected partners. At the same time, there are some really important foundational features still missing. All your post says about those is that Atlassian is working on them.

The timeline given in that blog post is not up to date anymore. The most recent update I have seen, indicates that this is delayed without a clear timeline.

I strongly believe the success for Forge will come from existing Connect apps and by bringing the ecosystem along yet Atlassian seems to prioritize features for newly built Forge apps instead. It just does not feel like we are on this journey together.

3 Likes

Thx for the comments, thx @asridhara for the commentary.

I’d like to focus on UI modifications in my answers, so sorry for not answering the Forge & Ecosystem strategic-related questions here.

Even if we would use Forge to build a new app (which we have already done and found lots of issues with), these are not “a few limitations”. It’s a blocker to build any production-ready app with it IMHO.
We’d probably get a constant stream of support tickets with the following questions: …

Oh, I highly agree with you that what we delivered in this release might be not enough for a lot of cases.
We released the preview version, as it also stays in https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-ui-modifications/, to give you access to it and the ability to play with it when we have anything which brings value to reveal publicly.
It is not GA (Global Availability) module yet.
You can find our future plans for UI modifications on those FRGE tickets.

Our rationale:
We are aware that apps are not created overnight, and the business development process and actual implementation take time.

We don’t expect first Forge apps on the marketplace using UI modifications being there the very next day as well. That’s why we decided to release UI modifications features incrementally, to give you a chance to explore this new extension, and develop ideas build with UI modifications right away - while it is still far from the end state.

What’s next
To answer “Why can it not be used” answers - we picked up a limited set of features for the first release, and we consciously cut the scope. Our team is continuing work on the new UI modifications features and current limitations, and we’re ready for a long run on that.

Please check those FRGE tickets to have a sneak peak in our plans.

If you’d be interested in more detailed roadmap for UI modifications - please let us know!
I hope that you’ll find great opportunities and ideas to develop apps using UI modifications and please give us your feedback about it!

1 Like

If this is the case, can you elaborate why you felt the need to refer to Forge & Ecosystem strategy in your previous comment?

The reason I’m asking is because if you really only want to talk about the feature UI modifications, the question why is this not available for Connect becomes immediately relevant. There are plenty of vendors that would love to start implementing this feature in their Connect apps.

If the team made the decision to make this a Forge only module, the team should be able to answer the question why it was not built in Connect. If the team did not make the decision, please refrain yourself from commenting on Forge & Ecosystem strategy and please forward our questions to the person responsible for making that decision for the team.

EDIT:
I know Atlassians don’t like answering the difficult questions, especially not because of the buzz kill. I know you came to this forum to celebrate the release of this new feature and only got grumpy responses, which sucks. We get that. But to be totally honest with you: that’s on Atlassian, not us. And it’s on you, Atlassians, to suck it up and also face the unpleasant consequences of the decisions that the company is making.

1 Like

I’ve been pondering a while about what rubs me the wrong way about Forge and these changes, and I think I tend to agree with @remie on the way you are selling Forge. The problem is - remote iFrames are totally fine security wise, if you have a capable team with an eye on security (most bigger vendors do in my experience). If you look at other companies and their extensibility models, you will find plenty of remote iFrames (e.g. extending the Microsoft Teams UI). With telling us “that’s insecure” and Forge is the solution, it comes across that you solved a problem that no one else has managed to solve, which is a bit unfortunate to vendors who have been trying to become very good at security practises over the last few years.

I feel like the whole Forge thing was a bit rushed into C-level-visibility mode, without considering the impact. There are very good (technical) reasons to prefer an extensibility model like Forge for certain features (e.g. the UI modifications, or rendering single custom fields, which is not really a great with iFrames - remote or not). In addition to that, allowing capable customers (or inexperienced vendors) to quickly implement custom functions or logic without spinning up some own, hosted infrastructure is great, totally behind this reasoning. Same for secure, hosted Atlassian storage.

Unfortunately, along the way, Forge lost focus and suddenly became the Connect “successor”, trying to replace Connect because security. In my opinion, that’s where you went wrong unfortunately, even torpedoing the success of Forge, by wanting it to be too much. The problem with this is, you are trying to find a technical solution to a problem (trust for 3rd party vendors), that’s in my opionion (and I can’t believe I’m saying this as a developer) an organizational maturity problem. Something that ISO27001 and SOC 2/3 are trying to solve. You can, perfectly fine, be a company offering a secure, remote iFrame. We are currently in the process of certifying us with ISO27001 and I have gained utmost respect for this framework, as it really makes you think about operational security, besides the “code”, like proper access control, on/offboarding etc.

Now, you might be saying: Well, if it’s on Forge, everything is hosted with us, so that matters less. While that was kind of true with the original vision, you are now weaking in Forge in a way to be compatible with Connect, so this becomes murky. Before, Forge was something customers could look at and almost blindely accept as secure, while now, they will need to look at “Well what Stage of Forge is this app, 4,5? What exactly does that mean for this particular app, better send them the stupid 33-pages security survey anyway”. You are not solving this problem anymore, because you basically still allow everyone to do anything, except hosting their own JS.

To make my point, let me qoute this other thread (Forge and Connect unified - #3 by jhazelwood)

For example, if your migration work can fit within Forge limits, it should be possible to, from within a Forge function, fetch data from your Connect app server (you’ll need to implement some auth) and then use the storage APIs to store it in Forge storage. You could also make use of Web Triggers to push the data in from the connect app server.

I don’t think it’s a good idea to move to a model where it’s encouraged practise to to roll your JWT authentication while sending data (in or out) to an external server - I fear this is not the improvement you are looking for, and I don’t think customers will appreciate this kind of thing.

Unfortunately, I don’t have any call to action. I think it’s too late in the process and Forge is now the spiritual successor of Connect, for the better or worse. I think, it would’ve been better to let Forge and Connect (or maybe something like Secure Connect) coexist, with proper integration points. I’d like to suggest that you think about a proper deprecation period for remote iFrames and JWT auth, because 6 month is really not going to cut it here. We have customer requirements and own 1+ year roadmaps, which we can’t just throw out the window to do a more less complicated move to Forge, with no benefit for our customers. You have a multi-million dollar ecosystem you are working with, please be considerate of the fact.

Thanks
Tobias

12 Likes

Adding to this, because I forgot it earlier, I’d really suggest looking at the Microsoft app compliance program for a good implementation of how to do this: Microsoft 365 App Compliance Program - Microsoft 365 App Certification | Microsoft Docs

1 Like

Thanks for the elaborate answer! I have already seen your plans. Unfortunately, many of the hypothetical support questions we’d receive will not be addressed until “Future - coming in 6+ months” - who knows when that will be. Some are not yet being addressed at all, unless I misunderstood (team-managed support, hidden fields, create issue dialog not opened from the 3 supported methods), with at least the last two being “bugs” from a customer point of view.

Nonetheless, thanks for highlighting once again that it’s a preview release - my mistake. I was just raising my eyebrows at the statement that “there are a few limitations”, which is a slight understatement when it’s barely useable in it’s current state :wink:

1 Like

We know the context, we don’t need another marketing message with rehashed talking points on how great Forge is compared to Connect

I can only echo what Remie wrote. It is wasteful to repeat the same rationale over and over. And it is boring and frustrating for us, your customers (who pay you money) to listen to it. Stop doing that and start listening to what we/vendors have to say.

With this shift, we are seeing strong evidence that migrating enterprise customers have difficulty assessing the security posture of cloud apps. Bringing apps onto Atlassian’s infrastructure allows partners to leverage Atlassian’s investment in security and privacy, and assures customers that apps offer the same level of security as Atlassian products.

With the above in mind, I would expect Atlassian to deliver the fully-featured storage that our apps use. So, @asridhara does Atlassian plan to release RDMBS or NoSQL-like features, starting from indexing, relations, uniqueness, slow queries reports, etc? As long as they are not there, we need to stay on Connect.
Assuming that there are more vendors like us and apps like ours, how do you plan to urge DC customers to migrate to Cloud? They can’t get in Cloud what they have in DC and you are limiting the capabilities even more.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.