At present, the websocket pubsub tokens are present at the contact objects in chatwoot. A better approach would be to have these tokens at the contact_inbox object instead. This helps chatwoot to deliver the websocket events targetted to the specific widget connection, stop contact events from leaking into other chat sessions from the same contact.
Fixes#1682Fixes#1664
Co-authored-by: Pranav Raj S <pranav@chatwoot.com>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
This change allows the user to configure both IMAP and SMTP for an email inbox. IMAP enables the user to see emails in Chatwoot. And user can use SMTP to reply to an email conversation.
Users can use the default settings to send and receive emails for email inboxes if both IMAP and SMTP are disabled.
Fixes#2520
This fixes issues in the swagger.json file. The motivation to do so is to be able to generate API clients using https://openapi-generator.tech Doing so will require further changes to the api spec, but this seems like a good first step since it is now "valid" according to editor.swagger.io and openapi-generator validate.
Fixes#2806
Configuring an agent email also as a support email inbox leads to conversations getting created in a loop if notifications were also configured to the same email.
- fix the wrong conversation status being sent in webhooks
- additional information in websocket events
- refactor activity messaging code
- move activity message generation to background job to stop the callback loop
* fix: Remove * as import from conversation module
* Remove * as import from conversation test spec
Co-authored-by: Fayaz Ahmed <15716057+fayazara@users.noreply.github.com>
This change limits the rails, redis and postgres container on `docker-compose.production.yaml` file to localhost only.
The default docker-compose configuration will expose redis, postgres and rails directly to the internet when the service is started on a virtual machine.
In most cases that is not what you want, and especially for redis and postgres exposing the services could be a potential security risk. By adding 127.0.0.1 access is limited to localhost and access is only possible after nginx oder another web server is configured as reverse proxy.
Note: Moving forward, anyone using docker-compose.production.yaml need to have something like Nginxto proxy the requests to the container.
If you want to verify whether the installation is working, try curl -I localhost:3000 to see if it returns 200. Also, you could temporarily drop the 127:0.0.1:3000:3000 for rails to 3000:3000 to access your instance at http://:3000. It's recommended to revert this change back and use Nginx in front.
Approved-by: Vishnu Narayanan <vishnu@chatwoot.com>
