Inspiration

Sometime Jira admins needs plugins, which could be done in few lines of php code. For example - send pushbullet notifications each time issue changed.

In perfect world creating such a plugin would be executing simple php script each time issue changed. Something like

<?php
include "vendor/autoload.php";

$pb = new \Pushbullet\Pushbullet($pushbulletApiKey);
$pb->allDevices()->pushNote($issueKey." ".$issueSummary, $issueChangesSummary);

$console->log("Send notification to pushbullet ".$pushbulletApiKey."\n".$issueKey." ".$issueSummary."\n".$issueChangesSummary);

And creating simple configuration which will add pushbulletApiKey for each user and execute php script each time, when some user need to be notified. Something like YAML file

settings:
    user:
          -
              variable: pushbulletApiKey
              title: Pushbullet Api key
              help: Its used to send notifications. You can get it <a href='https://www.pushbullet.com/account' target='_blank'>in your account profile</a>
              required: true
webhooks:
    userNotifier:
          handler: sendNotification.php

In real world Jira admin will need to spend a lot of hours on digging into documentation and creating complex system before he will be able to execute even that simple php script.

Jira Webhooks will not work, because each Jira User will have own pushbullet account and each Jira User will need to store his API key somewhere.

Plugin builder make everything simple.

Plugin builder could take your php script and execute it each time issue is changed.

No need for deployment - public git repository with script would be enough. System will deploy your code automatically on your personal Amazon EC2 instance!

Plugin builder also provide common features for your scripts, like User settings interface and Console log.

If you are still confused - I have created tutorial Building your first plugin for Jira with Plugin Builder

Something more complex than "execute php each time when issue changed"

Hm... What about old Jira Core issue, which is too simple for "real" plugin and too anoying for leaving it AS IS? I am talking about JRA-7663 - Grant permissions to watchers, closed with "Will not fix" with 92 votes and 70 watchers.

Unfortunately, It cant be 100% fixed, because of Jira limitations.
But 20 lines of php code with Plugin Builder could simplify your life, if you have similar problem. Custom issue field would be automatically synchronized with watchers.

<?php
//$console->log($json);


if(array_key_exists("changelog",$json) && array_key_exists("items",$json["changelog"])) {
    foreach ($json["changelog"]["items"] as $changes) {
        if ($changes["field"] == 'Can see this issue') {
            // Format is [user-name-1, user-name-2]. You could use $jira->parseCustomFieldMultipleUsers($str) to get array of usernames
            $previousState = $jira->parseCustomFieldMultipleUsers($changes["from"]);

            $currentState = $jira->parseCustomFieldMultipleUsers($changes["to"]);

            $addedUsers = array_diff($currentState,$previousState);
            if(count($addedUsers)) {
                foreach ($addedUsers as $addedUserName) {
                    $jira->post("/rest/api/2/issue/".$issueKey."/watchers", $addedUserName);
                }
                $console->success("Done adding users ".implode(", ",$addedUsers)." to watch list for <a href='".$issueUrl."' target='_blank'>".$issueKey." ".$issueSummary."</a>!");
            }
            $removedUsers = array_diff($previousState,$currentState);
            if(count($removedUsers )) {
                foreach ($removedUsers as $removedUserName) {
                    $jira->delete("/rest/api/2/issue/".$issueKey."/watchers?username=".$removedUserName);
                }
                $console->error("Done removing users ".implode(", ",$removedUsers)." from watch list for <a href='".$issueUrl."' target='_blank'>".$issueKey." ".$issueSummary."</a>!");
            }
        }
    }
}

More details here - Plugin - JRA-7663 fix - Sync watchers with custom field

Why do I use git repositories for storing plugins instead of simple file upload?

I want to make it easy for Jira admins to share their plugins. In future PluginBuilder would have private repositories support, but right now - only public repositories are allowed.

Changing something similar is much more simple, as looking through huge documentation and trying to learn how to build "real" Jira plugin.

Do you want to get telegram notifications? Twillio SMS? Slack chat messages? Fork pushbullet plugin, add library for your system, deploy and enjoy! You could do it within 30 minutes while drinking mornings coffee!

Want to create something more complex? Just contact me and I will create script prototype for you!

Is it secure? What, if somebody will upload php shell? Do you limit php commands?

Yes, its 100% secure. You can access only your data.

And No. Php scripts have NO limits on Plugin Builder.

When you install plugin - new EC2 Amazon instance is created personally for you. Plugin Builder is located on independent instance and its not accessible for user's php script.

Jira doesn't connect to user's EC2 instance. When hook is send - its sent to PluginBuilder, which locate related instance and forward hook data to it with syntax sugar variables like $issueChangesSummary.

It makes system simple, secure and unlimited at the same time!

What about adding something to Jira UI? Like Google map widget with clients address on issue's sidebar.

Thats another use-case for plugin builder. Sometime Jira users want to show on issue page something, which is pretty simple to build using php. It could be some client's data from external CMS or even something interactive, like google map.

Adding new UI to Jira is a bit more tricky, its explained here - Enabling Jira UI integrations

Existing open sources plugins

You could get actual list from "Open sources plugins" tab on your PluginBuilder settings page. Right now I did

What's next for Plugin Builder for Jira Cloud

  • add more sample plugins
  • make plugin deployment asynchronous
  • bitbucket webhooks for automated plugin reloading
  • private git repositories support (via deploy keys), ability to pick git branch/tag
  • more Jira integration points
  • more helpers and samples
  • direct ssh access to amazon EC2 instance
  • ability to use own EC2 instance (more fast, connected with internal infrastructure)
  • automatically detect new public plugins and add them to showcase
  • online php editor with autocompletion. Probably, it would be ace editor
  • add ability to attach own ssl sertificate and load plugin content directly (it will decrease plugin load time)

Built With

Share this project:

Updates