View Issue Details

IDProjectCategoryView StatusLast Update
0002718SOGo IntegratorBackend Calendarpublic2014-09-05 15:23
Reportermbi Assigned To 
Status newResolutionopen 
Platformx64OSWindowsOS Version7
Product Version24.0.4 
Summary0002718: Shared Calendars not automatically refreshed when events are added/updated/deleted

We have 2 calendar-users/calendars that are shared with other users.

Whenever someone invites one of these calendar-users/calendars to an event, the event is automatically added to the calendar (as it should be).

The problem is, the default calendar refresh interval for all Thunderbird+Lightning+Integrator calendars is 30 minutes.

So, when a user adds an event to one of these calendars through the invite mechanism, no one sees the event/update immediately, and in fact it may be up to 30 minutes before some of these users see the update.

Steps To Reproduce
  1. Create dedicated calendar user account

  2. Rename that users Personal Calendar to the new Shared Calendar name

  3. Assign permission for normal users to 'View All' (read-only)

  4. Using Thunderbird+Integrator with normal user account, create an event on your personal calendar and invite the calendar-user

  5. Note that the event does not show up immediately on the Shared Calendar, and that in fact it will not show up until the Calendar Refresh interval is triggered.

Yes, the user can manually click the 'Sync' button - except that many users hide the calendar toolbar - and besides, many of them simply won't think to do that.

Additional Information

What I'd love to see is a calendar option in the Permissions dialog to:

'Force refresh for this user/group when this calendar is modified.'

TagsNo tags attached.


related to 0002880 resolvedludovic SOGo Calendar polling interval for the webinterface 


Christian Mack

Christian Mack

2014-04-17 05:16

developer   ~0006915

Sorry, but if you need shorter refreshes, why don't you set refreshes to say 5 minutes?



2014-04-17 05:28

reporter   ~0006918

Thanks Christian.

I thought it was obvious that, yes, I could set a shorter refresh interval (since I noted the default was 30 minutes), but that is completely irrelevant to this bug (or possibly feature request), which was summed up in the 'Additional Information' field as:

"What I'd love to see is a calendar option in the Permissions dialog to:

'Force refresh for this user/group when this calendar is modified.'"

Do you not see the advantages of this? Users who 'see' these calendars would t hen see changes immediately, instead of within $Refresh_Interval minutes.

So, by all means, change this to 'enhancement' if you like.

I'd do this myself, but since I am unable to edit the bug details/summary after creation, it is impossible for me to adjust these myself:

Christian Mack

Christian Mack

2014-04-17 05:49

developer   ~0006919

I changed it to Feature request.

And I see only minor benefits.
No one needs immediate calendar changes.
At least if events are scheduled within a resonable timeframe before they occur.

And I see drawbacks.
In order to have immediate changes, you would have to use persistant connections for each calendar!
They would use up a SOGo process on the server too.



2014-04-17 05:51

administrator   ~0006920

There's no way to "Force refresh for this user/group when this calendar is modified."

The refresh interval is used to verify for changes, there's no other way Lightning can be notified about changes right now.



2014-04-17 06:00

reporter   ~0006921

Thanks Ludo - if this cannot be done without changes to Lightning, then that is what it is...

Out of curiosity... what would it take? This would basically be some kind of 'push' function, so, is this purely a Lightning issue? Or does Cal/CardDAV protocol support push capability (like Activesync)?



2014-04-17 06:03

administrator   ~0006922

There's no standard around that.

Apple has created an extension around XMPP to receive notifications:

SOGo doesn't support it, nor does Lightning. If Lightning would support it, we would for sure consider adding support for that in SOGo.



2014-04-17 06:08

reporter   ~0006923


Please do not assume that everyone uses calendars the way you use them.

You simply cannot claim that "No one needs immediate calendar changes.', because you cannot speak for everyone else.

This would be very valuable for us, considering that rather than go down the road of the complexity of 'resource users' and setting up 'resources', we simply set up special calendar-users, and let people invite those calendar users in order to add things to these calendars (that are otherwise read-only for these same users).

And you would NOT need to have persistent connections to the calendars, but yes, you would have to have just one additional server process whose sole job was to watch for calendar changes and push these out.



2014-04-17 06:08

reporter   ~0006924


A little googling reveals that apparently Cal/CardDAV protocol does support PUSH, so the only question then, is, what would it take to get PUSH working with Thunderbird+Lightning - or maybe it works already (since it is a protocol thing) and just no one has tried it?



2014-04-17 06:12

administrator   ~0006925

Have a look at my comment #6922.

If you've found something else, please share it but I doubt there's something else.



2014-04-17 06:13

reporter   ~0006926

@Ludo - ah, sorry, I was working on that post while you were posting the above...

Ok, indeed, the reference I had found was about Apple, and more reading revealed it was an apple only implementation... sorry...

Ok, well, what aboiy PHP-PUSH-2?

This is an ActiveSync reimplementation of ZPUSH that supports Card/CalDAV and has been (supposedly) specifically tested with SOGo.

Or would this also require Lightning to support it?



2014-04-17 06:27

administrator   ~0006927

I don't understand your previous question.

PHP-Push-2 is just a AS implementation that can connect to a CalDAV server for the calendar parts of AS.

Even if AS has "push" concept built-in, like our implementation has, that doesn't mean we don't poll at X interval within a tight loop to see changes while maintaining the HTTP connection open, just like Christian said.

Issue History

Date Modified Username Field Change
2014-04-16 09:45 mbi New Issue
2014-04-17 05:16 Christian Mack Note Added: 0006915
2014-04-17 05:28 mbi Note Added: 0006918
2014-04-17 05:49 Christian Mack Note Added: 0006919
2014-04-17 05:49 Christian Mack Severity minor => feature
2014-04-17 05:51 ludovic Note Added: 0006920
2014-04-17 06:00 mbi Note Added: 0006921
2014-04-17 06:03 ludovic Note Added: 0006922
2014-04-17 06:08 mbi Note Added: 0006923
2014-04-17 06:08 mbi Note Added: 0006924
2014-04-17 06:12 ludovic Note Added: 0006925
2014-04-17 06:13 mbi Note Added: 0006926
2014-04-17 06:27 ludovic Note Added: 0006927
2014-09-05 15:23 ludovic Relationship added related to 0002880