Bitbucket Decoration of Admin plugin settings page


#1

I’m developing a plugin for Bitbucket Server 5.7.1. I’m trying to add a create an admin plugin settings form following this tutorial: https://developer.atlassian.com/server/framework/atlassian-sdk/creating-an-admin-configuration-form/. I’ve created the form and added the following decorators:

<meta name="decorator" content="alt.admin">
<meta name="activeTab" content="checklist-system-settings-menu-item">

checklist-system-settings-menu-item is the ID of the web item that looks like this:

<web-item key="checklist-system-settings-menu-item" name="System Settings Menu Item"
              section="atl.admin/admin-plugins-section" weight="50">
        <label>My Plugin</label>
        <link>/plugins/servlet/my-plugin/admin</link>
        <tooltip>My Plugin Global Settings</tooltip>
</web-item>

The first problem is that the page is not rendered with the surrounding admin page content, it just looks like a very plain form with a white background. Additionally, resources that I’ve configure to be bundled with this page are also not delivered to the front end. I’ve created other servlets and web items to show custom pages in other contexts in the same application and those work fine. Is there something different about an admin page I should be aware of?


#2

The code you’ve shared here all looks fine to me, so I suspect the problem is somewhere else.

Given that tutorial is based on the refapp, it won’t start Bitbucket Server, and won’t have the same decorators available. Do you think that could be the issue?

You might rerun the steps but instead of writing atlas-create-refapp-plugin at the command-line, run atlas-create-bitbucket-plugin. The other steps generally apply - I believe the only real difference is in the pom.xml it generates, but I could be wrong there.

Otherwise, you might look at whether you’ve put the meta tags in the <head> or somewhere else.

As far as “resources that I’ve configure to be bundled with this page are also not delivered to the front end”, are you referring to code like $webResourceManager.requireResource("com.atlassian.auiplugin:ajs") form the tutorial? Would be good to understand what you wrote there. The pattern is plugin key - colon - resource key like your.plugin.key:web-resource-key. Plugin key is ${project.groupId}.${project.artifactId} by default if you haven’t changed it.

Hope that helps!

Cheers,
Adam


#3

I should say that I’m using that tutorial loosely as a guide, I’m not developing against the ref app. I’m developing against bitbucket. The entirety of the <head> tag in my soy template looks like this:

<head>
        <meta name="decorator" content="alt.admin">
        <meta name="activeTab" content="checklist-system-settings-menu-item">
        <title>System Settings</title>
</head>

Some random forum posts I read online from 2013 said that instead of “activeTab” the name in the meta tag should be “admin.active.tab” but I tried that and that didn’t change anything. Perhaps when the admin UI actually renders the active tab won’t be displayed properly unless I pick the right one but I digress…

I’m not using velocity templates so the $webResourceManager.requireResource("com.atlassian.auiplugin:ajs") doesn’t work at all. Instead I’m using the following line in my servlet to require some resources:

pageBuilderService.assembler().resources().requireWebResource("my.plugin.key:system-settings-resources");

where “system-settings-resources” is a web resource that looks like this:

<web-resource key="system-settings-resources" name="repository settings resources">
        <dependency>com.atlassian.auiplugin:ajs</dependency>

        <resource type="download" name="pr_checklist.js" location="/js/pr_checklist.js"/>
        <resource type="download" name="images/" location="/images"/>
</web-resource>

Like I said, this pattern has worked perfectly fine in other parts of my application. I’m able to render custom views in repository settings, project settings, and the pull request view page and they all have the correct UI rendered around them. For some reason the admin rendering is having issues so the alt.admin decorator doesn’t seem to be working. I imagine I need to handle that a little differently but I don’t know how.


#4

Turns out this was all just a spelling mistake alt.admin vs the correct atl.admin. Sad.