In response to "RFC-37: Embeds as a New Confluence Content Type" and subsequent EAP post

Confluence Development Confluence Cloud
1

This RFC RFC-37: Embeds as a New Confluence Content Type has been closed, so I cannot comment there.

Also, there’s no way of commenting on EAP announcement About the Confluence Cloud Embeds EAP.

I’m seeing several things here that need fixing.

Missing extension points

Embeds are missing the following extension points:

  1. Content Byline Items / contentBylineItems
  2. system.content.action/primary web item
  3. page.metadata.banner web item

This is important for at least one of our app which needs these so that the app’s screens can be accessed from the content (be it page, blog, embed, whiteboard, or database)

Lack of support for Atlassian Connect context

When using Atlassian Connect, this is not populated:

AP.context.getContext(x=>console.log(x));
// --> undefined

…luckily, you can access the product context using:

AP._data.options.productContext
// --> {
//    "space.key": "~658615005",
//    "content.id": "7724207",
//    "content.version": "2",
//    "space.id": "82306",
//    "content.type": "embed",
//    "user.isExternalCollaborator": "false"
// }

Inconsistent formatting

Content/page titles and breadcrumbs are inconsistent with those of pages.

Inability to edit

Once you’ve created an embed/smart link “page”, there is no easy/obvious way to change the URL that it embeds – the edit menu item just doesn’t work.

REST APIs

One more thing that I’ll note is that the v2 REST APIs have been available for over a year, but internally Atlassian are only building out new features based on the v1 REST APIs – see also Confluence databases & whiteboards.

What kind of message does this broadcast to the wider ecosystem and developer community? My guess is “ignore v2 until Atlassian start using it themselves”.

Cc: @KaiMunechika @AbhinavSingh

9 Likes
2

I’d also add that the URLs for these new content types are not in the standard URL format from pages

/wiki/spaces/:space_key/:content_type/:content_id/:content_title

but rather

/wiki/spaces/:space_key/:content_type/:content_id

If you construct the former URL format with the :content_title, each of the embed, database, whiteboard content types will throw a 404.

Having the content title in the URL really helps with when you are sharing the URL from the browser address bar. It helps contextualise what is being shared, rather than being so cryptic.

3 Likes
3

Hi David, apologies for the greatly delayed response, and thank you for the well-defined feedback! On the issues of

  • extension points
  • connect context object support
  • breadcrumb formatting
  • url standardization

I’m working to get these triaged/prioritized with the right folks.

Re: inability to edit

The team has deployed a change recently to all affected environments that should fix the “Edit link” menu button, please let us know if this still doesn’t work on your instance.

Re: REST APIs

Bringing in Embeds support to our v2 API is our top priority w.r.t. unblocking you/our ecosystem app partners.

On behalf of the team, we apologize for the thrash and frustration here. We are making process changes internally to ensure that future changes like this one are announced as early as possible, with v2 API support as a strict requirement, among other checklist items.

Thank you for your patience and continued support, and please do let us know if you have any further feedback!

3 Likes