Google Calendar Sync only works once

đź’¬ General Discussion
1

This is going to be one of those “is it just me” questions. I recently updated to 7.14, not sure if that was the cause, but in doing so I also had to reset my user preferences to fix some other issues going on from the upgrade. Then my Google calendar sync stopped working. Expected, I reset my user preferences. So I re-authorized, no problem, my sync started working again. Then I noticed, not working again. Re-authorized= working again. Long story short, it only works once and then I have to re-authorize.

I can’t see anything pertinent in the error logs. Is it just me?

2

Hi pstevens,
Can we schedule meeting in crm and that meeting show on my Google calendar page.
Is there any possibility.
Thanks & regard
Vishal Raj

3

Yes thats exactly what it does

4

Hi Paul

I had something similar and was chasing my tail. Mine turned out to be a simple problem with cron and/or the CRM scheduler.

Calendar sync ran when I authorised and then didn’t run again. After a lot of code chasing and other activity, I went into the CLI and ran the cron job from there and it worked again, but only that once.

We are on a shared platform but long story short, I redid the cron and re-timed the google calendar sync function in the scheduler and saved it and it started working all the time. I don’t have a prognosis but this did do the trick :slight_smile:

We are on v8.5 rather thanthe more stable V7 and I am sure you have probably checked the above but just worth pointing out, as I know how frustrating these things are.

I hope this helps.

I watched your Bounceback video about 4 times to try and solve our long term issue with it. We just get IMAP handler errors - IMAP non-valid resource stream and IMAP search errors, from the bounceback function every hour between 2am and 6am, when it is set to run and no bounceback functionality has ever worked. I have given up on it, as there is a lot of stuff in the forum but nothing that has fixed it.

Good luck

1 Like
5

THANK YOU!!!

I assumed because it was running once, that the job was running. I look in my scheduler and the Google Calendar sync job is no longer there!! Must have got cleaned out when I reset my user preferences. I think that’s it.

I owe you one! If you nee help with the bounce stuff let me know, I went through it all in detail a couple of months ago and have a pretty good understanding of how it works.

6

No problem. Glad to be of help rather than asking for it for once :slight_smile:.

I might revisit the IMAP problem again soon and drop you a note of where we are. Not that urgent as we handle bounces outside of the CRM at the moment and have this off to a fine art, so it takes about 30 mins to sort them.

Glad you got it fixed.

7

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.

8

Since you have a detailed diagnosis, please make sure there is an Issue for this on Github - otherwise it won’t get any attention from the devs.

9

This is the behavior I am also experiencing in 7,14 so its not specific to v8.x

10

I have created the following issue on github

Also I notice that the issue Regression: Local users gets Profile wizard on each login · Issue #10637 · salesagility/SuiteCRM · GitHub is related to the google calendar sync because when the token has expired it completely overrides the Global content inside the userpreferences due to the following line in googlesyncbase.php

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

Yes, that is expected because SuiteCRM 8.8 works with the engine of SuiteCRM 7.14 in some legacy code. And the sessions and google handling is done under SuiteCRM 7