chemaclass/jirastatusnotifier

Notify via Slack|Email when the JIRA-tickets doesn't move along

Jira Status Notifier

This tool will notify the person assigned a JIRA-ticket if the ticket remains in the same status for more than N days.

Installation as vendor

Using composer: composer require chemaclass/jira-status-notifier

Development and contribution

Requirements: PHP >=8.0

1. Fork and clone
2. composer install

Composer scripts

composer test-all -> quality, phpunit
composer quality  -> csrun, psalm, phpstan
composer phpunit  -> test-unit, test-functional

See more in composer.json

Documentation

• Using Slack as notification channel
• Using Email as notification channel
• Using Cli to render the tickets for each assignee without notifying anybody

Basic Example

$facade = new JiraStatusNotifierFacade();

$result = $facade->handle([
    CliChannel::class,
    SlackChannel::class,
    EmailChannel::class,
]);

$facade->renderOutput($result);

jirastatusnotifier's Issues

Install Twig

In order to split concerns, let's try out a render engine like Twig to render the views in another place, not mixed with the PHP logic.

https://twig.symfony.com/doc/3.x/intro.html#installation

Use Makefile instead of "bin/helpers"

Current behavior

There are plenty of "helper files" inside the bin directory. We could define certain tasks in a Makefile, so we could trigger them by just calling "make {task}" instead.

Acceptance criteria

• Implement a Makefile like https://github.com/Chemaclass/php-scaffolding/blob/master/Makefile
• Remove all unnecessary files from bin directory

Allow notifications via email

Current behavior

Currently, the notifications go always to Slack.

We should allow notifications to the email from the JIRA user.

Acceptance Criteria

Create a Channel which will send an email to the assigned person email with a specific template (not necessary the same template as the slack message).

tips

• use https://swiftmailer.symfony.com/docs/introduction.html to send emails via PHP

Make the KEY to get the Story Points from the Tickets customizable

Current behavior

Currently, the Tickets::FIELD_STORY_POINTS key has a constant string value which might be different from other companies or projects. This is the key that we use in order to get the story point value from the API response.

namespace Chemaclass\ScrumMaster\Jira;

final class Tickets
{
    public const FIELD_STORY_POINTS = 'customfield_10005';

    // ... more code

    private static function newJiraTicket(array $item): JiraTicket
    {
        $fields = $item['fields'];

        return new JiraTicket(
            $fields['summary'],
            $item['key'],
            static::newTicketStatus($fields),
            static::newAssignee($fields['assignee'] ?? []),
            $storyPoints = (int) $fields[self::FIELD_STORY_POINTS] // <--- Here!
        );
    }
    // ... more code

We should be able to define this key somehow in order to get rid of this constant. A possible solution might be injecting its value via the constructor.

Acceptance Criteria

• Get rid of Tickets::FIELD_STORY_POINTS as a contant. Instead make this value customizable from the outside. The client (see the using examples console files) needs to be able to define this key to whatever value they want.

Create a channel to only retrieve the information

Write a "Channel" to only retrieve the information without sending any notification

Remove Makefile. Use composer scripts instead.

Description

Instead of having the Makefile alias, use the composer scripts.

Even for development, in our case, Makefile doesn't really bring any extra value having already. composer scripts.

Acceptance Criteria

• Move the Makefile commands to the composer.scripts in composer.json
• Update the README.md file

Make the PR/pipeline fail if the php_cs fails

We already have php-cs-fixer in place. In fact, we can just run bin/csfix to run and apply the fixer in the hole project.

We should find a way to make red/fail the PR/pipeline, so it can't be merged until the styles are fixed.

Update to PHP 7.4 (Beta)

• Update docker to use the beta from PHP 7.4
• Use the new features form PHP 7.4

Get the number of days that the tickets belong to their current status since their last status change

Description

I would like to know how long remain every Jira ticket, from the current sprint, since their last status change.

Be capable of running some commands from local and docker

Currently, bin/composer, bin/csfix and bin/tests are running only from local: they exec docker and run the proper command inside.

What we need is that inside each of these files we will check if we are already inside the docker image, and in affirmative case avoid the docker exec... part and just run the command.

Display "None" when some people is not assigned to a JiraTicket

Current behavior

Currently, while running the examples/using-cli-channel, when nobody is assigned to a JiraTicket then it will render nothing.

Acceptance Criteria

We should render "None", instead of nothing.

Use Twig for email rendering

Current behavior

Currently, we generate the email template directly in src/ScrumMaster/Channel/Email/MessageGenerator.php.

We already installed twig, and use it in the output example.

Acceptance Criteria

• Use Twig inside the MessageGenerator (or similar).
• Decouple the logic from the rendering.

Use Twig for slack messages

Currently

We generate the slack message using pure PHP code.

Acceptance Criteria

Like we did for email here #46 (use twig for rendering the email body), I would like to use the same idea for the slack notifications as well.

Render proper ticket keys depending on the response status

Current behavior

The command outputs the total of notifications that were sent out. For example:

Total notifications: 3 (KEY-1, KEY-2: user.1, KEY-3: user.2)
Total successful notifications sent: 2
Total failed notifications sent: 1

Expected behavior

The command should output the successful AND failed "ticket-keys" as well. For example:

Total notifications: 3 (KEY-1, KEY-2: user.1, KEY-3: user.2)
Total successful notifications sent: 2 (KEY-1, KEY-2)
Total failed notifications sent: 1 (KEY-3)

Technical considerations

• A successful notification is when the response.status is 200
• A failed notification is when the response.status is not 200

Instead of SwiftMailer use SymfonyMailer

https://symfony.com/doc/current/components/mailer.html

Display the user.key next to the jira_ticket.key

Current behavior

The command outputs the total of notifications that were sent out with the Jira ticket keys next to it. For example:

Total notifications: 3 (KEY-1, KEY-2, KEY-3)

Expected behavior

The command should output the assigned user (user.key from Jira) next to each Jira-Ticket key. For example:

Total notifications: 3 (KEY-1: jira.user.1, KEY-2: jira.user.1, KEY-3: jira.user.2)

Add env variable to ignore send notifications to some certain users

Create some logic which by placing a list of users (Jira user ids) these users will be ignored in order to send them any notification. This is a useful feature to avoid unnecessary spam to people who's out of the office/workingTime for any reason (working student free day, sick leave for X days, etc).

Proposals:

IGNORE_JIRA_USERS:{"jira.user.id":false}

or maybe just a list for now like:

IGNORE_JIRA_USERS:["jira.user.id"]

Send unique notification via Slack per user

Current behavior

We send one ticket information as a notification (via slack) per ticket

Similar as we did in the issue #28, let's do the same idea-feature for Slack\Channel: send only one message per user. The message should contain information from all the tickets.

A project has one board. A board has multiple statuses. In the status-board, we can find multiple tickets.

Acceptance Criteria

• Send only one message/notification per user with all ticket information that the user should be aware of.