Matttermost Connection settings will be stored in “Desk | Setup | Email | Mattermost Settings”. DocType “Mattermost Settings” with type “System” will be created in the folder in Frappe/frappe/core/doctype. In the file Frappe/frappe/config/setup.py new Setup item for Mattermost settings will be added.
The folder Frappe/frappe/mattermost will be created. This folder will contain:
mattermost.py with post() method as like as frappe.desk.page.messages.messages.post(). It will create doc “Communication”, Communication_Type = ‘Notification’, Type (communication_medium) = “Chat”. Thats all. It will not doing nothing.
Python-wrapper class for Mattermost. The only one method will be used - for send message
Update handler Communicationn.after_insert(): after_insert() → it will call async task which will send message in Mattermost send2mattermost().delay(). This task will be stored in Frappe/frappe/tasks.py and executed by Celery (in case of Python RQ @celery_task decorator will be deleted and method will be called via frappe.utils.background_jobs.enqueue(method, **kwargs)). This async task will call Frappe/frappe/mattermost for “Communication” docs
Add in all necessary DocType checkbox for Mattermost and in chechboxes handles add call of mattermost.post() method from Frappe/frappe/mattermost.
for anybody who (as me) might be wondering what Mattermost is
Mattermost is an open source, self-hosted Slack-alternative … to proprietary SaaS messaging, Mattermost brings all your team communication into one place, making it searchable and accessible anywhere.
Actually, even though aforementioned pull request was closed, the commits are still retrievable in case you want.
I’m not a legal expert, so can’t promote this possible act as non-violating, taking into account that at some point Semilimes have closed all their public repos. Probably that happened after Alex Kozlov’s letter, which was mentioned by osya.
the files in the pull request inherited Frappe MIT License, and that because the didn’t put it in its on app and used hooks, instead they were implementing it with in frappe which i think was a mistake
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I messaged the original developer Osya about his code and to get some estimate from him to finish it and here is his replay
The main problem with this task of Mattermost integration is requirements. I cant even rough estimate time because it depends on requirements. If you really need Mattermost integration I suggest you to start with writing good requirements.
According to my work during this task for Mattermost Integration. There were no requirements and I needed to create some prototype as fast as possible. So I created some simple web page with field for enter you message and field for view all messages. This web page sends requests to Mattermost server (it is regular requests, not Websockets). I suppose, it is not what you are expecting from the Mattermost Integration.
As I understand requirements should contains the following:
At first it should be some module in Frappe framework. But it should be discussed with community. Probably it is better not to create separate module for Mattermost, but make some refactoring in Frappe and create one module for communication and/or notification. This module will contain not only Mattermost, but also email, SMS, and other notification channels. Probably tomorrow you will decide to integrate ERPNext with another messaging service. This new module should be extendable for new services.
Then I suppose it doesn’t make sense to create some app in Frappe/ERPNext just for chatting. You can use good separate chat clients for this. Instead it should be deep integration with ERPNext. Some SMEs should decide in which ERPNext modules should be integration with Mattermost and how it should looks like. These changes in ERPNext modules for Mattermost integration will use base module for Mattermost integration from Frappe framework.
And last my point - websockets should be used, not just GET/POST requests. Due to performance
As you see, to create good requirements needed discussion with Community and SMEs. And you see that deep integration of Mattermost with ERPNext is a big project, not a small simple task. This project should be planned somehow.
Creating Bounty is a good idea. Besides that I can recommend you to post job on Upwork. After good requirements will be ready and job posted on Bounty/Upwork I will probably come back to it.
He is quite right, we need to come up with generic way to integrate Mattermost with frappe. Generic in a way that we can define triggers and actions for any doctype, so the possibility will be limitless. for example, used for share, leave applications, new leads, new sale order… triggers can be defined for any model. so what do you guys think, how mattermost can be integrated into Frappe in generic way?
I think the way to look at this generically with minimal work is the following.
Frappe/ERPNext currently has “Email Alerts” that you can create. These are quite powerful and flexible. We would use the same concept here.
Create an “Alert” Doctype - you would use most of the same things as are currently there in Email Alert. In this way, it is completely flexible and user defined.
Rather than worrying about which app (mattermost, rocketchat, slack, glip, etc) to use, just use a generic webhook. Most services accept webhooks. The “recipient” of the alert would be webhook location.
In Alerts, you would paste the URL as the recipient
When an alert is triggered, it would make an HTTP POST request to the Webhook URL in properly formatted JSON. For phase one, this can be as simple as the following
POST https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX Content-type: application/json { "text": "This is a line of text.\nAnd this is another one." }
If the post is successful (HTTP 200 OK) then great. If not, then put the response error in the error log.
As you go further along, you could, in theory, make “Alert” completely generic. When you define an alert, you could define an Email recipient, an SMS recipient, a Webhook recipient, or more. This has the potential to be quite powerful.