API update
Hi all! I’m happy to share that all API updates listed in the RFC (that were not marked as “under consideration”) are now AVAILABLE in all EAP & Developer Canary Program sites for testing. Please do leverage the API updates and let us know if you have any feedback.
Cheers,
David
@DavidMichelson any chance you could respond to this one?
Thanks for highlighting @BorisBerenberg
Also tagging @scott.dudley as the original asker
At this time, we are not considering adding this for Connect. But, as mentioned in the RFC, we are considering making subtype available in the Forge context.
Thanks for letting us know. I recognize that Connect is “dead”, but I ask that the team reconsiders this position. There are still too many issues for us to adopt Forge within the timeline described in the RFC. This means that customers will have subpar experiences with this feature because we can’t adapt our apps to this change. I don’t think it is in either vendors or Atlassian’s interest for customers to have a bad experience when consuming this new functionality.
We use a configuration macro: A macro to specify app behavior on sections of the page when receiving a page update webhook.
We currently are not displaying this macro in “View” mode, but are displaying it in “Edit” mode.
I like the idea of reducing the macro to an icon, but I fear that our app is not recognizable enough and would like to keep the current display ( App name + Summary of settings in a few words ) when users are editing a regular Confluence page.
To underscore Boris’s point, I do understand that Atlassian has a “no new features on Connect” policy. Putting the above position into perspective, Atlassian is effectively rolling out a new feature (Live Docs) that it is forcing Connect apps to adopt, and yet the tools to support that feature are proposed to be constrained to the Forge platform.
Existing Connect apps are still invoked on Live Docs pages: most existing extension points still work, Connect content and macros are rendered, webhooks are still sent, and so on. But Live Docs pages are different from regular pages, so some apps will break in various ways. If apps cannot tell if they are being displayed on a Live Docs page or not, they cannot even disable themselves in the contexts where it would make sense.
The message Atlassian is sending here is: “We refuse to allow Connect vendors to be able to even identify which pages are Live Docs and which are regular pages”.
I argue that if Atlassian is changing one of the foundational pieces of content that is handled by apps, Atlassian needs to make at least bare-bones information available about this content type to all frameworks that it currently supports (which includes Connect).
As Boris pointed out, suppose that an existing vendor has an app that only really works with non-Live Docs pages. Live Docs is coming soon, but the Forge platform features required to actually move the app to Forge will not be delivered until much later. This amounts to “we will break your app until the platform team gets around to delivering Forge prerequisites in a year”.
I understand that “nothing new on Connect” is the new mantra, but with this in mind, is including the correct context information in AP.context really an extreme amount of work?
In passing, I also wanted to say “thanks!” for your active involvement in this and related RFCs. It’s great to see Atlassian proactively communicating with the community, responding promptly during the lifetime of the RFC, and iterating the idea in ways that have a positive impact on the ecosystem. Although I do not always agree with every decision (such as is the case in this comment), I still think that having such a tight feedback loop is great. Your participation here would be a great model for other Atlassians in future RFCs.
I think this is not a good approach. And a terrible naming.
Instead:
Here is the idea visually, obviously the UI can be improved to have this as a Toggle!
What do you think?
What made you come up with a separate Name and a Separate Content Type? What advantages would that have?
Cheers, Lukas
Hi all - I wanted to call out these feature requests for bodied macros. Are there any other developers who use bodied macros that have any thoughts on these feature requests as well?
@LukasGotter Thank you for your feedback @JackGraves as well. We primarily landed on our current direction based on feedback from customers in our Early Access Program. I will share your feedback with the rest of the team, and as we move into further Beta stages we will continue to monitor feedback on this direction.
Theoretically, would the suggestion to supply subtype via AP.context.getContext() also solve for your use case (utilizing output.type)?
No, unfortunately, static macros are strictly server rendered: We render a block of HTML and cannot execute Javascript. The output type must be provided to the request to <baseAppURL>/renderMacro
See: https://developer.atlassian.com/cloud/confluence/modules/static-content-macro/ specifically the url property.
Yes, I agree with @Corentin . We can’t use AP. , because the static content macros can’t execute javascript.
@marc @Corentin Thank you for your continued feedback. I much better understand your request.
For Atlassian-native macros, we have in principle tried to maintain a consistent experience while editing no matter whether a user is editing a Live Doc or a Page. To put that in “output.type” terms, for Atlassian-native macros we would only need to know whether output.type = preview OR display, we wouldn’t need some “live” option, as no matter whether a user is editing a Live Doc or Page, the experience will be the same.
Do you think this a principle that is possible to strive for in your apps? IE - would it be OK if your apps only ever knew if the user was in an “editing” state or not (e.g. output.type = preview OR display) - regardless of if it was a Live Doc or a Page? This would also be consistent with Forge which today has “isEditing” boolean parameter that is only either true or false instead of an output.type parameter.
This is not ideal, but we can live with this decision.
We would display the same macro in live and preview mode.
Hi Developers - I wanted to check in and see if anyone had any other feedback on the Extension Point Modules section.
@scott.dudley How would you feel if we shortened the “default off” period from 6 months to 3 months?
My first question would be, what concrete problem is being solved by turning everything off by default? For example, are there known problems with existing apps? On the other hand, if this is just a deprecation period to check a box for an internal requirement, I believe that earlier versions of this RFC already have already effectively given vendors notice.
For me, it doesn’t really matter: I will push out the descriptor change to add what is needed. Other vendors have users stuck on old versions of app manifests which they cannot force-upgrade, so their apps will be automatically turned off in these areas for whatever period is decided.
Figuring out how many existing apps have known problems when enabled (as implied by my question above) would help answer the question of: “Which option causes the least disruption?”, which I assume is the goal. In other words, if auto-disabling for some period creates more problems than just leaving enabled, the choice should be clear.
Hi developers!
I have updated the Discuss date to continue through the end of this week, until Friday February 21. (Previously, it was until today, Tuesday February 18).
Can an admin update permissions through the space settings? Are these states accessible through the REST API as well?
Hi developers, I’m happy to share that the changes outlined under Connect Webhooks / Forge Events in the RFC are now available for sites with Live Docs (which includes all sites in the Developer Canary Program). Please do give them a try!
Can an admin update permissions through the space settings?
Live Docs have the same permissions capabilities as Pages! There are space level permissions that can be updated the same as Pages.
Are these states accessible through the REST API as well?
These states are not available through REST API.
