This question is in reference to Atlassian Documentation: Add-ons and plugins
If I have a Cloud instance of JIRA, can I import a connect add-on that resides on a private network? I don't want to have to have an entry in the Marketplace for all the private instances of the target system.
Thank you, Petar..
The situation we have is that we have a product that our customers purchase which is only on-premise. But, many JIRA customers that want to use it are using JIRA Cloud. So, we want them to be able to display iframes inside of a JIRA ticket that are served from the on-premise product.
So, just to confirm what you're saying: in order for a Cloud customer to do that, they would have to enable development mode to point at something that is not itself listed in the Marketplace. Doing this would avoid the error message when trying to import the connect JSON file?
I still say it would be better to use a private listing in the Atlassian marketplace. In the future "Enable development mode" might enable more than just the ability to install add-ons from other places. It could enable other development mode only features too.
Hi Robert ,
I agree with you - private listing is the better approach, but the question specifically included the condition of not listing on the marketplace.
Joshua, as Robert points above, you need only one listing per add-on, not per JIRA instance. If that works for you - yes, it's better to enable private listings, rather than development mode.
Not being "in the Marketplace" is not a requirement in and of itself.
However, we are under the impression that something in the marketplace can have a single baseUrl in the JSON file. As such, we would have to figure out a way to divert traffic that comes into that entry point to our own product that is running on an individual customer's on-prem network.
Does that make sense? One way we thought to do that would be to have a Configure step page that lets us save the JIRA cloud instance's instanceName.atlassian.net address to our middle-man server. When subsequent requests come in against our baseUrl/someRoute, then we could again read that instanceName and render the IFRAME panel by redirecting to the customer's on-prem servers that run our product.
But, maybe we're missing something? Are there other ways to go about this situation?
I work with Joshua, here is what we need phrased slightly differently.
We would like to host the plugin in multiple on premise instances of our product. The roadblock we face has to do with the baseURL needing to be static, and since we will have many instances of the plugin, we need the base URL to be more dynamic. It would be ideal if we could use a variable within the baseURL, and get the value of that varaible from the configuration page. For example
Variables for URL obtained from the configuration page:
<instanceName> = Instance1234
Is something like this possible? If not, we are considering creating a private plugin for every instance of our plugin. Is there a limit to the amount of private plugins one can have in the marketplace?
If you are serving multiple OnDemand instances with your plugin (even if its not going to be public) you are probably better off with a private marketplace listing. There is quite a bit that gets taken care of behind the scenes. It is easy to add new instances and, as Robert points out, you avoid putting a production instance into development mode which could have hidden consequences.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs