Hi @Kusal and all
I found some bugs with the latest Confluence 9 milestones (including in the most recent 9.0.0-m109) with regards to the Atlassian Companion and Edit in Office features.
1. Edit in Office needs whitelisting
If Edit in Office is enabled in the Office Connector settings, it seems like the following velocity-allowlist item still needs to be added:
com.atlassian.confluence.extra.office.velocity.VelocityHelper#getWebDavUrl(com.atlassian.confluence.pages.Attachment)
2. Atlassian Companion Links Not Opening
If you do manage to launch an Atlassian Companion link from Confluence (such as from the previewer), it doesn’t open the document. Requests sent by the Companion back end to the following Confluence URL return 404 and the attachment never opens:
/rest/token-auth/api/previews/templinksresource/companion/attachment?attachmentId=AID
I didn’t debug this fully, but I suspect that the error occurs because the confluence-previews plugin has been migrated to rest-v2, but the root /rest/token-auth/api/* path is handled by confluence-rest-resources, which appears to be still rest-v1 and thus it probably doesn’t know about the sub-URLs of /rest/token-auth/api/previews/templinksresource registered under rest-v2.
3. Atlassian Companion “Edit” Button Not Rendering
I found that the “Edit” button for the Atlassian Companion was no longer working on recent 9.0 milestones, resulting in the inability to edit attachments from either the Attachments Macro or the Attachments Page. (Clicking on “Edit” just dumps you on the Attachment Properties page, if you’re using the Attachments Macro. And there is no button at all on the Attachments Page.)
I believe I found the root cause, which I wanted to share:
I first tracked this down through the Confluence Previews plugin (in js/component/companion/embedded-edit-with.js). This component sets up Companion edit buttons for everything that matches the following jQuery query:
var allEditButtonPlaceholders = $('.companion-edit-button-placeholder[data-linked-resource-id][data-linked-resource-container-id]');
However, this no longer matches anything in the DOM in recent 9.0 milestones. The companion-edit-button class exists in the HTML output, but the two extra attributes do not, so the query returns nothing.
The source <web-item> for this is defined in:
./confluence-project/confluence-core/confluence/src/main/resources/plugins/attachment-actions.xml
and it is supposed to have a bunch of extra attributes that make it match the jQuery selector above:
<web-item key="edit-in-app" name="Edit attachment using Companion app" section="system.attachment" weight="60">
<description>Allows editing of attachments using Companion app</description>
<label key="attachment.edit.with.app"/>
<styleClass>companion-edit-button-placeholder</styleClass>
<param name="has-custom-attributes" value="true"/>
<param name="edit-with-placeholder" value="true"/>
<param name="attribute.data-linked-resource-container-id" value="$page.id"/>
<param name="attribute.data-linked-resource-id" value="$attachment.id"/>
<param name="attribute.data-source-location" value="attachments"/>
[…]
In the Confluence Attachments plugin (confluence.extra.attachments), in order to display the Attachments macro, it renders via templates/extra/attachments/attachments-table.vm. This contains code that looks like this:
#foreach ($item in $webItems)
#set ($itemRenderedUrl = $item.link.getDisplayableUrl($request, $webInterfaceContext))
#set ($hasCustomAttributes = "")
#set ($editWithPlaceholder = "")
#if($item.webParams)
#if ($item.webParams.get("has-custom-attributes"))
#set ($hasCustomAttributes = $item.webParams.get("has-custom-attributes"))
#end
#if ($item.webParams.get("edit-with-placeholder"))
#set ($editWithPlaceholder = $item.webParams.get("edit-with-placeholder"))
#end
#end
Here, $item is an instance of ConfluenceWebItemModuleDescriptor, but in platform 7, this class no longer has a getWebParams() method, so item.webParams is falseish.
If you replace item.webParams with item.params and item.webParams.get(abc) with item.params.get(abc), most of this code then works. However, there is still a macro at the bottom of the file:
#macro (renderCustomAttributes $webParams $webInterfaceContext)
#set ($map = $webInterfaceContext.toMap())
#foreach($paramKey in $webParams.params.keySet())
#if($paramKey.startsWith("attribute."))
$paramKey.substring(10)="$htmlUtil.htmlEncode($webParams.getRenderedParam($paramKey, $map))"
#end
#end
#end
This is the part that adds the data-linked-* attributes, called with #renderCustomAttributes($item.webParams, …) but it looks like it needs to be called now with #renderCustomAttributes($item, … because params and getRenderedParams are now direct members of the ConfluenceWebItemModuleDescriptor class.
The Attachments Page is also broken, as mentioned earlier. It looks like someone already made an attempt to fix this already (confluence/pages/includes/attachments-table.vm, plus the very-similar renderCustomAttributes macro in confluence/template/includes/menu-macros.vm) but it still does not render anything at all for the Companion button. I did not try to track this down but I assume the cause is similar.
Scott