Google Calendar Integration & Sync Issues

khvusr · 10 May 2025 10:34

Using v8.8.0 and trying to get the google calendar sync to work. It took a few tries to get the google api intgration to stick under Administration / Google Sync Settings; meaning that I uploaded the json file and saved and logged out and in again just to find that it dropped the json file. But, seems to stick now.

Next logged with user account and had the same experience; first didn’t seem to stick but after a few tries it seems that the Google Account Synchronization sticks and indicates that it’s been configured.

But, still it doesn’t seem to sync with the personal google calendar tied to the account and yes the calendar sync option is marked. And everything indicates Configured.

What is it that I’m missing out here? Also, once working, does this also mean that when scheduling a meeting that it will create a Google Meeting link as well?

pstevens · 10 May 2025 16:43

For me it hasn’t worked properly in years. It seems to work once I “re-authorize” and it syncs once, but subsequent syncs never work. I’ve tried to debug a few times but just end up re-authorizing when I need a sync a couple of times a day.

khvusr · 10 May 2025 16:49

Ok, sounds like one would need to look for third-party add-on to solve this then. Pitty, since it’s an essential function of a crm which is crazy that it doesn’t work.

While on the topic of integration; what about google maps integration; is this also something which is an issue as well from your side to get to work?

guiferreira2000 · 13 May 2025 11:29

I’m experiencing the same critical issue with Google Calendar sync in SuiteCRM 8.8 on PHP 8.3, and I want to clarify that this is not related to scheduler misconfiguration — the scheduled sync is running perfectly every minute.

The core issue:

The OAuth access token is being refreshed successfully and appears to be saved using setPreference() and savePreferencesToDB(). But despite this, every subsequent run treats the token as expired, resulting in the same cycle:

Scheduler runs and loads the access token from user preferences
isAccessTokenExpired() returns true
A new token is fetched and logged as successfully saved
On the next run, it repeats — never reusing the token just saved

What I’ve discovered:

This isn’t just a logic bug — it appears to be tied to SuiteCRM’s session behavior, particularly in CLI (cron) context:

Either the token isn’t actually saved to the DB despite the success log, or
The session data ($_SESSION[...]) used to track preference state is reset or not properly restored when cron runs again

So even though setPreference() sets the value and savePreferencesToDB() reports success, the system still loads an outdated or blank token on the next run. This suggests the refreshed token isn’t truly being persisted or is being lost between runs — possibly because SuiteCRM stores preferences in session and relies on session state even in CLI mode.

Why this matters:

This did not happen in SuiteCRM 8.3 under the same environment. It only started after upgrading to 8.8. So this looks like a regression, possibly due to session changes or stricter behavior introduced in 8.8 or triggered by PHP 8.3.

Suggestion:

The OAuth logic needs to force-load preferences from the database explicitly during cron execution and not rely on session state to persist values between runs.

khvusr · 14 May 2025 13:02

@guiferreira2000 Thanks, confirms that I’m doing it right, but that it’s SuiteCRM which isn’t doing what it’s expected. I would assume that there is bug report for this already, right?

Edit: I see now that you’ve also raised a issue ticket for this yesterday: Google Calendar Sync only works while the access token has not expired · Issue #10674 · salesagility/SuiteCRM · GitHub

guiferreira2000 · 20 May 2025 09:52

Solution for Sessions for Google sync users

Issue 1

The proposed fix suggested on Regression: Local users gets Profile wizard on each login · Issue #10637 · salesagility/SuiteCRM · GitHub still won’t work, because in reloadPreferences() in the modules/UserPreferences/UserPreference.php that inner if

        if ($row) {
            if (!$GLOBALS['current_user']->id || $GLOBALS['current_user']->user_name === $user->user_name){
                $_SESSION[$user->user_name . '_PREFERENCES'][$category] = unserialize(base64_decode($row['contents']));
            }
            $user->user_preferences[$category] = unserialize(base64_decode($row['contents']));
            return true;
        } else {
            if (!$GLOBALS['current_user']->id || $GLOBALS['current_user']->user_name === $user->user_name){
                $_SESSION[$user->user_name . '_PREFERENCES'][$category] = array();
            }
            $user->user_preferences[$category] = array();
        }

will never be true for your Google‐Sync user when run under cron, since current_user is always the admin. As a result, the sync user’s session bucket never gets populated—instead it falls through to the “else” and gets reset to an empty array. That change was introduced in commit ea756b13f0ae606997c0ccb4382e1a72902a9207 (“Add check for current user on session preferences”) and has broken Google‐Sync users

Fix

Or remove the condition completely

