Support

Documentation

Frequently asked questions

1.1. Why did you remove the old Gmail integration? It seemed to work fine.
1.2. Other applications don't require me to go through that process to login to Gmail / G Suite. They just show a consent page. Why didn't you implement something like this?
1.3. I am not a G Suite admin (e.g. I am a site integrator working on behalf of my client). Can I set up Akeeba Ticket System to use the G Suite account?
1.4. I do not have access to my client's Gmail account. Can I set up Akeeba Ticket System to use their Gmail account?
1.5. I believe there is an easier way to connect to Gmail / G Suite email
1.6. How about the security, privacy and GDPR compliance of this integration?
1.7. Can I forward my Gmail / G Suite emails to a different account and access that account over IMAP / POP3 instead?
1.1. Why did you remove the old Gmail integration? It seemed to work fine.
1.2. Other applications don't require me to go through that process to login to Gmail / G Suite. They just show a consent page. Why didn't you implement something like this?
1.3. I am not a G Suite admin (e.g. I am a site integrator working on behalf of my client). Can I set up Akeeba Ticket System to use the G Suite account?
1.4. I do not have access to my client's Gmail account. Can I set up Akeeba Ticket System to use their Gmail account?
1.5. I believe there is an easier way to connect to Gmail / G Suite email
1.6. How about the security, privacy and GDPR compliance of this integration?
1.7. Can I forward my Gmail / G Suite emails to a different account and access that account over IMAP / POP3 instead?

1.1.

Why did you remove the old Gmail integration? It seemed to work fine.

Yes, it did work fine. However, Google decided to phase out the IMAP password authentication for Gmail and G Suite mail. This means that starting June 2020 it no longer works fine – it doesn't work at all. Implementing XOAUTH2 is a requirement imposed by Google, not Akeeba Ltd. If you are unhappy with that please let them know; we have done so already.

1.2.

Other applications don't require me to go through that process to login to Gmail / G Suite. They just show a consent page. Why didn't you implement something like this?

This is exactly the approach we initially pursued. However, Google wouldn't allow us to do it.

As explained earlier, Access and Refresh Tokens are issued to an API application registered with Google. There are two kinds of applications. An Internal application – like the one created with the process explained above – only allows getting tokens for an email account that is the same as the one creating the account (Gmail) or belongs to the same organisation (G Suite). This wouldn't work for our clients. This meant that we had to create the other kind of API application, an External one. The External application is able to request tokens for any Gmail or G Suite account. However, External applications need to be verified by Google.

Normally, External applications are used for desktop applications, mobile apps or hosted web services. Akeeba Ticket System is none of the above. It's a self-hosted web application meant to be installed on your sites. The tokens are meant to be stored on our clients' sites, not our server. The emails are retrieved directly by our clients' sites, not through our server. However, Google requires us to host an application on our domain to retrieve the Access Token and, when it expires, exchange the Refresh Token with a new Access Token.

The only solution to that is something similar to what desktop / mobile apps like Thunderbird or Microsoft Outlook for Android do – or like what we are already doing in Akeeba Backup to integrate with Google Drive: a "mediator" application. That's a barebones application hosted on our site which handles the OAuth2 consent flow, retrieves the Access and refresh Tokens and conveys them to your site, without storing them on our server. This guarantees your privacy.

We wrote and tested that code and submitted our External API application to Google for verification. Unfortunately, Google decided to decline the verification of our Extenal API application on the grounds that the site processing the email is not the same as the domain name registered with the application. Therefore they are rejecting the use case of a self-hosted ticket system using an easy method for authenticating to Gmail / G Suite.

Google gave us only one alternative: have an unverified application which could be whitelisted by G Suite administrators manually. This alternative is bad for two reasons. First and foremost, it makes it impossible for Gmail clients (with an @gmail.com email address) to use Akeeba Ticket System; that's the majority of our clients interested in connecting Akeeba Ticket System with a mail account hosted by Google. Second, the manual whitelisting process is just as complicated as creating your own Internal API application.

This left us with two options. One, we would have to stop supporting Gmail / G Suite in Akeeba Ticket System. Two, we would have to make you create your own Internal API applications with Google since they do not require going through the verification process. We chose the latter as the lesser of two evils.

We are fully aware that this process is complicated and hostile to the users. We did raise that point with Google, repeatedly, throughout the onerous verification process. Unfortunately, Google does not want to consider software like Akeeba Ticket System as valid consumers of email. In other words, email accounts hosted by Google come with artificial limitations imposed by Google. They are not real email accounts that can be used for any purpose their owners see fit. They are crippled by anti-features which are controlled by a commercial entity's opaque and arbitrary decision making process.

We strongly recommend not using a Google-controlled, crippled email account whenever possible. If your organisation / client is tied to G Suite then you will have to go through the complicated process of creating an Internal API application. Unfortunately, we can't be of much help because Google doesn't allow third parties providing support for its products either. Worse, yet, because of the nature of an Internal API application we cannot perform that process for you, not for free or even for a fee; it would require administrator access to your Gmail / G Suite account that you cannot reasonably provide and we cannot possibly accept to be given for reasons that have to do with GDPR and similar privacy legislation.

1.3.

I am not a G Suite admin (e.g. I am a site integrator working on behalf of my client). Can I set up Akeeba Ticket System to use the G Suite account?

No, you can't. That's a limitation due to Google's decision not to authorize our External project as described above.

1.4.

I do not have access to my client's Gmail account. Can I set up Akeeba Ticket System to use their Gmail account?

No, you can't. That's a limitation due to Google's decision not to authorize our External project as described above.

1.5.

I believe there is an easier way to connect to Gmail / G Suite email

Yes, you are right, there is. Unfortunately, Google denied verification for it. See the long explanation above.

1.6.

How about the security, privacy and GDPR compliance of this integration?

Your OAuth2 API application information (client ID and secret key) and your access and refresh tokens are only stored on your own site, as plugin parameters. They are NOT shared with Akeeba Ltd or any other third party, nor do they ever leave your site. This means that you have perfect privacy of your support tickets.

Regarding security, your information is as secure as your Joomla! site itself. If your site gets hacked you should unlink your email address from your API application, disable the OAuth2 API credentials of your API application and create new ones, then relink ATS to your email account. A more secure alternative is forwarding your emails to a non-Gmail, non-G Suite email account that's accessible over regular IMAP with password authentication. In case of compromise you can simply change the password of that account and be done with it.

As for GDRP, CCPA and similar privacy legislation – please ask your lawyer. We cannot give a legal opinion. Our non-legal advice is that you should disclose that the emails sent to a particular email address are automatically processed by software running on your site for the purpose of creating new support tickets or replies to existing ones. If that has other privacy implications, e.g. third parties employed by / affiliated with your site have access to the ticket system, that should be disclosed as well. Again, it's best to ask a qualified lawyer.

1.7.

Can I forward my Gmail / G Suite emails to a different account and access that account over IMAP / POP3 instead?

Yes, of course you can. Google has documented the automatic mail forwarding process already.

Once you set up your automatic forwarding to a regular email account, e.g. one provided by your hosting company, you can connect ATS to that email account over IMAP / POP3.