As a Marketplace app vendor, we use the vendor portal frequently in the general course of running our business.
Because of this, we have been gathering a list of small annoyances (paper cuts) that we think would be nice, quick (hopefully) quality-of-life wins for us and potentially other vendors.
Below is this unsolicited feedback.
Layout shift on the Marketplace landing page
The vendor portal page is located at https://marketplace.atlassian.com/manage/vendors/{vendorid}
Although we could (and probably should) simply bookmark that URL, most of us instead go to marketplace.atlassian.com, click the avatar at the top right, and choose “Manage partner account”, which opens the vendor portal in a new browser tab.
The annoyance here is that when you land on the public Marketplace landing page (marketplace.atlassian.com) if you are already authenticated, after ~1-2 seconds a grey “Partner Links” banner slides down from the top, pushing the rest of the normal Marketplace landing page down.
This generally happens around the exact time the user is about to click their avatar, which unhelpfully slides down from under the mouse pointer.
It would be great if this layout shift could be avoided.
Steps to reproduce:
- Go to marketplace.atlassian.com
- Authenticate as a Marketplace partner
- Refresh the landing page
- Observe that the grey “Partner Links” banner slides in a couple of seconds later, causing layout shift
Versions page for an app always defaults to Cloud
The dropdown on the page https://marketplace.atlassian.com/manage/apps/{appid}/versions defaults to Hosting type: Cloud, which lists the Cloud versions of an app. This is a sensible default, given Cloud is the future, and DC/Server are going/have gone EoL.
However, as vendors still supporting customers on DC, we regularly need to view and manage DC versions.
After changing the dropdown to Hosting type: Data Center (or even Hosting type: Server), anything that refreshes the page reverts to Hosting type: Cloud.
It would be great if changing the Hosting type dropdown would update the URL so that refreshing the page keeps you on the same hosting platform. Refreshing the page is common, particularly when waiting on approval of a newly uploaded app version.
An example of a possible URL change (query param): https://marketplace.atlassian.com/manage/apps/{appid}/versions?type=datacenter
Steps to reproduce:
- As a Marketplace vendor, go to the https://marketplace.atlassian.com/manage/apps/{appid}/versions for an app in your portfolio
- Change the dropdown to
Hosting type: Data Center - Refresh the page
- Observe that the dropdown reverts to
Hosting type: Cloud
Uploading a new version offers Server when server is no longer supported
When uploading a new DC version, the publishing workflow lists a “Compatible Atlassian apps” section, and offers both Data Center and Server:
As such, every new version of our app has always had both DC and Server versions even though Server has long gone EoL.
Recently though, we started getting an error popup when we attempted to proceed to the next screen:
Version creation failed
Server hosting disabled for appKey:
This in itself is unsurprising. We expected at some point Atlassian would stop the ability to publish new Server versions.
What is surprising, though, is that the publishing screen still offers both platforms, and we need to click that little trash can icon next to the server line before we can proceed.
If Server hosting is disabled as the error message says, could we omit Confluence Server as a compatible app when uploading new versions? Otherwise we’re forced to click that trash icon every time we publish.
Steps to reproduce:
- Go to https://marketplace.atlassian.com/manage/apps/{appid}/versions for a Confluence app in your portfolio
- Click Create Version
- Upload an app artifact
- Observe that both DC and Server are listed as compatible apps
- Try to proceed and observe an error indicating server hosting is disabled (note that whether you can proceed or not may be app specific, as per the error message above)
- Click the trash icon next to the Server row
- Try to proceed and observe that the error no longer appears
Latest version shown on the Marketplace listing is the most recent version uploaded, not the highest version number
Due to breaking changes introduced in Confluence 10.x (“platform 7”), we publish two versions of our Confluence apps: one that targets Confluence 8.x-9.x and one that targets Confluence 10.x and above.
Each release line uses a different app major version:
- Versions of our app that support Confluence 8/9 are
4.x - Versions of our app that support Confluence 10/11 are
5.x
Historically we published the 4.x release first, followed by the 5.x release.
Recently we swapped our repo’s default branch, and our release workflow now publishes the 5.x release first and the 4.x release second.
In the versions page, this means that the “top” version in the list is 4.x and the second one is 5.x
On the app’s Marketplace listing, the “Version information” panel at the bottom right seems to only show whatever is the “top” version in the version list (regardless of whether that is semantically the “highest” version). Our most recent versions are 5.4.2 and 4.9.2, and ideally we would want the 5.x version shown in the listing, not the 4.x version (even though the 4.x was technically published later).
The ask here is that the Version information panel uses semver to determine which version to show, OR allow us to reorder the version list in the vendor portal to control which version is at the “top”.
Steps to reproduce:
- Upload two new versions of an app, with different major version numbers (e.g.
5.x, followed by4.x) - Observe that the last version uploaded (
4.x) is listed as the “top” version - Observe on the Marketplace listing, under “Version information” that the
4.xversion is displayed, despite not being (semantically) the highest version published
Promotions page defaults to Cloud
This is a similar issue to the versions page.
Initially filtering the list of promos to Cloud makes perfect sense. However when creating a promotion for DC, after saving the promo you land back on the list showing only Cloud promos.
After changing the filter to show DC promos, a green banner appears showing the new promo just created.
It would be ideal if the green banner appeared immediately without having to first change the filter from Cloud → DC. Generally the thing that happens immediately after creating a promo is to issue one or more codes for that promo, so having the banner appear regardless of what the filter is would save a few clicks.
Steps to reproduce:
- Go to https://marketplace.atlassian.com/manage/vendors/{vendorid}/promos
- Observe that “Cloud” is selected, and only Cloud promos are listed
- Click Create Promotion
- Set Deployment to “Data Center” and finish creating the promo
- Observe that you land back on the Cloud promos list
- Change the filter to “Data Center”
- Observe a green banner appears showing your new promo (this should appear immediately at step 5, in our opinion)
Promotion data model
Speaking of promos, the data model doesn’t really work well for our use case.
We receive frequent requests from customers and solution partners asking for a discount around their renewal time.
In each case, we create a new promo naming the customer (e.g. “Acme 10% Discount”), and set the deployment, app, discount amount & timeframe to align with that customer’s license expiry (with some wiggle room).
Often, the promo code expires before the customer gets to use it (for a variety of reasons - e.g. procurement is held up), so they come back and ask for a new promo code, and we have to create an entirely new promo with a new expiry.
In our view, expiry should (optionally ) be linked to the promo code, not the promo itself. Additionally, being able to name a code would enable us to create one promotion (e.g. “10% Discount”), and then issue unique codes each with their own expiry for different customers.
If a customer needs a new code because their one expires, we just issue a new code and not have to create an entirely new promo.
We don’t want to use “generic” promotion types where all customers use the same code, as we want to track who has used their code, and also prevent codes from being shared; but equally having to create a whole new promotion just to reissue a code with an extended expiry is onerous.
Steps to reproduce:
- Create a promotion with an expiry of today
- Issue a promo code for that promo
- Now imagine that the customer that code was issued to comes back tomorrow and asks for a new code because their old one expired
- To reissue an new code, you need to recreate the whole promotion
Conclusion
Some of these issues seem like they could be solved quite easily with just a little bit of attention paid to the vendor management tools.