if (!$GLOBALS['current_user']->id || $GLOBALS['current_user']->user_name === $user->user_name){

Or add an extra condition like

if (PHP_SAPI === 'cli' || $GLOBALS['current_user']->user_name === $user->user_name){

Whenever PHP is invoked from the command‐line (for example by your cron job), its “Server API” string (PHP_SAPI) is set to cli. In contrast, when PHP runs as an Apache module it might be apache2handler, or under PHP‐FPM it’s fpm‐cgi, etc.

This will always be true in the cron context, because you’re literally calling php -f cron.php (the CLI binary), not going through the web server. That guarantees your session‐reload logic fires under cron even though current_user is still “admin.

Issue 2

On the other hand, the function getGoogleClient in the file include/GoogleSync/GoogleSyncBase.php needs also a small fix for code optimization so it does not refresh the Google API token every minute. To fix this, pass the “no-session” flag (0) as the third argument and the category as the fourth:

By changing from

                $this->workingUser->setPreference('GoogleApiToken', base64_encode(json_encode($client->getAccessToken())), 'GoogleSync');

to

$this->workingUser->setPreference('GoogleApiToken', base64_encode(json_encode($client->getAccessToken())), 0,'GoogleSync');

you are making sure that the generated GoogleApiToken is actually saved under the user preference GoogleSync and not Global

If you make this change the token is saved under the GoogleSync category, so subsequent runs will load the existing token and only refresh when it’s actually expired.

The current behaviour means that the function getGoogleClient always perceives the GoogleApiToken as expired and forces the token to be reloaded because it cannot find it in the GoogleSync preference.

pgr · 20 May 2025 10:56

@guiferreira2000 can you please make a PR to fix these bugs in core code?

guiferreira2000 · 20 May 2025 17:52

Hello @pgr here’s the pull request

github.com/salesagility/SuiteCRM

Fix #10674 - Enable CLI session reload and fix GoogleSync token persi…

salesagility:hotfix ← CRM-Seepmode:bugfix_10674

opened 05:44PM - 20 May 25 UTC

Guiferreira2000

+8 -3

## Description This pull request contains two related bug fixes for SuiteCRM’…s Google Calendar sync and session managment which are related: Enable CLI-driven session reload The **reloadPreferences()** method in **modules/UserPreferences/UserPreference.php** was only populating **$_SESSION** when the web’s **current_user** matched the target user. Since cron jobs always run as Admin under the PHP CLI SAPI, the GoogleSync user’s session bucket was never loaded—causing their preferences to be reset on every run. Added a **PHP_SAPI === 'cli'** check so that under cron we always reload the user’s preferences into **$_SESSION**. Fix GoogleApiToken persistence In include **/GoogleSync/GoogleSyncBase.php**, the call to ```sh $this->workingUser->setPreference('GoogleApiToken', base64_encode(json_encode($client->getAccessToken())), 'GoogleSync'); ``` was inadvertently saving the new token to the global category due to the method signature. As a result, each run treated the token as missing and refreshed it every minute. Changed the call to ```sh $this->workingUser->setPreference('GoogleApiToken', base64_encode(json_encode($client->getAccessToken())), 0, 'GoogleSync'); ``` so the token is stored correctly in the GoogleSync category and only refreshed when truly expired. Closes #10674 #10637 ## Motivation and Context Issue 1: Cron-driven Google sync never sees the saved token in **$_SESSION** because sessions are only populated for web users. This caused the google-sync user to always be redirected to user wizard since it had no session saved. Issue 2: Incorrect **setPreference()** usage meant the token was saved under the wrong category, so even a correctly populated session would still appear empty for GoogleSync. Together, these fixes ensure that: - The existing token is loaded under cron, - New tokens are saved in the right place, - The sync only refreshes tokens when necessary. ## How To Test This 1. Prepare In the UI, authorize Google Calendar for a non-admin user. Confirm that a valid **GoogleApiToken** + **GoogleApiRefreshToken** appear under the GoogleSync category in **user_preferences**. 2. Verify CLI reload ```sh php cron.php --job="Sync Google calendars" ``` - First run: should log the existing token and skip refresh. - Second run (immediately after): must not log “Refreshing Access Token” again, and the token in the DB remains unchanged. 3. Verify web behavior Log in as that user in the browser and perform an action that reads a preference. Ensure their preferences still load normally. ## Types of changes - [x] Bug fix (non-breaking change which fixes an issue) ### Final checklist - [x] My code follows the code style of this project found [here](https://docs.suitecrm.com/community/contributing-code/coding-standards/). - [ ] My change requires a change to the documentation. - [x] I have read the [**How to Contribute**](https://docs.suitecrm.com/community/contributing-code/) guidelines.