January 25, 2018 at 14:39Telegram bot for Redmine. How to simplify life for yourself and people
In any company that uses a project and task management system, sooner or later there is a desire to combine it with some popular messenger to simplify communications. Especially if there is interaction with customers through this system.
The article will discuss how to make Redmine friends with Telegram and not break existing business processes.
A little background on how the idea of a subject was born.
Our company is engaged in the administration of servers and sites 24/7, the development of infrastructure for large and growing Internet projects, the design of fault-tolerant systems and the automation of DevOps.
To interact with customers, we use Redmine, which we have tuned into our processes and hung on it a number of pleasant things that make our life easier.
Even when we just started, it was in 2011, we decided that we would conduct communications with customers only through our task tracker. This is due to the fact that in addition to supporting servers and responding to incidents, most of our work consists of infrastructure development tasks. It is important for us at any time to well understand the current state of infrastructure, the vector of development of the project, correctly assess needs and bottlenecks, propose solutions, coordinate them and implement them. The matter is complicated by the fact that there are many projects, not one person is working on each, but a team of administrators. At the same time, administrators work in shifts, some of them may not always intersect with each other in the office, and tasks need to be done. Therefore, the issue of synchronization of knowledge and actions within the team and between shifts is extremely important for us.
Given all these factors, we decided that the only possible way to keep the situation under control is to make sure that all communications and all work takes place in one place - in the task system. Naturally, we run the project wiki and do much more to solve the problem of synchronizing actions and context, but the key point has always been a single point of interaction with customers. If you add another channel to the communications, for example, instant messengers, for example, to quickly discuss some issues, 100% of customers will begin to abuse it, we will quickly drown in the abyss of endless comments, and important information will simply begin to get lost. Yes, and administrators the prospect of chaotic communication with customers in 5 different windows against the tasks laid out in Redmine, laid out for clear business processes, to put it mildly, was not attractive.
As a result, we lived like that for about 5 years. During this time, many customers loved our Redmine, its simplicity and functionality. Someone, having worked with him with us, decided to introduce it in his company. Only occasionally did individual clients ask whether it is possible to set tasks for us not only through the system of tasks, but also through some kind of messenger, because that would be more convenient.
But over the past 2 years, the number of such requests has increased significantly. So much so that it was impossible not to take them into account. And once again we thought about what to do with this. Sales managers, as usual, tried to push the idea in some miraculous way to integrate communication with customers via Skype, WhatsApp or Telegram into our work processes. Administrators flatly did not want this.
After heated debate and discussion, we had the idea to develop a Telegram bot that would allow all client messages to be laid out according to existing tasks in Redmine or create new ones where administrators will work with them in their usual environment.
They put together a small plan - at first minimal functionality, then pleasant trifles. After some time, we got a prototype of the future bot, which successfully delivered the message it wrote from Telegram to Redmine, and vice versa! This gave confidence that the idea was viable. And we made every effort to bring it to the end and launch it.
In order to better explain how all this works, the article is divided into two blocks. The first block contains a general description of the bot and examples of its operation. In the second - the device and technical aspects of the bot.
At the end of the article are links where to download and how to configure our bot.
So what did we get?
Firstly, for the user to be able to work with the bot, it needs to be authorized.
To do this, the user must have an active Redmine account.
He needs to come up with a username and register it in the settings of his Telegram account:
The same username must be entered in the settings of the Redmine account in a special additional field “Telegram”:
Next, the user finds the bot in Telegram and clicks Start. The bot authorizes it and welcomes:
In order to pose a new task or add a comment to an existing task, just write a text to the bot and it will offer options. At the same time, you can attach files to the message: You
can add a written comment to the last active task, select a task from the list, create a new task based on it, or do nothing and end the dialog.
When you select the "Add to last task" item, the user's comment will be added to the task for which the last correspondence was conducted. The bot shows it above.
If you select "Create a new task", the bot will switch to the mode of creating a new task:
And offer the user:
Пользователь может пропустить эти шаги, если его устроят дефолтные значения, и сразу нажать «Создать задачу», потребуется только указать для неё заголовок:
После этого бот уведомит клиента о создании задачи (ссылка на задачу кликабельна и по ней при необходимости сразу можно будет перейти в тикет):
Которая в Redmine будет выглядеть следующим образом:
Если же пользователь нажал на «Выбрать задачу» — бот предложит список открытых на текущий момент задач, в которые можно отправить написанный комментарий:
При этом пользователь видит только те проекты и задачи, к которым он подключен в Redmine. Это относится ко всем действиям в боте.
The bot supports the delivery of notifications of changes in tasks. For example, our administrator has completed the task and asks the client to check the result:
Here is what the client will receive: You can
answer the tasks through Reply to the corresponding message in Telegram. This is especially convenient when work is being done on several tasks at once (the answer will immediately go to the desired ticket without additional questions):
Summary. The client created a task, communicated on it, and did all this through Telegram. He never had to go to Redmine for this. The employee received and processed the task in the usual way in Redmine, as part of standard business processes, he did not have to switch to the messenger, and then take care of transferring the correspondence to the task system.
In the bot, we implemented support for attachments. And it works both ways. You can attach anything you like: photos, documents, video and audio. You can even attach stickers, though they look so-so in the browser, but it’s a pity, sometimes a perfectly selected sticker extends the life of our entire office.
Let's say a monitoring system informed us of a problem on one of the servers. The administrator created a task through Redmine and attached a graph of the monitoring system to it. The client will receive the following message:
To which he can respond with a voice message:
A voice message will be delivered to the task and listened to by the administrator.
Of course they are. We encountered the following:
A little over two months have passed since the launch. First observations:
So, let's start ... The
basic scheme of the bot is as follows:
It seems nothing complicated - all the changes in Redmine are delivered to the bot using hooks, it looks at the type of event in which project it happened, determines the Telegram accounts of the recipients of this message and delivers them. From the side of Telegram, everything happens in a similar way - the type of message is determined, what task it relates to and delivered to Redmine.
Now let's add a little action and get acquainted with some features of message delivery in Telegram!
Telegram splits large messages into several small ones. These messages come with some delay. All attachments are delivered as separate messages and sometimes with a long delay (as the user downloads them). Those. you can’t just take and forward all received messages, otherwise we will spam users and spoil our karma.
And what to do? We decided to create message queues for this and use Redis to store them. Our bot queues each incoming message and updates the delay time for its processing. When this delay has expired, we believe that the message is fully formed and now you can select a task and send it to Redmine.
Then the question arises: how to choose the right task in Redmine? Indeed, in order for the bot to understand what to do with the received data, it needs to ask the user about it, and this, anyway, is another message (even if it is a button click) and it needs to be somehow connected with previous user actions. This session will help us.
The first message received from the user's Telegram account - generates a session that contains:
Each subsequent message received from Telegram can either supplement the session with data, or change its state (for example, start the process of further processing and delivery of data), or destroy the session (for example, if the user changes his mind to write his comment), or lead to an error (for example, if the type of data received does not correspond to the current state of the session).
Another important element of the bot is caching. Our Redmine consists of a fairly large number of projects, users and some other data. The bot often needs to access this data, and if it will follow them every time in Redmine, this will lead to noticeable delays in processing requests.
The bot has a separate process that is only concerned with periodically retrieving from Redmine the data required for the rest of the processes and storing it in Redis.
What about MySQL?
It was noted above that in addition to Redis, the bot also uses MySQL. Of course, all the data could be stored in Redis, but despite the presence of periodic dumps - the data is still stored in memory and an unexpected crash in the system can lead to their loss, and among them there is very important information that needs to be treated with particular care. To better understand what is at stake, we recall the first part of the article. It said that the user can not only choose from the dialogue with the bot what to do with his message (create a new task or select an existing one), but also make a response to the message. And the bot must understand what task you need to add it to.
In Telegram, messages have identifiers that have nothing to do with task identifiers in Redmine. In order to make them friends, you need to establish some kind of correspondence and decide how to store this data. But before that, let's try to understand how this data is formed, what will happen if this data is lost and, based on this, to understand their importance.
Suppose a user writes his first message in a Telegram bot. The bot opens the session and finds out from the user what task you need to add a comment to. After the answer is received - the bot sends the data to Redmine and at the same time saves this correspondence at home.
Further, when the user makes a reply to this message in Telegram, the bot will receive the number of the “parent” message and determine the number of the Redmine task to which the comment should be sent. The described correspondence will also be established for this new message, i.e. reply can then be done on it. The same is true for events coming from Redmine. Our clients believe that this is a very convenient mechanism and, judging by the statistics, they use it very actively.
Now let's imagine that we have lost all these correspondences. Those. the client, as a matter of habit, clicks reply to the message that came from the administrator, writes his comment and sends it to the bot. But since the bot according to the described algorithm is no longer able to understand what task to send a comment to, it will give an error message and ask additional questions in order to find out what to do next.
Other important types of data that cannot be lost (and they cannot be lost even more than the first ones) are the correspondence of Redmine and Telegram user IDs. If this does happen, then users will simply stop receiving information about events taking place in Redmine until they write something to the bot. And since According to polls, the bots are almost more often used as a notifier (to replace mail), then here we can get even more trouble.
In order not to upset users, we put this data into a less fast but more reliable MySQL.
In fairness, it is worth noting that our team is still arguing about whether to abandon MySQL and transfer this data to Redis. Therefore, it is possible that in the future we can completely switch to working with Redis, and maybe even to some other storage system. Fortunately, the architecture of our application makes such replacements relatively simple.
Now I would like to talk about how to ensure the scaling and fault tolerance of the bot ...
With the advent of the bot, our Redmine in some cases turned into a chat and the intensity of messaging is constantly growing. Some of our customers also want to integrate it into their infrastructure. And given the fact that our development is completely open source, it is not known what other company or team of administrators / developers wants to use it and it is not known what loads the bot will encounter. Therefore, even at the stage of project development, we laid the possibility of scaling in it.
In our project, scaling can be divided into two classes:
To understand how the bot can be scaled, let's take a closer look at the process of receiving and processing messages.
The schematic diagram is as follows:
The only task of the “Rest API” process is to put a message received from Redmine or Telegram into a ra-queue and wait for the next. This queue is constantly monitored by the Queue-workers processes, and when data appears in it, they are read.
Messages from Redmine are immediately processed and sent to the right users in Telegram. With events from Telegram, everything is more complicated. Because they cannot be sent immediately to Redmine (the reasons are described above), then they are transferred to another queue, already broken down by users. The type of message determines the time during which we wait for other messages. Sooner or later, all these messages are read, undergo preliminary preparation, in one way or another change the state of the session and can be sent to Redmine with all the attached files that are downloaded from Telegram at the same step.
It is important to note here that thanks to this approach and the existing locking mechanism, processing always occurs on one specific node. This is what allows you to create as many bot instances with as many Queue-workers processes as necessary within the existing load.
When Redmine receives a message, a hook is triggered and the same message is sent back to the bot, after which it is delivered to the rest of the Telegram accounts subscribed to the task.
Thus, the infrastructure of the bot in a distributed version can be represented as follows:
But everything described does not limit the ability to use the bot in the usual standalone version with one MySQL server and the usual non-clustered version of Redis.
To demonstrate the work of the bot, we made a demo version, available at demo.nxs-chat.nixys.ru .
To try it in action, you need to follow a few preliminary steps:
Important notice! The bot will send messages to Telegram in the following cases:
The bot is completely open and can be obtained both in the form of source codes and as a package (packages are currently available only for Debian 8, but will be available for Debian 9 and CentOS 7 in the near future).
Link to the Github repository with bot source codes . There is also an instruction for installing a bot from packages and setting it up.
In the near future we plan to add the following functionality:
The article will discuss how to make Redmine friends with Telegram and not break existing business processes.
A little background on how the idea of a subject was born.
Our company is engaged in the administration of servers and sites 24/7, the development of infrastructure for large and growing Internet projects, the design of fault-tolerant systems and the automation of DevOps.
To interact with customers, we use Redmine, which we have tuned into our processes and hung on it a number of pleasant things that make our life easier.
Even when we just started, it was in 2011, we decided that we would conduct communications with customers only through our task tracker. This is due to the fact that in addition to supporting servers and responding to incidents, most of our work consists of infrastructure development tasks. It is important for us at any time to well understand the current state of infrastructure, the vector of development of the project, correctly assess needs and bottlenecks, propose solutions, coordinate them and implement them. The matter is complicated by the fact that there are many projects, not one person is working on each, but a team of administrators. At the same time, administrators work in shifts, some of them may not always intersect with each other in the office, and tasks need to be done. Therefore, the issue of synchronization of knowledge and actions within the team and between shifts is extremely important for us.
Given all these factors, we decided that the only possible way to keep the situation under control is to make sure that all communications and all work takes place in one place - in the task system. Naturally, we run the project wiki and do much more to solve the problem of synchronizing actions and context, but the key point has always been a single point of interaction with customers. If you add another channel to the communications, for example, instant messengers, for example, to quickly discuss some issues, 100% of customers will begin to abuse it, we will quickly drown in the abyss of endless comments, and important information will simply begin to get lost. Yes, and administrators the prospect of chaotic communication with customers in 5 different windows against the tasks laid out in Redmine, laid out for clear business processes, to put it mildly, was not attractive.
As a result, we lived like that for about 5 years. During this time, many customers loved our Redmine, its simplicity and functionality. Someone, having worked with him with us, decided to introduce it in his company. Only occasionally did individual clients ask whether it is possible to set tasks for us not only through the system of tasks, but also through some kind of messenger, because that would be more convenient.
But over the past 2 years, the number of such requests has increased significantly. So much so that it was impossible not to take them into account. And once again we thought about what to do with this. Sales managers, as usual, tried to push the idea in some miraculous way to integrate communication with customers via Skype, WhatsApp or Telegram into our work processes. Administrators flatly did not want this.
After heated debate and discussion, we had the idea to develop a Telegram bot that would allow all client messages to be laid out according to existing tasks in Redmine or create new ones where administrators will work with them in their usual environment.
They put together a small plan - at first minimal functionality, then pleasant trifles. After some time, we got a prototype of the future bot, which successfully delivered the message it wrote from Telegram to Redmine, and vice versa! This gave confidence that the idea was viable. And we made every effort to bring it to the end and launch it.
In order to better explain how all this works, the article is divided into two blocks. The first block contains a general description of the bot and examples of its operation. In the second - the device and technical aspects of the bot.
At the end of the article are links where to download and how to configure our bot.
So what did we get?
User Authorization
Firstly, for the user to be able to work with the bot, it needs to be authorized.
To do this, the user must have an active Redmine account.
He needs to come up with a username and register it in the settings of his Telegram account:
The same username must be entered in the settings of the Redmine account in a special additional field “Telegram”:
Next, the user finds the bot in Telegram and clicks Start. The bot authorizes it and welcomes:
Setting goals
In order to pose a new task or add a comment to an existing task, just write a text to the bot and it will offer options. At the same time, you can attach files to the message: You
can add a written comment to the last active task, select a task from the list, create a new task based on it, or do nothing and end the dialog.
When you select the "Add to last task" item, the user's comment will be added to the task for which the last correspondence was conducted. The bot shows it above.
If you select "Create a new task", the bot will switch to the mode of creating a new task:
And offer the user:
- Select a project (optional, if you did not arrange a default):
- Specify the priority of the task (optional, if the default does not work):
Пользователь может пропустить эти шаги, если его устроят дефолтные значения, и сразу нажать «Создать задачу», потребуется только указать для неё заголовок:
После этого бот уведомит клиента о создании задачи (ссылка на задачу кликабельна и по ней при необходимости сразу можно будет перейти в тикет):
Которая в Redmine будет выглядеть следующим образом:
Если же пользователь нажал на «Выбрать задачу» — бот предложит список открытых на текущий момент задач, в которые можно отправить написанный комментарий:
При этом пользователь видит только те проекты и задачи, к которым он подключен в Redmine. Это относится ко всем действиям в боте.
Переписка по задачам
The bot supports the delivery of notifications of changes in tasks. For example, our administrator has completed the task and asks the client to check the result:
Here is what the client will receive: You can
answer the tasks through Reply to the corresponding message in Telegram. This is especially convenient when work is being done on several tasks at once (the answer will immediately go to the desired ticket without additional questions):
Summary. The client created a task, communicated on it, and did all this through Telegram. He never had to go to Redmine for this. The employee received and processed the task in the usual way in Redmine, as part of standard business processes, he did not have to switch to the messenger, and then take care of transferring the correspondence to the task system.
Attachment Support
In the bot, we implemented support for attachments. And it works both ways. You can attach anything you like: photos, documents, video and audio. You can even attach stickers, though they look so-so in the browser, but it’s a pity, sometimes a perfectly selected sticker extends the life of our entire office.
Let's say a monitoring system informed us of a problem on one of the servers. The administrator created a task through Redmine and attached a graph of the monitoring system to it. The client will receive the following message:
To which he can respond with a voice message:
A voice message will be delivered to the task and listened to by the administrator.
Limitations
Of course they are. We encountered the following:
- Long posts. Telegram has a limit on the length of one message - 4096 characters. Initially, long comments from Redmine were simply clipped. I had to write a handler that broke long comments into pieces. And so that it was pleasing to the eye, that is, that the comment did not break off strictly at 4096 characters in the middle of the word, and the breakup occurred carefully, at the junction of phrases. For customers, the inconvenience is that in this case several messages will come.
- Formatting Formatting in Redmine and Telegram are two different universes. But it is understandable, and their purpose is somewhat different. Redmine formatting is displayed in Telegram as service characters, and sometimes it is very difficult to read. So far, we have not figured out how to display them in their normal form, but we do not leave any hope of eliminating this nuisance. Not everything is transferred from Telegram to Redmine either. For example, if the text contains certain emoticons, then receiving such a message Redmine just cut it. These are the features of the Redmine database structure. We have some tips for solving this problem and they work correctly on a test bench, but so far we are afraid to use them on a combat base.
- Names of images. If you attach an image attachment (namely an image) to Telegram, the bot will receive a file with a name in the format file_xyz.jpg. Accordingly, in Redmine he will get with that name. Here we can’t do anything yet, since the bot itself receives files with these names.
- The interface and all bot messages so far are only in Russian, but in one of the next versions we plan to add support for other languages.
Usage statistics
A little over two months have passed since the launch. First observations:
- Currently, about 3.5% of tasks are created and updated by clients through the bot.
- As already mentioned above, the bot has found application not only among customers, but is also actively used by ourselves. It is very convenient to receive notifications on tasks (they arrive faster than in the mail) and immediately answer them. Feels like with the launch of the bot, we have increased the speed of communication on internal tasks.
Briefly about how our bot works
- It is written in C. More precisely, in our framework, which is written in C
- Uses two types of databases: Redis and MySQL
- We needed to write a plugin for Redmine, which would activate the hook mechanism when creating tasks and comments
- Easy to replicate and scale.
So, let's start ... The
basic scheme of the bot is as follows:
It seems nothing complicated - all the changes in Redmine are delivered to the bot using hooks, it looks at the type of event in which project it happened, determines the Telegram accounts of the recipients of this message and delivers them. From the side of Telegram, everything happens in a similar way - the type of message is determined, what task it relates to and delivered to Redmine.
Now let's add a little action and get acquainted with some features of message delivery in Telegram!
Telegram splits large messages into several small ones. These messages come with some delay. All attachments are delivered as separate messages and sometimes with a long delay (as the user downloads them). Those. you can’t just take and forward all received messages, otherwise we will spam users and spoil our karma.
And what to do? We decided to create message queues for this and use Redis to store them. Our bot queues each incoming message and updates the delay time for its processing. When this delay has expired, we believe that the message is fully formed and now you can select a task and send it to Redmine.
Then the question arises: how to choose the right task in Redmine? Indeed, in order for the bot to understand what to do with the received data, it needs to ask the user about it, and this, anyway, is another message (even if it is a button click) and it needs to be somehow connected with previous user actions. This session will help us.
The first message received from the user's Telegram account - generates a session that contains:
- User ID associated with the session
- Type of session (i.e. its state)
- Data to do something with
Each subsequent message received from Telegram can either supplement the session with data, or change its state (for example, start the process of further processing and delivery of data), or destroy the session (for example, if the user changes his mind to write his comment), or lead to an error (for example, if the type of data received does not correspond to the current state of the session).
Another important element of the bot is caching. Our Redmine consists of a fairly large number of projects, users and some other data. The bot often needs to access this data, and if it will follow them every time in Redmine, this will lead to noticeable delays in processing requests.
The bot has a separate process that is only concerned with periodically retrieving from Redmine the data required for the rest of the processes and storing it in Redis.
What about MySQL?
It was noted above that in addition to Redis, the bot also uses MySQL. Of course, all the data could be stored in Redis, but despite the presence of periodic dumps - the data is still stored in memory and an unexpected crash in the system can lead to their loss, and among them there is very important information that needs to be treated with particular care. To better understand what is at stake, we recall the first part of the article. It said that the user can not only choose from the dialogue with the bot what to do with his message (create a new task or select an existing one), but also make a response to the message. And the bot must understand what task you need to add it to.
In Telegram, messages have identifiers that have nothing to do with task identifiers in Redmine. In order to make them friends, you need to establish some kind of correspondence and decide how to store this data. But before that, let's try to understand how this data is formed, what will happen if this data is lost and, based on this, to understand their importance.
Suppose a user writes his first message in a Telegram bot. The bot opens the session and finds out from the user what task you need to add a comment to. After the answer is received - the bot sends the data to Redmine and at the same time saves this correspondence at home.
Further, when the user makes a reply to this message in Telegram, the bot will receive the number of the “parent” message and determine the number of the Redmine task to which the comment should be sent. The described correspondence will also be established for this new message, i.e. reply can then be done on it. The same is true for events coming from Redmine. Our clients believe that this is a very convenient mechanism and, judging by the statistics, they use it very actively.
Now let's imagine that we have lost all these correspondences. Those. the client, as a matter of habit, clicks reply to the message that came from the administrator, writes his comment and sends it to the bot. But since the bot according to the described algorithm is no longer able to understand what task to send a comment to, it will give an error message and ask additional questions in order to find out what to do next.
Other important types of data that cannot be lost (and they cannot be lost even more than the first ones) are the correspondence of Redmine and Telegram user IDs. If this does happen, then users will simply stop receiving information about events taking place in Redmine until they write something to the bot. And since According to polls, the bots are almost more often used as a notifier (to replace mail), then here we can get even more trouble.
In order not to upset users, we put this data into a less fast but more reliable MySQL.
In fairness, it is worth noting that our team is still arguing about whether to abandon MySQL and transfer this data to Redis. Therefore, it is possible that in the future we can completely switch to working with Redis, and maybe even to some other storage system. Fortunately, the architecture of our application makes such replacements relatively simple.
Scaling and fault tolerance
Now I would like to talk about how to ensure the scaling and fault tolerance of the bot ...
With the advent of the bot, our Redmine in some cases turned into a chat and the intensity of messaging is constantly growing. Some of our customers also want to integrate it into their infrastructure. And given the fact that our development is completely open source, it is not known what other company or team of administrators / developers wants to use it and it is not known what loads the bot will encounter. Therefore, even at the stage of project development, we laid the possibility of scaling in it.
In our project, scaling can be divided into two classes:
- Scaling Databases
Here everything is fairly well known:- For MySQL, you can use Percona Cluster or equivalents.
- For Redis - Redis Cluster
- Scaling the bot itself
To understand how the bot can be scaled, let's take a closer look at the process of receiving and processing messages.
The schematic diagram is as follows:
The only task of the “Rest API” process is to put a message received from Redmine or Telegram into a ra-queue and wait for the next. This queue is constantly monitored by the Queue-workers processes, and when data appears in it, they are read.
Messages from Redmine are immediately processed and sent to the right users in Telegram. With events from Telegram, everything is more complicated. Because they cannot be sent immediately to Redmine (the reasons are described above), then they are transferred to another queue, already broken down by users. The type of message determines the time during which we wait for other messages. Sooner or later, all these messages are read, undergo preliminary preparation, in one way or another change the state of the session and can be sent to Redmine with all the attached files that are downloaded from Telegram at the same step.
It is important to note here that thanks to this approach and the existing locking mechanism, processing always occurs on one specific node. This is what allows you to create as many bot instances with as many Queue-workers processes as necessary within the existing load.
When Redmine receives a message, a hook is triggered and the same message is sent back to the bot, after which it is delivered to the rest of the Telegram accounts subscribed to the task.
Thus, the infrastructure of the bot in a distributed version can be represented as follows:
But everything described does not limit the ability to use the bot in the usual standalone version with one MySQL server and the usual non-clustered version of Redis.
How to try a bot?
To demonstrate the work of the bot, we made a demo version, available at demo.nxs-chat.nixys.ru .
To try it in action, you need to follow a few preliminary steps:
- In demo.nxs-chat.nixys.ru/account/register register at least 2 accounts (to be able to correspond between them) and fill in the Telegram field for at least one of them
- Activate created accounts
- Find the @nixys_demo_chat_bot bot for each Telegram account specified during registration, and click the Start button .
Make sure that the same usernames are set in the settings of Telegram accounts as in the account settings in demo.nxs-chat.nixys.ru - Create a project in Redmine and add the created accounts to it in the role of "Project member"
- In the created project, add a task and start communication!
Important notice! The bot will send messages to Telegram in the following cases:
- The account that is the author of the task (provided that it is not the author of a specific comment)
- The account that is the executor of the task (provided that this is not the author of a specific comment)
- Accounts in the list of observers in the task (provided that this is not the author of a specific comment)
How to get a bot?
The bot is completely open and can be obtained both in the form of source codes and as a package (packages are currently available only for Debian 8, but will be available for Debian 9 and CentOS 7 in the near future).
Link to the Github repository with bot source codes . There is also an instruction for installing a bot from packages and setting it up.
Conclusion
In the near future we plan to add the following functionality:
- Simplify task creation
- Set up notifications
- Multilingual interface
- Subscribing to tasks and unsubscribing from them through the bot (now it is possible to do this only through Redmine)
- In the future we plan to add voice file recognition to the text, which will be very useful for tasks that customers create with voice
- And much more