
# Plugin Collaborativetools for GLPI
## Purpose
This plugin aims to provide connectors for web collaborative tools.
It currently push notifications to HTTP `incoming webhooks` for the following services:
### Mattermost

> #### Setup
> As a logged team administrator, go to the main menu and click on `Integrations` sub link, select `incoming webhooks`, add a new one, define a title and select a channel.
> After save, you will get the url of the webhook.
### Microsoft Teams

> #### Setup
> You need to add a `connector` on your channel (by right clicking on it), select `Incoming Webhooks`, set a name and add optionnaly an image.
> After save, you will get the url of the webhook.
### Rocket.Chat

> #### Setup
> As a logged team administrator, go to the administration menu and click on `Integrations` menu item. Click on the `New integration` button, select `incoming webhooks`, and define webhook parameters.
> After save, you will get the url of the webhook.
### Slack

> #### Setup
> You need to add an `application` to your team (the link is present in the bottom of the left side bar) and select `incoming-webhook`.
> Add a new configuration, select the channel where you want notifications and you will get the webhook url.
> You can optionally setup a name and a logo for your hook.
### Telegram

> #### Setup
> First you need to create a `Telegram bot` by talking to `@BotFather` inside Telegram. You will get an API token corresponding to this bot. The webhook URL will be `https://api.telegram.org/bot<token>`.
> Then you need to add this bot, as an administrator, on the channel where you want notifications.
> Telegram API requires an additional parameter, called `chat_id`, that corresponds to your channel id. To get it, forward any message from your channel to the `@getidsbot` bot and get the id value of the `forward_from_chat` message property.
## GLPI Setup
After installing and enabling Plugin in `Setup > Plugins`, you will find a new entry in `Setup > Dropdowns` labelled `Collaborative tools > Webhooks`.
You can define here the list of your services' webhooks.
When adding one, paste the url you got in the specific setup of the service.
After this, go to `Setup > Notifications`, then:
- Set `Enable webhooks notifications` to Yes
- You can test the hook in `Webhooks notifications configuration` sub menu
- In a notification (like new ticket):
- add a new link to a existing template with `webhook` mode
- set recipients (you will find the dropdown you defined previously)
- You are done
> **Important**
> The webhook notifications pass through the notification queue like emails one, so make sure the automatic action for send notification in queue is active and functionnal.
> **Notification Models**
> The above services take into input very simple HTML.
> We recommend to set new and distinct notification templates from emails one.
> Keep it simple!
## Screenshots



## Notification / WebHook / Target: explanation
This documentation is intended to explain the different ways of sending notifications according to the targets of the webhooks and the recipients of the notifications
## Collaborative tools settings
In this documentation we will use two different webhooks
### Webhook A (without user target)
This first webhook does not use any targets

### Webhook B (with user target)
This second webhook defines the user ```tech``` as the target.

## Use Case 1
The **New user in assignees** notification defines as a recipient **only**:
* Technician in charge of the ticket

### User assigned is defined as recipients and as target
Assigning user ```tech``` as a technician on a ticket will have the following behaviour:
:::success
Even if the ```Webhook B (with user tech as target)``` is not declared in the list of recipients of the GLPI notification, it is still triggered by the plugin, because the recipient (```tech``` user) corresponds to the defined target.
:::
:::danger
The ```Webhook A (without user target)``` is not triggered
:::
### User assigned is defined as recipients and as target
Assigning user ```tech 2``` as a technician on a ticket will have the following behaviour:
:::danger
```Webhook B (with user tech as target)``` is not triggered because ``` user != target```.
:::
:::danger
The ```Webhook A (without user target)``` is not triggered
:::
## Use Case 2
The **New user in assignees** notification defines as a recipient:
* Webhook A (without target)
* Webhook B (with target)

### User assigned is defined as recipients and as target
Assigning the ```tech``` user as a technician on a ticket will have the following behaviour:
:::success
```Webhook A (without user target)``` is triggered
:::
:::success
```Webhook B (with user tech as target)``` is triggered
:::
### User assigned is defined as recipients but not as a target
Assigning the ```tech 2``` user as a technician on a ticket will have the following behaviour:
:::success
```Webhook A (without user target)``` is triggered
:::
:::success
```Webhook B (with user tech as target)``` is triggered even if ```user != target```
:::
## Use Case 3
The **New user in assignees** notification defines as a recipient :
* Webhook A (without target)
* Webhook B (with target)
* Technician in charge of the ticket

### User assigned is defined as recipients and as target
Assigning the ```tech``` user as a technician on a ticket will have the following behaviour:
:::success
```Webhook A (without user target)``` is triggered
:::
:::success
```Webhook B (with user tech as target)``` is triggered because :
* the user assigned to the ticket **is** the recipient of the notification
* the user assigned to the ticket **is** the target of the webhook
:::
### User assigned is defined as recipients but not as a target
Assigning the ```tech 2``` user as a technician on a ticket will have the following behaviour:
:::success
```Webhook A (without user target)``` is triggered
:::
:::danger
```Webhook B (with user tech as target)``` **is not triggered** because :
* the user assigned to the ticket is the recipient of the notification
* the user assigned to the ticket **is not** the target of the webhook
:::
[[toc]]