{"id":26001,"date":"2016-04-06T14:08:42","date_gmt":"2016-04-06T12:08:42","guid":{"rendered":"https:\/\/mamchenkov.net\/wordpress\/?p=26001"},"modified":"2019-02-01T15:11:08","modified_gmt":"2019-02-01T13:11:08","slug":"sugarcrm-roundcube-and-request-tracker-integration-on-a-single-domain","status":"publish","type":"post","link":"https:\/\/mamchenkov.net\/wordpress\/2016\/04\/06\/sugarcrm-roundcube-and-request-tracker-integration-on-a-single-domain\/","title":{"rendered":"SugarCRM, RoundCube and Request Tracker integration on a single domain"},"content":{"rendered":"\n

In my years of working as a system administrator I’ve done some pretty complex setups and integration solutions, but I don’t think I’ve done anything as twisted as this one recently.  The setup is part of the large and complex client project, built on their infrastructure, with quite a few requirements and a whole array of limitations.  Several systems were integrated together, but in this particular post I’m focusing primarily on the SugarCRM<\/a>, RoundCube<\/a> and Request Tracker<\/a>.  Also, I am not going to cover the integration to full extent – just the email related parts.<\/p>\n

<\/p>\n

Quick overview of the requirements to set the scene:<\/p>\n

    \n
  1. SugarCRM web application used by company with many employees and multiple offices world-wide.  Currently, with access limited by IP address. Later, maybe, with public access.<\/li>\n
  2. Gmail for Work<\/a> used with a single primary domain and a few alias domains.  Let’s say, example.com<\/em> as a primary domain and other.com as an alias.  user@example.com<\/em> is the same mailbox as user@other.com<\/em> .<\/li>\n
  3. Company employees should not know their Gmail account credentials.<\/li>\n
  4. Individual employee mailboxes and group mailboxes (like support@example.com<\/em>) should operate on the same domain – no sub-domains or additional domains allowed.<\/li>\n
  5. Full featured webmail client (folders, templates, signatures, filters, auto-replies, etc) should be available to all employees within the SugarCRM interface.<\/li>\n
  6. Single sign-on between SugarCRM and webmail client, using SugarCRM user details.  So whoever is logged into the SugarCRM can access webmail without any additional authentication.<\/li>\n
  7. All incoming and outgoing emails to\/from individual employee mailboxes should be imported into the SugarCRM database and linked with related client accounts, so that whoever has the access to see client account in the SugarCRM, can also see the sent and received email communications with this client.<\/li>\n
  8. The exception to the above should be managerial mailboxes, which should be excluded from such import.<\/li>\n
  9. A full-featured ticketing\/suport system for handling support requests and certain types of workflows\/communications should be provided.<\/li>\n
  10. All incoming emails to group mailboxes (such as support@example.com, sales@example.com, etc) should create a new ticket in the ticketing\/support system, also leaving a copy of the message in the Gmail’s mailbox.<\/li>\n
  11. Ticketing\/support system should have single sign-on integration with SugarCRM, using SugarCRM user details.  So whoever is logged into the SugarCRM can access appropriate tickets inside the ticketing\/support system.<\/li>\n
  12. All client-related tickets (based on the primary email address of the client), should be visible inside the SugarCRM to whoever has access to see the client account details.<\/li>\n
  13. Ticketing\/support system should send email responses from appropriate addresses on the @example.com domain, both to external users (“Your request has been received”, etc), as well as internal users (example: employee@example.com – “You have been assigned a new ticket”).<\/li>\n
  14. All systems can be hosted on the same servers, but they cannot expose more than one application to the outside world.  So, for example, choose either web (ports HTTP\/80 or HTTPS\/443) or email (SMTP\/25).<\/li>\n
  15. Additional servers can be provided to expose applications to the outside world, but they will have limited communications between them – firewalls, different networks, etc.<\/li>\n<\/ol>\n

    The above are by no means all the requirements, just the major ones.<\/p>\n

    Now, a little bit on why there were these three particular systems.<\/p>\n

    SugarCRM was the primary part of the project.  If it could solve all the functionality needs, it could have been used on its own, without any additional systems.  By the way, SugarCRM in question is the self-hosted Community Edition version 6.5.20<\/strong>, not professional, enterprise, or cloud variation.<\/p>\n

    SugarCRM provides both the built-in email client and support\/ticketing system, among other things.  However the functionality of both modules is very limited and insufficient for the requirements of the project.<\/p>\n

    Gmail for Work provides an excellent webmail application.  There is even a way to integrate it with external systems for single sign-on, using the SAML SSO Service<\/a>.  Here’s a handy illustration from the page:<\/p>\n

    \"SAML<\/a><\/p>\n

    It wasn’t clear how much time and effort would be needed to so however.  And there was a limitation of embedding Gmail into the SugarCRM interface.  To the best of my knowledge, this is not possible with IFRAME tag (one<\/a>, two<\/a>).  The closest option is to build a custom user interface application using Gmail API<\/a>.  Which is an undertaking of its own.<\/p>\n

    So, with Gmail being unavailable and SugarCRM being not good enough, a third-party solution was necessary.  RoundCube is a free and Open Source application, written in PHP (same as SugarCRM), providing an excellent array of features, extendable with plugins, and with which we had previous positive experiences.<\/p>\n

    Now for the ticketing system, the reasons were very similar.  SugarCRM wasn’t good enough and we needed something else.  There are plenty of alternatives to choose from.  However, in-depth expertise with Request Tracker was the deciding factor.  Turned out be more important than the technology stack – Request Tracker is written in Perl, not PHP.  However it is too a free, Open Source solution, with lots of features and extension functionality.<\/p>\n

    The single sign-on functionality was implemented rather easy.  I’m not going to cover it in this post, but you might want to have a look at some recent related posts talking about this functionality and some of the related issues:<\/p>\n