Could you provide a .mobileconfig changed to demo.sogo.nu for testeing?

I experienced the problem on macOS 13.0 (22A380) using the native calendar.app, but on a custom install of SOGo (Nightly 5.7.1.20221109-1):
The default "personal" calendar does not show up (but work on all other clients) and a new "Calendar" is instead created.

I found the problem: It seems that calendar.app does not like calendars starting with lower case letters (anymore)... and you paths also are lower case calendar names.
If I rename the folder path in the database table "sogo_folder_info" from "/Users/%USERNAME%/Calendar/personal" in c_path to "/Users/%USERNAME%/Calendar/Personal" as well as updating c_path4 from "personal" to "Personal", they show up fine again in caldendar.app

I attached the modified mobileconfig. We didn't get the SSL Cert to work though, maybe someone else can get their mac to trust the cert?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>PayloadContent</key>
    <array>
      <dict>
        <key>EmailAccountDescription</key>
        <string>demo@sogo-demo.de</string>
        <key>EmailAccountType</key>
        <string>EmailTypeIMAP</string>
        <key>EmailAccountName</key>
        <string>DEMO</string>
        <key>EmailAddress</key>
        <string>demo@sogo-demo.de</string>
        <key>IncomingMailServerAuthentication</key>
        <string>EmailAuthPassword</string>
        <key>IncomingMailServerHostName</key>
        <string>netcup-sogo.de</string>
        <key>IncomingMailServerPortNumber</key>
        <integer>993</integer>
        <key>IncomingMailServerUseSSL</key>
        <true/>
        <key>IncomingMailServerUsername</key>
        <string>demo@sogo-demo.de</string>
                <key>IncomingPassword</key>
        <string>demo</string>
                <key>OutgoingMailServerAuthentication</key>
        <string>EmailAuthPassword</string>
        <key>OutgoingMailServerHostName</key>
        <string>netcup-sogo.de</string>
        <key>OutgoingMailServerPortNumber</key>
        <integer>465</integer>
        <key>OutgoingMailServerUseSSL</key>
        <true/>
        <key>OutgoingMailServerUsername</key>
        <string>demo@sogo-demo.de</string>
        <key>OutgoingPasswordSameAsIncomingPassword</key>
        <true/>
        <key>PayloadDescription</key>
        <string>Configures email account.</string>
        <key>PayloadDisplayName</key>
        <string>IMAP Account (info@it-service-kutter.de)</string>
        <key>PayloadIdentifier</key>
        <string>de.sogo-demo.demo.appleprofile.mailcowUI.email</string>
        <key>PayloadOrganization</key>
        <string></string>
        <key>PayloadType</key>
        <string>com.apple.mail.managed</string>
        <key>PayloadUUID</key>
        <string>196DEC6F-5D24-44B4-BD62-96AE34CD9D06</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PreventAppSheet</key>
        <false/>
        <key>PreventMove</key>
        <false/>
        <key>SMIMESigningUserOverrideable</key>
        <true/>
        <key>SMIMESigningCertificateUUIDUserOverrideable</key>
        <true/>
        <key>SMIMEEncryptByDefaultUserOverrideable</key>
        <true/>
        <key>SMIMEEncryptionCertificateUUIDUserOverrideable</key>
        <true/>
        <key>SMIMEEnableEncryptionPerMessageSwitch</key>
        <true/>
      </dict>
            <dict>
        <key>CalDAVAccountDescription</key>
        <string>demo@sogo-demo.de</string>
        <key>CalDAVHostName</key>
        <string>netcup-sogo.de</string>
        <key>CalDAVPort</key>
        <real>443</real>
        <key>CalDAVPrincipalURL</key>
        <string>/SOGo/dav/demo@sogo-demo.de</string>
        <key>CalDAVUseSSL</key>
        <true/>
        <key>CalDAVUsername</key>
        <string>demo@sogo-demo.de</string>
                <key>CalDAVPassword</key>
        <string>demo</string>
                <key>PayloadDescription</key>
        <string>Configures CalDAV account.</string>
        <key>PayloadDisplayName</key>
        <string>CalDAV (demo@sogo-demo.de)</string>
        <key>PayloadIdentifier</key>
        <string>de.sogo-demo.demo.appleprofile.mailcowUI.CalDAV</string>
        <key>PayloadOrganization</key>
        <string></string>
        <key>PayloadType</key>
        <string>com.apple.caldav.account</string>
        <key>PayloadUUID</key>
        <string>C373EFF5-91C6-2779-9B2F-829C38B2E24B</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
      </dict>
      <dict>
        <key>CardDAVAccountDescription</key>
        <string>demo@sogo-demo.de</string>
        <key>CardDAVHostName</key>
        <string>netcup-sogo.de</string>
        <key>CardDAVPort</key>
        <integer>443</integer>
        <key>CardDAVPrincipalURL</key>
        <string>/SOGo/dav/demo@sogo-demo.de</string>
        <key>CardDAVUseSSL</key>
        <true/>
        <key>CardDAVUsername</key>
        <string>demo@sogo-demo.de</string>
                <key>CardDAVPassword</key>
        <string>demo</string>
                <key>PayloadDescription</key>
        <string>Configures CardDAV accounts</string>
        <key>PayloadDisplayName</key>
        <string>CardDAV (demo@sogo-demo.de)</string>
        <key>PayloadIdentifier</key>
        <string>de.sogo-demo.demo.appleprofile.mailcowUI.carddav</string>
        <key>PayloadOrganization</key>
        <string></string>
        <key>PayloadType</key>
        <string>com.apple.carddav.account</string>
        <key>PayloadUUID</key>
        <string>554461B9-2F4F-DA62-A2E4-F6AFACA3305C</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
      </dict>
          </array>
    <key>PayloadDescription</key>
    <string>IMAP, CalDAV, CardDAV with application password</string>
    <key>PayloadDisplayName</key>
    <string>demo@sogo-demo.de</string>
    <key>PayloadIdentifier</key>
    <string>de.sogo-demo.demo.appleprofile.mailcowUI</string>
    <key>PayloadOrganization</key>
    <string>mailcow UI</string>
    <key>PayloadRemovalDisallowed</key>
    <false/>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>C8956C05-7184-F366-76E5-CEA128729C99</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
  </dict>
</plist>

Christopher Zimmer how can you do that? Can you explain?

For me it was simple as I have phpMyAdmin to access the MySQL database directly.
For the dockerized mailcow installation something similar to the following two commands COULD work (taken from mailcow-reset-admin.sh helper script), but I can not test it, so please be warned:

docker exec -it $(docker ps -qf name=mysql-mailcow) mysql -u${DBUSER} -p${DBPASS} ${DBNAME} -e "UPDATE 'sogo_folder_info' SET 'c_path4' = 'Personal' WHERE 'sogo_folder_info'.'c_path' = '/Users/YOUREMAIL/Calendar/personal';"

docker exec -it $(docker ps -qf name=mysql-mailcow) mysql -u${DBUSER} -p${DBPASS} ${DBNAME} -e "UPDATE 'sogo_folder_info' SET 'c_path' = '/Users/YOUREMAIL/Calendar/Personal' WHERE 'sogo_folder_info'.'c_path' = '/Users/YOUREMAIL/Calendar/personal';"

You need to replace DBUSER, DBPASS and DBNAME with the values from your mailcow.conf as well as replace YOUREMAIL with the login (I would assume "info@it-service-kutter.de" in your case).
Same then again for the the other calendar 'inbox' in your case.

I tweaked the mobileconfig to use credentials for sogo1@example.com at demo.sogo.nu.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>PayloadContent</key>
    <array>
      <dict>
        <key>EmailAccountDescription</key>
        <string>sogo1@example.com</string>
        <key>EmailAccountType</key>
        <string>EmailTypeIMAP</string>
        <key>EmailAccountName</key>
        <string>DEMO</string>
        <key>EmailAddress</key>
        <string>sogo1@example.com</string>
        <key>IncomingMailServerAuthentication</key>
        <string>EmailAuthPassword</string>
        <key>IncomingMailServerHostName</key>
        <string>demo.sogo.nu</string>
        <key>IncomingMailServerPortNumber</key>
        <integer>993</integer>
        <key>IncomingMailServerUseSSL</key>
        <true/>
        <key>IncomingMailServerUsername</key>
        <string>sogo1@example.com</string>
        <key>IncomingPassword</key>
        <string>sogo</string>
        <key>OutgoingMailServerAuthentication</key>
        <string>EmailAuthPassword</string>
        <key>OutgoingMailServerHostName</key>
        <string>demo.sogo.nu</string>
        <key>OutgoingMailServerPortNumber</key>
        <integer>587</integer>
        <key>OutgoingMailServerUseSSL</key>
        <true/>
        <key>OutgoingMailServerUsername</key>
        <string>sogo1@example.com</string>
        <key>OutgoingPasswordSameAsIncomingPassword</key>
        <true/>
        <key>PayloadDescription</key>
        <string>Configures email account.</string>
        <key>PayloadDisplayName</key>
        <string>IMAP Account (sogo1@example.com)</string>
        <key>PayloadIdentifier</key>
        <string>de.sogo-demo.demo.appleprofile.mailcowUI.email</string>
        <key>PayloadOrganization</key>
        <string></string>
        <key>PayloadType</key>
        <string>com.apple.mail.managed</string>
        <key>PayloadUUID</key>
        <string>196DEC6F-5D24-44B4-BD62-96AE34CD9D06</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PreventAppSheet</key>
        <false/>
        <key>PreventMove</key>
        <false/>
        <key>SMIMESigningUserOverrideable</key>
        <true/>
        <key>SMIMESigningCertificateUUIDUserOverrideable</key>
        <true/>
        <key>SMIMEEncryptByDefaultUserOverrideable</key>
        <true/>
        <key>SMIMEEncryptionCertificateUUIDUserOverrideable</key>
        <true/>
        <key>SMIMEEnableEncryptionPerMessageSwitch</key>
        <true/>
      </dict>
      <dict>
        <key>CalDAVAccountDescription</key>
        <string>sogo1@example.com</string>
        <key>CalDAVHostName</key>
        <string>demo.sogo.nu</string>
        <key>CalDAVPort</key>
        <real>443</real>
        <key>CalDAVPrincipalURL</key>
        <string>/SOGo/dav/sogo1</string>
        <key>CalDAVUseSSL</key>
        <true/>
        <key>CalDAVUsername</key>
        <string>sogo1@example.com</string>
        <key>CalDAVPassword</key>
        <string>sogo</string>
        <key>PayloadDescription</key>
        <string>Configures CalDAV account.</string>
        <key>PayloadDisplayName</key>
        <string>CalDAV (sogo1@example.com)</string>
        <key>PayloadIdentifier</key>
        <string>de.sogo-demo.demo.appleprofile.mailcowUI.CalDAV</string>
        <key>PayloadOrganization</key>
        <string></string>
        <key>PayloadType</key>
        <string>com.apple.caldav.account</string>
        <key>PayloadUUID</key>
        <string>C373EFF5-91C6-2779-9B2F-829C38B2E24B</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
      </dict>
      <dict>
        <key>CardDAVAccountDescription</key>
        <string>sogo1@example.com</string>
        <key>CardDAVHostName</key>
        <string>demo.sogo.nu</string>
        <key>CardDAVPort</key>
        <integer>443</integer>
        <key>CardDAVPrincipalURL</key>
        <string>/SOGo/dav/sogo1</string>
        <key>CardDAVUseSSL</key>
        <true/>
        <key>CardDAVUsername</key>
        <string>sogo1@example.com</string>
        <key>CardDAVPassword</key>
        <string>sogo</string>
        <key>PayloadDescription</key>
        <string>Configures CardDAV account.</string>
        <key>PayloadDisplayName</key>
        <string>CardDAV (sogo1@example.com)</string>
        <key>PayloadIdentifier</key>
        <string>de.sogo-demo.demo.appleprofile.mailcowUI.carddav</string>
        <key>PayloadOrganization</key>
        <string></string>
        <key>PayloadType</key>
        <string>com.apple.carddav.account</string>
        <key>PayloadUUID</key>
        <string>554461B9-2F4F-DA62-A2E4-F6AFACA3305C</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
      </dict>
    </array>
    <key>PayloadDescription</key>
    <string>IMAP, CalDAV, CardDAV with application password</string>
    <key>PayloadDisplayName</key>
    <string>sogo1@example.com</string>
    <key>PayloadIdentifier</key>
    <string>de.sogo-demo.demo.appleprofile.mailcowUI</string>
    <key>PayloadOrganization</key>
    <string>mailcow UI</string>
    <key>PayloadRemovalDisallowed</key>
    <false/>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>C8956C05-7184-F366-76E5-CEA128729C99</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
  </dict>
</plist>

The mobileconfig is not working for me, but if I add the demo.sogo.nu with the usual settings directly, the same happens there as well: 'Personal' is not visible and a new 'Calendar' is created.

I also enabled all kind of logging in Calendar.app, but can't see any errors.... for my accounts with 'Personal' the calendar is created, but for the demo.sogo.nu it shows no errors, but only the one for 'inbox' and the newly created are are visible in the log....

@skutter
The 'inbox' renaming is not necessary/possible (as its a built-in one).

WARNING: Caveat of renaming both c_path and c_path4: WebUI can not create new appointments, as 'personal' seems hard-coded, so the call to '/SOGo/so/USERNAME/Calendar/personal/newguid' will receive a 404 as it should be now '/SOGo/so/USERNAME/Calendar/Personal/newguid'.
For me it is ok as I am not using the Web based UI. But of course may break things in other areas as well...

Automatic entry and acceptance of invites from other SOGo users will fail with renamed personal calendar.

It seems to still working when the OS got upgraded from Monterey to Ventura. As soon as you resetup the calendar in Calendar app or reinstall the computer from scratch the issue is reproduceable. Even if you use the new created calendar sync doesnt work correctly. Your appoints don't get synced when you import the ics file locally. Sometimes I get http 400 as an error message.

A workaround for not so big companies may be to export the actual calendar to an ics-file. Setup Calendar and let create the alternate calendar in SOGo. Then import the ics-file to the new calendar in the web gui. Then syncing between Calendar and SOGo works. But then you have to redo all the subscriptions if your colleges use shared calendars.

Some googleling yesterday reveiled some Exchange-server may also have problems with the new macOS and Calendar. It looks like Apple changed something in WebDAV and didnt tell the world.

@thoso +1

+1

Hi, on my side got no problem for adding SOGo caldav account to MacOS Ventura (13.0 (22A380)).
As I understand the issue is linked to the mobileconfig, so this issue should be opened on mailcow bts, nope ?

Sebastien

For me it is not tied to the mobileconfig, I also get the exact same when setting up the demo server account manually (see the screenshot from my post earlier).

For me its also a persistent problem over different sogo instances (at the work instance, at my private instance).
This sogo instances are standalone ones and not bundled with mailcow.

My co-workers have the same problem. When upgrading MacOS existing accounts are still working.
But new CalDAV and CardDAV accounts doesn't work anymore. Only macOS13 is affected.

Could you please provide how do you set the account in mac os ?

system settings -> Internetaccounts -> add account -> other -> CalDAV-Account:

account type: extended
server address: <domain.tld>
server path: /SOGo/dav/<username>/
server port: 443
use ssl?: yes

Ok this is really strange I can't reproduce on my dev env, but on demo it is effectively the case

I would like to specify: The account is accepted and created.
Subscribed calendars are also transferred.
However, we do not have access to our personal calendars.
A new calendar is simply created.

Also to mention: All attempts to trick the system and link the old calendar to the "new" one failed (renaming, symbolic link). Seems also Apple Calendar didnt sync at all because during testing I deleted my local Calendar Cache files and a lot of entries where gone.

Thanks all for reporting and explaining the issue. I have a small idea of what can cause this issue.
I'm currently working on other issues related to Apple's calendar, so I will take a look on that ;)

Sebastien

+1
thanks sebastien for looking into this.
it's a veritable annoyance

i checked, and (paid) 3rd party calendars would work fine, but no longer having access to the entire corporate agenda, meeting links etcpp is… well you imagine.

Hi everybody,

I have made a fix, will be available on next nightly build 5.8.0.20221207 (tomorrow).
I would like to get your feedback on this.

Sebastien

Yes, my private calendar is visible now.
Kind of. Appointments get syncronised, but uninportant stuff like the calendar color not.
After a few seconds the CalendarApp could not refresh data and throws an unexcpeted error with HTTP/400.

I already deleted all accounts and added them again.

I fixed this issue. You can try to install freshly built nightly to test.

Sebastien

I have the same issue and the fix does show the Personal calendar again, although without the calendar color.

I also have a problem that account delegation does not work, so I am unable to see calendars that are shared with me (see attached screenshot). "Accounts I can access:" is empty and clicking the "Edit" button to get to "Manage Account Access" shows "{" for Name.

Screenshot 2022-12-13 at 10.20.23.png (65,485 bytes)   

Screenshot 2022-12-13 at 10.20.23.png (65,485 bytes)   

For the color it should work. What version you are using ? What is the problem exactly ?
For the Manage Account Access, I was not able to find this window 0_o

Mac OS 13.0.1, Calendar 11.0, sogo 1.113
The account access area is through Settings > Accounts > Delegation

Screenshot 2022-12-14 at 10.29.58.png (179,631 bytes)   

Screenshot 2022-12-14 at 10.29.58.png (179,631 bytes)   

On my side everything works as expected. Did you tried on demo.sogo.nu ?
Could you also please try this :

• In SOGo, go to Preferences / Mail / IMAP
• Edit primary identity (the one with the heart) and change full name
• Save
• Close calendar / reopen calendar app

That procedure didn't have any effect on my calendars. I also upgraded to Mac OS 13.1 and no change.

"Did you tried on demo.sogo.nu ?"

Yes, shared calendars do not show up using demo.sogo.nu either.

I suppose I run into this problem when connecting the macOS calendar app (I just needed to reinstall macOS (13.1) from scratch) to SOGo (5.8 202212231701) now:
Personal calendar is loaded without the specific color, a second personal calendar is loaded with proper color. Shared/delegate calendars etc do not properly work/load.

Interestingly, the ToDos in the macOS Reminders app work without a problem.

The calendar app gives an error notification: "Your calendar couldn’t be refreshed. There was an unexpected error with the request (domain DAErrorDomain / error 6)."

Color is now fixed

Hi there

Is this fixed in 5.8.0? The version for demo.sogo.nu is named with 5.8.0 in https://demo.sogo.nu/SOGo/so/sogo1/Preferences#!/general

I assume it isn't released yet as this ticket is in an open state. Do you have an idea when this could be released?

Regards

Here is my tests on demo.sogo.nu :

Apple M1 Pro Mac OS Ventura 13.1 (22C65) / Chrome Version 108.0.5359.124 (Build officiel) (arm64)
SOGo 5.8.0.20230104-1

1. Login to webmail with sogo1
2. Share personal calendar to sogo3
3. Login to webmail with sogo3
4. Create another calendar called "Other calendar", change colors (red for personal, purple for other)
5. On MacOC, go to settings / account and create new caldav account (Advanced / sogo3 / sogo / demo.sogo.nu / /SOGo/dav/sogo3/ / 443 / SSL)
6. Open Calendar App, Menu Calendar, Settings, Account, demo.sogo.nu, Delegation and check sogo1
7. Create event in personal calendar
8. Create event in other calendar
9. Create event in delegation calendar
10. Change color of personal calendar (in Calendar App)
11. CMD + R to force refresh
12. Refresh SOGo web page

Pictures in attachement.

Everything works as expected, if you still have issue, please give the test case on demo.sogo.nu.

Sebastien

1.png (124,100 bytes)   

1.png (124,100 bytes)   

2.png (111,775 bytes)   

2.png (111,775 bytes)   

3.png (150,748 bytes)   

3.png (150,748 bytes)   

4.png (119,482 bytes)   

4.png (119,482 bytes)   

5.png (48,106 bytes)   

5.png (48,106 bytes)   

6.png (197,025 bytes)   

6.png (197,025 bytes)   

7.png (127,264 bytes)   

7.png (127,264 bytes)   

8.png (128,038 bytes)   

8.png (128,038 bytes)   

Hi @itvshn,

It will be still displayed 5.8.0 on demo.sogo.nu (until we release new version). However this platform is updated every night.
I can't put this ticket in resolved state until all users confirm that this issue is fixed in nightly.

So any feedback is welcome ;)

Sebastien

For me it's still not working as it should (and had before I needed to connect to the server again after reinstalling macOS).

So:

• still not the proper color on the personal calendar (grey)
• secondary calendar for the account has the proper color
• not all delegates visible
• no calendars visible for visible delegates
• error message in macOS Calendar: "There was an unexpected error with the request (domain DAErrorDomain / error 6)."

macOS 13.1
but:
SOGo nightly Version 5.8.0 (root@sogo-build.alinto.int 202301021701)

So I suppose I need to wait till tomorrow for an updated nightly, and I will test again

@jda Try on demo.sogo.nu

the demo sever appears to work, I will try my own again when the update is included in the nightly package (probably tomorrow then?)

Version 5.8.0.20230104-1 has been built today, and it's available.

If you still have the issue, could you :

• Provide SOGo logs with a maximum of debug parameters set to YES
• Try with a brand new account

I skipped the mirror repository I usually use, and tested version 5.8.0 (root@sogo-build.alinto.int 202301040338) now.

On my existing account the color is loaded correctly by macOS Calendar on the personal calendar again.

Also the list of delegates/premitted other users is complete now, before two users (read/write) were missing, one (read only) was missing, but (and of that I am not entirely sure anymore): flagged as read/write.

Unfortunately I do not have a lot of time for testing/debugging right now, I will see what I can do in the weekend.

To be clear, the calendars of the linked users are still not shown, and the error message "There was an ... DAErrorDomain / error 6)." persists

@jda It would be great if you can have more logs on the error message (sogo, calendar).

Hi @smizrahi,

I have had the problems described in this thread (inside Mailcow); but for me updating to the latest nightly build (from 6. January) works nicely and fixes the problems :) So for me, linked calendars etc all work again on nightly.

All the best,
Sebastian

Thanks Sebastian for the feedback !

I noticed also that when I create an event on Calendar, there is no invitation sent to participants. I'll have a look on that

Sebastien

Hey @smizrahi,

you are right, we also now have problems with the invitations; and we also get the attached error for many calendars (not sure yet why and which).

Anything I can do for you to help you debug this?

Tested with latest nightly.

All the best,
Sebastian

SCR-20230111-em1.png (95,788 bytes)   

SCR-20230111-em1.png (95,788 bytes)   

Noticed this bug today with our 5.8.0 instance to - it is completely random which and if calendars are detected. Also using manual and advanced setup results in completely different behaviors. At the moment it weirdly found my disabled calendar but not the active one, subscribed "resources" group calendars show up but are not syncable (unexpected error, access denied)...

Hi all,

Got no time to work on this at this moment, maybe next week.
I keep you informed ;)

Sebastien

Thanks for taking care and for the status update <3 All the best!

Not sure it's the right place for this but it may anyway help newbies like me should they stubled upon this post.

While it (the fix) is worked on, I set a quick workaround for my own SOGo CalDAV setup. It's ok for private use but don't think viable for an organization (company, school, etc) with loads of users.

1) Login the SOGo web interface with the account you are trying to get calendars for on your client (I'm on MAC OS 13.1 (22C65) Ventura , with the Apple Calendar app, so it's apply).
2) Select the "personal" calendar and "Export"
3) While still on the Web Interface, create a new calendar with a name to your liking, BUT with a capital letter (first position).
4) Import into it the exported personal calendar
Et voilà, at least you can get to your data. Just "untick" the kina broken "personal" calendar so it's gets not sync should the issue be resolved.
Option) Ask your fellow calendar subscribers to perform the same procedure.

KR

Hi all,

Thanks for your patience, I fixed the invitations and calendar entry for the attendee.
Let's try tomorrow's nightly build ;)

Sebastien

Hey @smizrahi,

thanks for your work! I removed the account from Apple Calendar and re-added it; and now I see the following error (see screenshot):

It seems that invitations seem to work again though ;)

Can I somehow provide some logs or so which help you to debug the issues further?

All the best,
Sebastian

image.png (197,967 bytes)   

image.png (197,967 bytes)   

SCR-20230119-r9l-2.png (197,136 bytes)   

SCR-20230119-r9l-2.png (197,136 bytes)   

Hey @smizrahi,

I can reproduce the issue on demo.sogo.nu as well (as of today).

steps I did:

• created an appointment in sogo1's calendar
• set the personal calendar of sogo1 to "readable for everybody on the same server (see screenshot)
• logged in as sogo2 - subscribed to sogo1's calendar. All appears in Sogo backend (see sceennshot)
• then added sogo2 to my mac OS calendar (see screenshot)
• then inside OSX Calendar preferences, added the calendar of sogo1 underneath delegation (see screenshot)
• then, there are two problems in the calendar:
  • the exclamation mark for sogo1/Kalender displays a message ("Calendar could not be created") - see screenshot
  • calendar entries from the "personal" calendar of sogo2 do not appear - see screenshot

This is the exact behavior we have in our local instance as well.

To me it also somehow makes sense: If you map "personal -> Personal" on the read side, I guess inside some request bodies, the reverse transformation needs to be done? (but that's just my guess, I am not familiar in the protocol in depth).

Can I do anything else to help fix this issue?

All the best,
Sebastian

SCR-20230124-alz.png (253,804 bytes)   

SCR-20230124-alz.png (253,804 bytes)   

SCR-20230124-an2.png (235,259 bytes)   

SCR-20230124-an2.png (235,259 bytes)   

SCR-20230124-anq.png (104,458 bytes)   

SCR-20230124-anq.png (104,458 bytes)   

SCR-20230124-ao6.png (123,240 bytes)   

SCR-20230124-ao6.png (123,240 bytes)   

SCR-20230124-aqu.png (152,892 bytes)   

SCR-20230124-aqu.png (152,892 bytes)   

Hi Sebastian,

Thanks for helping, I will take a look on this bug this week.
Do you have any other issue ?

Sebastien

Hey @smizrahi,

FYI: I am currently on parental leave - that's why I sometimes can't timely answer. My colleagues did not report any problems, apart from the stuff above (which, to be fair, currently blocks effective usage for us - but that's Apple to blame ;) )

BTW: the above stuff was tested on OSX 13.1. As Apple has released the update 13.2 today, I updated my Mac.

For 13.2, I believe the fix is not working anymore (as the headers have changed ) - see attached screenshots of mitmproxy. At first rough testing, I could not find any functional difference yet and the problem still seems to exist.

If it helps, I could also send you the mitmproxy logs - then you would be able to see the full interaction.

All the best,
Sebastian

Has anyone in this thread reported this problem to Apple using the Feedback Assistant (either the app or https://feedbackassistant.apple.com)?
I think it's clear that Apple messed this up, but they very likely ain't gonna fix it themselves in a timely manner.

Also, they use "iOS" in the user-agent for macOS, but use a different implementation on macOS vs. iOS?! This means that iOS 13 users (even though there probably won't be many) will also be targeted by this workaround...
Don't even want to know what kind of mess they have there...

Good point I opened a ticket : https://feedbackassistant.apple.com/feedback/11966088

On my side I have macOS/13 in the user agent. The several fixes for this only affects this user agent (https://github.com/Alinto/sogo/blob/03e6d0012bc0d6ba4d8cb427f8d904a75d9ce036/SoObjects/SOGo/WORequest%2BSOGo.m#L254)

However I'm on Mac OS X Ventura 13.1, I'm going to update to 13.2. This drives me crazy O_o

[EDIT] : After 13.2 update user agent is macOS/13.2 (22D49) dataaccessd/1.0

@smizrahi - sorry I made an mistake - you are right, my user agent is macOS/13.2 . And in the response it also says "Personal" as expected. Phew :D Probably I made a mistake tracing this due to sleep deprivation :D I have no clue how I was able to trace the iOS user agent previously...

The experienced problem is still as described above, though.

All the best,
Sebastian

Weird. I am debugging some more - and I really don't know webdav in detail or anything (BTW - any good docs you can recommend for me to read into?)

For a user I am having a read-only delegation (so I am allowed to read his calendar, as reproduced above wiht sogo1/sogo2), in the request log, a calendar UUID appears "out of nowhere" (and I cannot find any trace of this UUID in the log - that is weird)...

I'll try to investigate further once time permits. Maybe this helps to people more knowledgeable than me ;)

All the best,
Sebastian

Update. the request I highlighted above is a MKCALENDAR request - so I guess the UUID is invented by the client. Should this be this way or not? :)

I'm seeing exactly the same issue as @skurfuerst with delegated calendars which do not work anymore.

Does anyone know a good calendar alternative for MacOS until it's fixed? (I don't want to install Outlook just for a working calendar)

@jacotec Mozilla Thunderbird? Outlook isn't even compatible on macOS...

Mac 13.2 broke the previous fix. Now personal calendar disappeared once again.
I wait for Apple's feedback.

It seems that in 13.2 Calendar wants a full case folder name. Not personal, Personal but PERSONAL.
Made the fix in latest commit and personal folder came back to life once more.
I'm not really convinced by those fix - fortunately it is only applied for Mac OS 13 and does not impact other clients. The good way to resolve this would come from Apple.

Now I can take a look on delegated calendars.

Sebastien

you are my hero! great that you found this out - how did you do this? :)

keep up the great work!

@sebastien First of all a big thank you for all your work here!!!

What irritates me a bit is that (at least for me), SOGo is the only caldav server having this issue. I also have a NextCloud calendar account and that one works just fine.
Have you narrowed down what exactly is the problem?
Because I can create a calendar named personal in NextCloud and it appears perfectly fine in the macOS 13.2 Calendar.app.

I'm wondering whether it would be helpful to compare the requests/responses of a NextCloud Calendar instance with those SOGo generates to find out what's the issue?

I guess Nextcloud is using UID behind this. As far as I know, personal calendar is anchored in SOGo code (i.e. it is hardcoded). Others calendars are generated with UID.
Changing that means a deep rework (and I don't have the necessary background knowledge) and I'm a little bit afraid about impacts on existing calendars. In
But you're right this is a good question. Conversely, this is really strange that others clients (thunderbird, ...) doesn't complains.

If anybody can look for differences between Nextcloud and SOGo this will helps.

Sebastien

They don't, actually. The UUID stuff is something that iOS/macOS uses for creating new calendars. Not the stupidest of ideas.

Just to be sure, I've just enabled the Calendar app on another NextCloud instance and set it up. And the primary calendar is named... drumroll ..."personal"! And it syncs just fine with macOS Ventura...

Unfortunately I don't have the time at the moment to do a in-depth analysis of the requests/responses of SOGo vs. NextCloud. The responses are hard to compare due to differences in URL paths and ids. The only apparent difference I found was that NextCloud seems to support DAV 3 while SOGo uses DAV 2. Also, macOS asks NextCloud for the <C:invite xmlns:C="http://calendarserver.org/ns/"/> property in the PROPFIND, but doesn't ask that from SOGo. Don't know if that is even relevant, though.

@sebastien:

I just tried the latest nightly, and it again shows the personal calendar on OSX 13.2, AND it also shows delegated calendars for me again without errors... So that is really good :)

Is this reproducible for others as well? If so, we could consider this fixed.

All the best,
Sebastian

Thanks for the feedback Sebastian !

And I agree with @ffried. This is a temporary patch and we have to go deeper in the investigation. Maybe the DAV version is a good start.

Sebastien

After adding an account on build 202302010344 to macOS Calendar again, the display of the Personal Calendar color and contents is improved (but for some reason a second, greyed out, empty personal calendar has appeared, maybe an artifact of a previous connection, will look into that).

But the delegated still do not work properly, and the error "domain DAErrorDomain / error 6" mentioned before still appears. Unfortunately I am still very short on time to look into that...

@jda fixed this today (delegated calendar) and start a new build can you please try with next nightly build

Hey,

I somehow have to have some problems again since yesterday - this time both on iOS and on "some" calendars on Mac OS:

"Your Calendar could not be refreshed - DAErrorDomain / error 6"

That is really strange, as we did not change anything either on the client nor on the server (that we know of).

All the best <3
Sebastian

Do you have logs ?

Sebastien

any chance that the changes get released?

not sure whether the error from @skurfuerst is related to the initial request.
According to our tests our problem we had in the support ticket https://support.sogo.nu/view.php?id=5611 would be solved with a new release (tested in demo.sogo.nu)

Our problem description from there:

Mac Calendar Version 11.0 (2932)
Ventura 13.0.1

Personal Calendar cannot be synced to to Mac calendar.
Looks like Mac creates a calendar called "Calendar" in sogo after we connect to the calendar.

What is the proper way to connect the calendar to iPhone and Mac Calendars?

Steps To Reproduce

1. Add calendar in Mac with Automatic
2. Choose sogo.vshn.net and the correct username and password
3. Personal Calendar is not synced and somehow a new Calendar is created in sogo

Any chance to have a fix for that issue released in a 5.8.1?

Thanks
Daniel

Not sure to understand. Do you still have issues with nightly build (you can do some test on demo.sogo.nu) ?

Sebastien

Sorry for being confusing :-)

Our problem (https://support.sogo.nu/view.php?id=5611) is solved on demo.sogo.nu. So I'm looking forward that you release the changes officially it will be rolled out to our servers.

So any chance, that you could release this fix anytime soon? :-)

Thanks for your work

No problem ! The official 5.8.1 will be released at the end of the month and will be announced at the SOGo days.

Sebastien

Hi @itvshn you're describing what sounds like an issue I'm having. New M2 Mac, macOS 13.2.1, Calendar 11.0 (2932.3.4).

Cannot add/sync calendars to Calendar correctly. I get a calendar called "Calendar" appearing but this is the wrong name, no events are synced, and it has this error: "Your calendar couldn’t be created. The calendar “Calendar” could not be created on the server with an unexpected error. This is not a location that supports this request."

Is this the same problem as yours? I don't see a fix listed for it in 5.8.1

Yesterday we installed sogo 5.8.2, we have some similar error as above @christian has print screened.
There is just an exclamation mark after the calendar and nothing can be synced. Unfortunately it works on demo.sogo.nu, so perhaps something on our sind.

Client is:
OS: Ventura 13.2.1 (22D68)
Calendar: 11.0 (2932.3.4)

Logs on Client:

default 10:51:08.816040+0200    Calendar    order window front conditionally: 1563f related: 0
default 10:51:09.079489+0200    Calendar    order window: 15685 op: 0 relative: 0 related: 0
default 10:51:09.081295+0200    Calendar    order window: 15685 op: 0 relative: 0 related: 0
default 10:51:09.095500+0200    Calendar    <private>
default 10:51:09.095582+0200    Calendar    <private>
default 10:51:09.096597+0200    Calendar    Notification monitor wants to reload notifications. Will fetch notification references from the event store as a result.
default 10:51:09.096649+0200    Calendar    Fetching event notifications from event store: <private>.
default 10:51:09.097951+0200    Calendar    Fetched event notifications from event store: <private>.
default 10:51:09.098000+0200    Calendar    Set notification references to <private>.
default 10:51:09.098023+0200    Calendar    Current notification count: 0. Last event notification count: 0.
default 10:51:09.098043+0200    Calendar    Is initial check: NO.
default 10:51:09.137842+0200    Calendar    <private>
default 10:51:09.139017+0200    Calendar    <private>
default 10:51:09.140019+0200    Calendar    <private>
default 10:51:09.142575+0200    Calendar    <private>
default 10:51:09.144543+0200    Calendar    <private>
default 10:51:09.146625+0200    Calendar    <private>
default 10:51:09.240397+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:09.240439+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:09.240464+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:09.327600+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:09.327653+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:09.327703+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:11.214405+0200    Calendar    order window front conditionally: 1563f related: 0
default 10:51:11.217053+0200    Calendar    order window: 15686 op: 1 relative: 1563f related: 0
default 10:51:11.483361+0200    Calendar    order window: 15686 op: 1 relative: 1563f related: 0
default 10:51:11.888649+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:11.888721+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:11.888757+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:11.968360+0200    Calendar    <private>
error   10:51:12.834353+0200    Calendar    "Error returned from daemon: Error Domain=com.apple.accounts Code=6"
default 10:51:13.041254+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:13.041349+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:13.041380+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:13.137098+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:14.394989+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:14.395076+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:14.395104+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:14.426758+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:14.687931+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:14.784892+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:15.111275+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:15.412516+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:15.432252+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:15.472907+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:15.703533+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:15.783117+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:16.018817+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:16.361391+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:16.509108+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:16.524920+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:16.658026+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:16.858097+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:17.021702+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:17.036463+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:17.166634+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:17.563858+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:17.840226+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:18.104537+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:18.219058+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:18.320077+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:18.504759+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:18.678067+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:18.761909+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:18.952399+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:19.479950+0200    Calendar    order window: 15687 op: 0 relative: 0 related: 0
default 10:51:19.504606+0200    Calendar    order window: 15686 op: 1 relative: 1563f related: 0
default 10:51:19.506067+0200    Calendar    order window: 15688 op: 1 relative: 15686 related: 0
default 10:51:19.506772+0200    Calendar    +[CATransaction synchronize] called within transaction
default 10:51:19.507467+0200    Calendar    order window front conditionally: 15688 related: 0
default 10:51:23.821827+0200    Calendar    order window: 15688 op: 0 relative: 0 related: 0
default 10:51:28.731909+0200    Calendar    order window front conditionally: 15686 related: 0
default 10:51:28.732017+0200    Calendar    order window: 1563f op: -1 relative: 15686 related: 0
default 10:51:28.773564+0200    Calendar    order window front conditionally: 15686 related: 0
default 10:51:30.601381+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.601444+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.601509+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.601561+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.601613+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.601666+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.601728+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.601794+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.601876+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.601973+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.602047+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.602093+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:30.602099+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:31.946746+0200    Calendar    [com.apple.calendar.accounts.ui] [saveAccount: called for c*****r@vshn.net (4******E).]
default 10:51:31.946827+0200    Calendar    [com.apple.calendar.accounts.ui] [Setting the following values on the account:
hostname = (null)
port = (null)
useSSL = YES]
default 10:51:31.963576+0200    Calendar    <private>
default 10:51:31.963654+0200    Calendar    <private>
default 10:51:31.963689+0200    Calendar    <private>
default 10:51:31.963766+0200    Calendar    "Starting credential verification for account <private>."
default 10:51:32.414160+0200    Calendar    "Completed account credential verification: <private> - (null)."
default 10:51:32.414870+0200    Calendar    "Checking save eligibility of account <private>."
default 10:51:32.430548+0200    Calendar    "Completed checking save eligibility: YES - (null)."
default 10:51:32.430711+0200    Calendar    "Starting save for account <private>."
default 10:51:32.514137+0200    Calendar    <private>
default 10:51:32.514214+0200    Calendar    <private>
default 10:51:32.530314+0200    Calendar    "Completed account save: YES - (null)."
default 10:51:32.536674+0200    Calendar    order window front conditionally: 1563f related: 0
default 10:51:32.583592+0200    Calendar    <private>
default 10:51:32.585531+0200    Calendar    <private>
default 10:51:32.587852+0200    Calendar    <private>
default 10:51:32.591531+0200    Calendar    <private>
default 10:51:32.595489+0200    Calendar    <private>
default 10:51:32.599004+0200    Calendar    <private>
default 10:51:32.601747+0200    Calendar    <private>
default 10:51:32.699170+0200    Calendar    order window: 15686 op: 0 relative: 0 related: 0
default 10:51:32.700705+0200    Calendar    <private>
default 10:51:32.714128+0200    Calendar    Notification monitor wants to reload notifications. Will fetch notification references from the event store as a result.
default 10:51:32.714169+0200    Calendar    Fetching event notifications from event store: <private>.
default 10:51:32.715563+0200    Calendar    Fetched event notifications from event store: <private>.
default 10:51:32.715600+0200    Calendar    Set notification references to <private>.
default 10:51:32.715621+0200    Calendar    Current notification count: 0. Last event notification count: 0.
default 10:51:32.715640+0200    Calendar    Is initial check: NO.
default 10:51:32.865458+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:32.865521+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:32.865550+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:32.978481+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:32.978579+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:32.978621+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:34.010258+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:34.010380+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:34.010412+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:36.543616+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:36.543674+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:36.543704+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:36.933839+0200    Calendar    <private>
default 10:51:36.933931+0200    Calendar    <private>
default 10:51:37.001744+0200    Calendar    <private>
default 10:51:37.003267+0200    Calendar    <private>
default 10:51:37.005150+0200    Calendar    <private>
default 10:51:37.007350+0200    Calendar    <private>
default 10:51:37.009325+0200    Calendar    <private>
default 10:51:37.011425+0200    Calendar    <private>
default 10:51:37.012573+0200    Calendar    <private>
default 10:51:37.150707+0200    Calendar    Notification monitor wants to reload notifications. Will fetch notification references from the event store as a result.
default 10:51:37.150738+0200    Calendar    Fetching event notifications from event store: <private>.
default 10:51:37.152368+0200    Calendar    Fetched event notifications from event store: <private>.
default 10:51:37.152410+0200    Calendar    Set notification references to <private>.
default 10:51:37.152431+0200    Calendar    Current notification count: 0. Last event notification count: 0.
default 10:51:37.152451+0200    Calendar    Is initial check: NO.
default 10:51:37.283446+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:37.283478+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:37.283493+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:37.317110+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:37.317147+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:37.317162+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:38.374613+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:38.374660+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:38.374686+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:39.161082+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:41.224304+0200    Calendar    order window: 1563f op: 0 relative: 0 related: 0
default 10:51:45.916336+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944045+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944055+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944055+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944128+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944204+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944283+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944401+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944485+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944542+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944624+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944704+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944761+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944814+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:45.944864+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:51:46.790165+0200    Calendar    Setting spinner updating now for controller 0x7fa80d90a440 to YES
default 10:51:46.802856+0200    Calendar    Started a refresh of 12 accounts and 6 subscribed calendars
default 10:51:46.968586+0200    Calendar    -[EKAccountRefresher _eventStoreChanged], and _currentlySyncing is still NO (sources=NO; calendars=NO)
default 10:51:46.992289+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:46.992361+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:46.992383+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:48.621943+0200    Calendar    -[EKAccountRefresher _eventStoreChanged], and _currentlySyncing changed from NO to YES (sources=YES; calendars=NO)
default 10:51:48.622077+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:48.622154+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:48.622190+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:51.400413+0200    Calendar    -[EKAccountRefresher _eventStoreChanged], and _currentlySyncing is still YES (sources=YES; calendars=NO)
default 10:51:51.400752+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:51.400949+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:51.401060+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
error   10:51:52.620836+0200    Calendar    Daemon died, cleaning up.
default 10:51:52.758477+0200    Calendar    -[EKAccountRefresher _eventStoreChanged], and _currentlySyncing is still YES (sources=YES; calendars=NO)
default 10:51:52.758613+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:52.758671+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:51:52.758690+0200    Calendar    [com.apple.calendar.ui.log.autoNobo] [Items in nobo badge count: 0]
default 10:52:02.430531+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:52:02.430530+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:52:07.736783+0200    Calendar    CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces, or set CA_ASSERT_MAIN_THREAD_TRANSACTIONS=1 to abort when an implicit transaction isn't created on a main thread.
default 10:52:16.793792+0200    Calendar    _refreshControlMaximumVisibleTimeElapsed; calling sync completed
default 10:52:16.793991+0200    Calendar    Hiding sync spinner after 30.000604s
default 10:52:16.794092+0200    Calendar    Setting spinner updating now for controller 0x7fa80d90a440 to NO
default 10:52:22.279812+0200    Calendar    "The connection to ACDAccountStore was invalidated."
default 10:52:22.279836+0200    Calendar    "The connection to ACDAccountStore was invalidated."

Logs on /var/log/sogo.log:

Apr 05 13:17:23 sogod [1212]: [WARN] <0x0x7f271e873f60[WOxElemBuilder]> could not locate builders: WOxExtElemBuilder,WOxExtElemBuilder
Apr 05 13:17:23 sogod [1212]: 127.0.0.1 "GET /SOGo/ HTTP/1.0" 200 2593/0 0.022 - - 1M - 14
Apr 05 13:18:20 sogod [1212]: 127.0.0.1 "GET /SOGo/ HTTP/1.0" 200 2593/0 0.003 - - 0 - 14
Apr 05 13:18:36 sogod [1212]: [ERROR] <0x0x5622582f2be0[WOHttpTransaction]> client disconnected during delivery of response for <WORequest[0x0x56225830a1e0]: method=POST uri=/SOGo/so/c*********r/Mail/0/folderINBOX/expunge app=SOGo rqKey=so rqPath=christian.haeusler/Mail/0/folderINBOX/expunge> (len=54): the socket was shutdown
Apr 05 13:18:36 sogod [1212]: 127.0.0.1 "POST /SOGo/so/christian.haeusler/Mail/0/folderINBOX/expunge HTTP/1.0" 200 54/0 0.147 - - 0 - 15

Any idea how we could get Mac Calendar working with SOGo?

Damn, so not even fixed in 5.8.2

5.8.2 fixed, but delegates still not work. Stupid bugged iCalendar -_-
It tries to create new calendar collection when subscribed another calendar, getting 403 responce (thats right, because user cannot create new calendar not into personal caldav collection), and shows Access denied error.

Example:

192.168.13.57 - <user_login> [06/Apr/2023:11:17:38 +0300] "MKCALENDAR /SOGo/dav/<delegate>/Calendar/CC0918A8-3BDD-482C-8D70-E28E5EA14E0F/ HTTP/1.1" 403 0 "-" "macOS/13.0.1 (22A400) dataaccessd/1.0" "10.0.105.36"

Hi all, that's strange I have tested it and everything worked :( . I will have a look on that, but I'm away until two weeks.

Sebastien

Hi Sebastien

Thanks for having a look on that. We meanwhile tried to reproduce it. We were able to reproduce it on our system. But it looks like there was some difference with old an new accounts (referenced as olduser and new.testuser below).
The olduser exists since about 3 years, the test.user is new and was created probably after we installed 5.8.0 of sogo.

Our findings:

• olduser: Add calendar to mac while having shared calendars does not work.
• olduser: Remove all shared calendars in SOGo, now add SOGo calendar to mac works.
• olduser: Add again shared calendars in SOGo, now cannot add calendar to mac any more.
• olduser: Add shared calendars while SOGo is connected with mac works.
• new.testuser: add SOGo calendar to mac works.
• new.testuser: add SOGo calendar to mac with shared calendars works.
• new.testuser & olduser: once the SOGo calendar is connected with mac there is no limit for shared calendars.

Unfortunately we were not able to reproduce that on demo.sogo.nu.

Does our pattern help you to find the bug?
What could be the difference between the old user and the new user? Is there something in the Database (we use postgres as backend) which we could check, why the calendar could be broken for olduser?
That pattern above was verified with 2 completely different profile on on test Mac, so we think there's no caching issue on client side.

Best Regards and thank for your support.

Hi @itvshn,

So I have tested delegated calendar and works well on my side (Mac OS 13.3 (22E252) - Calendar Version 11.0 (2932.4.5)).
As I understand, you don't have issues with new CALDav account added in mac os, right ?

For old accounts, I think the problem is personal folder has been renamed to PERSONAL so it may cause some issues. Can you removed and re add the account ?

Sebastien

As I understand, you don't have issues with new CALDav account added in mac os, right ?
We don't have problems with a new SOGo user. We add this user to the MacOS calendar and don't have issues.
If we use a SOGo account from one of our employees who exists longer, then we have issues adding it to MacOS calendar.

problem is personal folder has been renamed to PERSONAL

Do I understand it correctly, that the personal folder in SOGo was renamed to PERSONAL? Where would I find that PERSONAL folder on a Linux SOGo Server?

Can you removed and re add the account ?
Not that easy, all our employees have their calendars on SOGo, we would lose some date if we remove the accounts.
But could be an approach to export all calendar entries, delete the SOGo account, and import the calendar entries.

Ok, so it's time to get a summary about this :)

The issue

Personal Calendar doesn't work with Calendar on Mac OS 13 (Ventura)

Initially in https://bugs.sogo.nu/view.php?id=5639#c16371, Christopher has investigated the issue and noticed that if the personal calendar starts with a lower case personal calendar doesn't appear in Apple's Calendar. There was no changes on that side from SOGo.

Note that personal calendar is hardcoded in SOGo.

Later, (https://bugs.sogo.nu/view.php?id=5639#c16607) the fix has been modified to PERSONAL due to new Apple changes after Ventura's update.

The temporary fix

The patch done in SOGo 5.8.2 is to change "on the fly" personal with PERSONAL. This change is applied depending on user agent (https://github.com/Alinto/sogo/blob/03e6d0012bc0d6ba4d8cb427f8d904a75d9ce036/SoObjects/SOGo/WORequest%2BSOGo.m#L252) - that's why I said it may cause issues with existing calendars and you have to remove / re add accounts.
I mean for others platforms than Calendar in Mac OS X Ventura it will still be personal.

Keep in mind that this code is NOT definitive.

The next steps

As ffried said in https://bugs.sogo.nu/view.php?id=5639#c16615, we have to go deeper in the investigation - as Nextcloud works well with a personal folder. I have opened an issue to Apple, but for an unknown reason they said that the logs doesn't have the trace of the issue (?).
A clue would be CALDAV version (https://bugs.sogo.nu/view.php?id=5639#c16615).

However this is not in the short priority list for now. That's why I would like to provide a quick fix and this ticket has not been marked as resolved.

Sebastien

Hi @sebastien,
I'm getting the same problem with Mac OS 12.5.1 (21G83) and Calendar 11.0 (2855.6.1) too.
Maybe, if present in user agent string, as temporary fix we should filter Calendar version instead of Mac Os version.

Unfortunately, the version of calendar is not sent through user agent macOS/13.3 (22E252) dataaccessd/1.0.
Please provide yours.

Sebastien

I think you are right, Sebastien. Mine is "macOS/12.5.1 (21G83) accountsd/113"

But, since I'm having troubles with Mac OS 13 "macOS/13.3.1 (22E261) accountsd/1.0" too which should work with SoGo 5.8.2 , I'm investigating further.

Did you removed and re add your account ?

Yep, removed with "sogo-tool remove user" and readded by logging in webmail. When tried to add calendar I got return code 501

Nope, you have to remove account in MacOS settings and re add. Maybe uncheck and recheck calendar button (as in the screenshot) also fix the issue (try this first)

Capture d’écran 2023-04-26 à 16.14.07.png (223,187 bytes)   

Capture d’écran 2023-04-26 à 16.14.07.png (223,187 bytes)   

Oooops, I definitely misunderstood your point. I didn't have the account configured before.
Trying to configure the account I don't know if I have to copy the caldav url from web ui as is (with "personal" in lower case), or if I have to change it with "PERSONAL" in uppercase.
Tried both and both failed, but in different manner.
These are relevant logs from reverse proxy in both cases:
<code>
xx.yy.zz.tt - - [26/Apr/2023:18:11:38 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/personal/ HTTP/1.1" 401 0 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - myuser [26/Apr/2023:18:11:38 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/personal/ HTTP/1.1" 207 726 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - - [26/Apr/2023:18:11:38 +0200] "OPTIONS /SOGo/dav/myuser/ HTTP/1.1" 401 0 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - myuser [26/Apr/2023:18:11:38 +0200] "OPTIONS /SOGo/dav/myuser/ HTTP/1.1" 200 0 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - - [26/Apr/2023:18:11:38 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/personal/ HTTP/1.1" 401 0 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - myuser [26/Apr/2023:18:11:38 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/personal/ HTTP/1.1" 207 726 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - - [26/Apr/2023:18:11:39 +0200] "OPTIONS /SOGo/dav/myuser/ HTTP/1.1" 401 0 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - myuser [26/Apr/2023:18:11:39 +0200] "OPTIONS /SOGo/dav/myuser/ HTTP/1.1" 200 0 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - - [26/Apr/2023:18:11:39 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/personal/ HTTP/1.1" 401 0 "-" "macOS/13.3.1 (22E261) dataaccessd/1.0"
xx.yy.zz.tt - myuser [26/Apr/2023:18:11:40 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/personal/ HTTP/1.1" 404 90 "-" "macOS/13.3.1 (22E261) dataaccessd/1.0"
xx.yy.zz.tt - - [26/Apr/2023:18:12:00 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/personal/ HTTP/1.1" 401 0 "-" "macOS/13.3.1 (22E261) dataaccessd/1.0"
xx.yy.zz.tt - myuser [26/Apr/2023:18:12:00 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/personal/ HTTP/1.1" 404 90 "-" "macOS/13.3.1 (22E261) dataaccessd/1.0"

xx.yy.zz.tt - - [26/Apr/2023:18:13:47 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/PERSONAL/ HTTP/1.1" 401 0 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - myuser [26/Apr/2023:18:13:47 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/PERSONAL/ HTTP/1.1" 404 90 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - - [26/Apr/2023:18:14:30 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/PERSONAL/ HTTP/1.1" 401 0 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
xx.yy.zz.tt - myuser [26/Apr/2023:18:14:30 +0200] "PROPFIND /SOGo/dav/myuser/Calendar/PERSONAL/ HTTP/1.1" 404 90 "-" "macOS/13.3.1 (22E261) accountsd/1.0"
</code>
As you can see it first tries with "accountsd" in user agent, it returns code 207 and "seems" to work. Then it tries again with different user agent, i.e. "dataaccessd" in user agent and it gets a 404 status code. Looking at the patch you linked before it seems you are matching just user agents matching "dataaccessd" while I suspect it should match both. I'll do some tests, try to patch your patch and see if it fixes my problem

You can read https://bugs.sogo.nu/view.php?id=5639#c16523 for configuration. Test with demo.sogo.nu check https://bugs.sogo.nu/file_download.php?file_id=2680&amp;type=bug

Thank you so much @sebastien! Tried with your instructions and it worked like a charm, both with demo.sogo.nu and our sogo instance. FYI the error was that I appended the calendar name "personal/" or "PERSONAL/" to the path, removing it fixed the issue.

Great !

It seems that CalDAV is broken again in the current macOS14 beta 4 version.
Even if this message shows up in beta status, it may be something that can be taken into account early on and not become an issue when the OS is released.

Photo_Calendar-App.jpg (182,296 bytes)   

Photo_Calendar-App.jpg (182,296 bytes)   

standard	17:23:22.422658+0200	Calendar	[0.3669] [0.0049] [main] <private>
standard	17:23:22.423579+0200	calaccessd	[0x122d28240] invalidated after getting a no-senders notification - client is gone
standard	17:23:22.425860+0200	Calendar	[0x1376c7250] activating connection: mach=true listener=false peer=false name=com.apple.SharedWebCredentials
standard	17:23:22.435137+0200	Calendar	[0.3794] [0.0125] [main] <private>
standard	17:23:22.441718+0200	Calendar	[0.3860] [0.0066] [main] <private>
standard	17:23:22.441926+0200	Calendar	[0.3862] [0.0002] [main] <private>
standard	17:23:22.442121+0200	Calendar	[0.3864] [0.0002] [main] <private>
standard	17:23:22.442166+0200	Calendar	[0.3865] [0.0000] [main] FINISHED DISPLAYING VISIBLE EVENTS: All visible occurrence containers have populated their UI!
standard	17:23:22.442353+0200	Calendar	[0.3866] [0.0002] [main] <private>
standard	17:23:22.449162+0200	Calendar	[0.3934] [0.0068] [bg  ] <private>
standard	17:23:22.450124+0200	Calendar	[0.3944] [0.0010] [bg  ] <private>
standard	17:23:22.452404+0200	Calendar	[0.3967] [0.0023] [bg  ] <private>
standard	17:23:22.505351+0200	Calendar	[0x600000628000] activating connection: mach=false listener=false peer=false name=com.apple.ViewBridgeAuxiliary
standard	17:23:22.505526+0200	Calendar	[0x1410735f0] activating connection: mach=false listener=false peer=false name=(anonymous)
standard	17:23:22.505953+0200	Calendar	[0x141066990] activating connection: mach=false listener=true peer=false name=(anonymous)
standard	17:23:22.506160+0200	Calendar	[0x600000628000] invalidated after the last release of the connection object
standard	17:23:22.508224+0200	Calendar	[0x141062370] activating connection: mach=true listener=false peer=false name=com.apple.coreservices.lsuseractivitymanager.xpc
standard	17:23:22.508243+0200	Calendar	[0x137767ea0] activating connection: mach=true listener=false peer=false name=com.apple.synapse.backlink-service
standard	17:23:22.605221+0200	Calendar	ENCODE: Caching encoded userInfo to use until we are marked dirty again, returning encoded result <private> opts={ LSUserActivityContainsFileProviderURL = 0; LSUserActivityContainsUnsynchronizedCloudDocs = 0; UAUserActivityContainsCloudDocsKey = 0;}
standard	17:23:22.612747+0200	com.apple.CalendarWeatherKitService	[0x1239cf480] activating connection: mach=false listener=true peer=false name=com.apple.CalendarWeatherKitService
standard	17:23:22.638854+0200	com.apple.CalendarWeatherKitService	[0x122798150] activating connection: mach=false listener=false peer=true name=com.apple.CalendarWeatherKitService.peer.0x122798150
fehler	17:23:22.642618+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.642654+0200	com.apple.CalendarWeatherKitService	We received an empty location when looking up historical weather so we will return nil results.
fehler	17:23:22.643538+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.643609+0200	com.apple.CalendarWeatherKitService	We received an empty location when looking up historical weather so we will return nil results.
fehler	17:23:22.644006+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.644032+0200	com.apple.CalendarWeatherKitService	We received an empty location when looking up historical weather so we will return nil results.
fehler	17:23:22.644171+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.644269+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.644486+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.644579+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.644865+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.644913+0200	com.apple.CalendarWeatherKitService	We received an empty location when looking up almanac weather so we will return nil results.
fehler	17:23:22.645004+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.645258+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.645328+0200	com.apple.CalendarWeatherKitService	We received an empty location when looking up almanac weather so we will return nil results.
fehler	17:23:22.645704+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.645729+0200	com.apple.CalendarWeatherKitService	We received an empty location when looking up almanac weather so we will return nil results.
fehler	17:23:22.646080+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.646142+0200	com.apple.CalendarWeatherKitService	We received an empty location when looking up almanac weather so we will return nil results.
fehler	17:23:22.646487+0200	com.apple.CalendarWeatherKitService	We received an empty location coordinate (0,0) when looking up weather so we will return nil results.
fehler	17:23:22.646544+0200	com.apple.CalendarWeatherKitService	We received an empty location when looking up almanac weather so we will return nil results.
standard	17:23:22.766406+0200	dataaccessd	This account is enabled for events, but has no event calendar. We're going to create a default one
standard	17:23:22.767009+0200	dataaccessd	******Creating calendar with url <private> (
	0   DACalDAV                            0x000000020309de54 -[MobileCalDAVCalendar initCalCalendarWithTitle:] + 836
	1   DACalDAV                            0x0000000203097a20 -[MobileCalDAVCalendar initWithCalendarURL:calendar:principal:title:] + 348
	2   DACalDAV                            0x00000002030951f0 -[MobileCalDAVPrincipal calendarOfType:atURL:withOptions:] + 292
	3   CalDAV                              0x00000001a55a1790 -[CalDAVCalendarPropertyRefreshOperation _getDefaultMkCalendarForPrincipalTaskGroup:isEventCalendar:] + 200
	4   CalDAV                              0x00000001a55a1b40 -[CalDAVCalendarPropertyRefreshOperation _getDefaultCalendarsTasksIfNeededForPrincipal:] + 384
	5   CalDAV                              0x00000001a55a164c -[CalDAVCalendarPropertyRefreshOperation _continueHandleContainerInfoTask:completedWithContainers:error:] + 2260
	6   CalDAV                              0x00000001a55a22e8 -[CalDAVCalendarPropertyRefreshOperation containerInfoTask:completedWithCo
standard	17:23:23.025083+0200	Calendar	ENCODE: Caching encoded userInfo to use until we are marked dirty again, returning encoded result <private> opts={ LSUserActivityContainsFileProviderURL = 0; LSUserActivityContainsUnsynchronizedCloudDocs = 0; UAUserActivityContainsCloudDocsKey = 0;}
fehler	17:23:23.398128+0200	dataaccessd	CalDAVMkcalendarTask failed: Error Domain=CoreDAVHTTPStatusErrorDomain Code=403 UserInfo={CoreDAVHTTPHeaders=<private>}
fehler	17:23:23.398338+0200	dataaccessd	Encountered an error while creating a calendar. error = Error Domain=CoreDAVHTTPStatusErrorDomain Code=403 UserInfo={CoreDAVHTTPHeaders=<private>}; failing calendar = <private>; failing task group = <private>
standard	17:23:23.398533+0200	dataaccessd	Ignoring 403 performing mkcalendar because the URL already looks like one we generated.
standard	17:23:23.399816+0200	dataaccessd	Commencing database save for client with identifier [com.apple.dataaccessd-B1BA93A3-1D8C-4379-8B24-AF1687F9EAC9], name [dataaccessd].  Commit: [YES]
standard	17:23:23.400063+0200	dataaccessd	Summary of changes being saved: Calendar (add: 1 mod: 0 del: 1)
standard	17:23:23.400103+0200	dataaccessd	Summary of changes being saved: Error (add: 1 mod: 0 del: 0)
standard	17:23:23.401712+0200	dataaccessd	Allowing reload for changeType ChangeTypeAdded because calendar has dirty instance attributes
standard	17:23:23.402782+0200	dataaccessd	Client dataaccessd (com.apple.dataaccessd-B1BA93A3-1D8C-4379-8B24-AF1687F9EAC9) is adding a calendar with properties: [rowid=-1, title=DEFAULT_CALENDAR_NAME, external_id=<private>, external_mod_tag=(null), external_id_tag=02B1F623-625E-49CC-9A6D-7A2E0233C28E, UUID=BE2F5634-6BEC-4F57-894D-44C21DA7FE27, sync_token=(null)]
standard	17:23:23.402940+0200	calaccessd	Forwarding darwin notifications to modules.
standard	17:23:23.403038+0200	calaccessd	Sync started. Suppressing notification monitor checks while it runs.
standard	17:23:23.403148+0200	calaccessd	Sync started. Suppressing updates while it runs.
standard	17:23:23.403332+0200	calaccessd	Received notification: [CalSyncClientBeginningMultiSave].
standard	17:23:23.403397+0200	calaccessd	Forwarded darwin notification named: CalSyncClientBeginningMultiSave to module: <private>.
standard	17:23:23.403508+0200	calaccessd	Forwarded darwin notification named: CalSyncClientBeginningMultiSave to module: <private>.
standard	17:23:23.403523+0200	calaccessd	Installing sync yield timer for travel engine: [<private>].
standard	17:23:23.403597+0200	calaccessd	Installed sync yield timer with [240] second length for travel engine: [<private>].
standard	17:23:23.403661+0200	calaccessd	Finished forwarding darwin notifications to modules.
standard	17:23:23.406918+0200	dataaccessd	Reloading widget timeline because of database change notification
standard	17:23:23.407613+0200	chronod	Received request to reload [com.apple.iCal.CalendarWidgetExtension:com.apple.CalendarWidget.CalendarUpNextWidget] - (allowCostOverride: true) from <BSProcessHandle: 0x600003e64b10; dataaccessd:1506; valid: YES>
standard	17:23:23.408094+0200	chronod	Received request to reload [com.apple.iCal.CalendarWidgetExtension:com.apple.CalendarWidget.CalendarListWidget] - (allowCostOverride: true) from <BSProcessHandle: 0x600003e64b10; dataaccessd:1506; valid: YES>
standard	17:23:23.411031+0200	com.apple.dock.extra	[0x129f05290] activating connection: mach=true listener=false peer=false name=com.apple.CalendarAgent
standard	17:23:23.411739+0200	Calendar	Notification monitor wants to reload notifications. Will fetch notification references from the event store as a result.
standard	17:23:23.411812+0200	Calendar	Fetching event notifications from event store: <private>.
standard	17:23:23.412439+0200	Calendar	[1.3567] [0.9600] [main] <private>
standard	17:23:23.413713+0200	Calendar	[1.3580] [0.0013] [main] <private>
standard	17:23:23.415396+0200	calaccessd	Skipping suggestion resource change notification 79 because it is an add without an event
standard	17:23:23.415541+0200	calaccessd	Skipping suggestion resource change notification 85 because it is an add without an event
standard	17:23:23.415644+0200	calaccessd	Skipping suggestion resource change notification 89 because it is an add without an event
standard	17:23:23.415734+0200	calaccessd	Skipping suggestion resource change notification 90 because it is an add without an event
standard	17:23:23.416182+0200	calaccessd	Skipping suggestion resource change notification 101 because it is an add without an event
standard	17:23:23.416269+0200	calaccessd	Skipping suggestion resource change notification 118 because it is an add without an event
standard	17:23:23.414959+0200	Calendar	[1.3592] [0.0012] [main] <private>
standard	17:23:23.416366+0200	calaccessd	Skipping suggestion resource change notification 253 because it is an add without an event
standard	17:23:23.416568+0200	calaccessd	Skipping suggestion resource change notification 278 because it is an add without an event
standard	17:23:23.416738+0200	calaccessd	Skipping suggestion resource change notification 323 because it is an add without an event
standard	17:23:23.416974+0200	calaccessd	Skipping suggestion resource change notification 324 because it is an add without an event
standard	17:23:23.417071+0200	calaccessd	Skipping suggestion resource change notification 328 because it is an add without an event
standard	17:23:23.417160+0200	calaccessd	Skipping suggestion resource change notification 349 because it is an add without an event
standard	17:23:23.416826+0200	calaccessd	[0x122858980] activating connection: mach=false listener=false peer=true name=com.apple.CalendarAgent.peer.0x122858980
standard	17:23:23.417252+0200	calaccessd	Skipping suggestion resource change notification 363 because it is an add without an event
standard	17:23:23.417393+0200	calaccessd	Skipping suggestion resource change notification 376 because it is an add without an event
standard	17:23:23.416416+0200	Calendar	[1.3607] [0.0015] [main] <private>
standard	17:23:23.417469+0200	calaccessd	Skipping suggestion resource change notification 554 because it is an add without an event
standard	17:23:23.417685+0200	calaccessd	Skipping suggestion resource change notification 631 because it is an add without an event
standard	17:23:23.417762+0200	calaccessd	Skipping suggestion resource change notification 690 because it is an add without an event
standard	17:23:23.417793+0200	calaccessd	ClientConnection trySetDatabaseInitializationOptions. clientProvidedOptions:<CADDatabaseInitializationOptions: 0x1229ffec0>: {databaseInitOptions = 0, enablePropertyModificationLogging = 1, unitTesting = 0, changeTrackingID = No Custom ClientID or Suffix, databaseDirectory = (null), containerProvider = (null), allowDelegateSources: 1, allowedSourceIdentifiers: (null), privacyClientIdentity: (null), mockPermissions: (null), remoteClientIdentity: (null)}
standard	17:23:23.417870+0200	calaccessd	Skipping suggestion resource change notification 696 because it is an add without an event
standard	17:23:23.418080+0200	calaccessd	Skipping suggestion resource change notification 711 because it is an add without an event
standard	17:23:23.418169+0200	calaccessd	[0x122839970] activating connection: mach=true listener=false peer=false name=com.apple.tccd
standard	17:23:23.417644+0200	Calendar	[1.3619] [0.0012] [main] <private>
standard	17:23:23.418308+0200	calaccessd	Skipping suggestion resource change notification 718 because it is an add without an event
standard	17:23:23.418518+0200	calaccessd	Skipping suggestion resource change notification 721 because it is an add without an event
standard	17:23:23.418729+0200	calaccessd	Skipping suggestion resource change notification 832 because it is an add without an event
standard	17:23:23.418927+0200	calaccessd	Skipping suggestion resource change notification 1046 because it is an add without an event
standard	17:23:23.419107+0200	calaccessd	Skipping suggestion resource change notification 1069 because it is an add without an event
standard	17:23:23.419418+0200	calaccessd	Skipping suggestion resource change notification 1075 because it is an add without an event
standard	17:23:23.419619+0200	calaccessd	Skipping suggestion resource change notification 1096 because it is an add without an event
standard	17:23:23.418875+0200	Calendar	[1.3632] [0.0012] [main] <private>
standard	17:23:23.420011+0200	Calendar	[1.3643] [0.0011] [main] <private>
standard	17:23:23.420095+0200	Calendar	Fetched event notifications from event store: <private>.
standard	17:23:23.420685+0200	Calendar	Set notification references to <private>.
standard	17:23:23.420865+0200	Calendar	Current notification count: 0. Last event notification count: 0.
standard	17:23:23.420886+0200	Calendar	Is initial check: NO.
standard	17:23:23.421133+0200	Calendar	[1.3654] [0.0011] [main] <private>
standard	17:23:23.419734+0200	tccd	AUTHREQ_CTX: msgID=1122.16535, function=TCCAccessRequest, service=kTCCServiceCalendar, preflight=yes, query=1, client_dict=(null), daemon_dict=<private>
standard	17:23:23.419775+0200	tccd	AUTHREQ_ATTRIBUTION: msgID=1122.16535, attribution={accessing={TCCDProcess: identifier=com.apple.dock.extra, pid=1482, auid=501, euid=501, binary_path=/System/Library/CoreServices/Dock.app/Contents/XPCServices/com.apple.dock.extra.xpc/Contents/MacOS/com.apple.dock.extra}, requesting={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, },
standard	17:23:23.419910+0200	tccd	requestor: TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd is checking access for accessor TCCDProcess: identifier=com.apple.dock.extra, pid=1482, auid=501, euid=501, binary_path=/System/Library/CoreServices/Dock.app/Contents/XPCServices/com.apple.dock.extra.xpc/Contents/MacOS/com.apple.dock.extra
standard	17:23:23.419696+0200	calaccessd	Skipping suggestion resource change notification 1101 because it is an add without an event
standard	17:23:23.419774+0200	calaccessd	Skipping suggestion resource change notification 1104 because it is an add without an event
standard	17:23:23.426655+0200	calaccessd	Commencing database save for client with identifier [com.apple.dataaccess.dataaccessd], name [dataaccessd].  Commit: [YES]
standard	17:23:23.426935+0200	calaccessd	Summary of changes being saved: Source (add: 0 mod: 1 del: 0)
standard	17:23:23.427357+0200	calaccessd	Disallowing reload for changes because they don't affect the widget
standard	17:23:23.427333+0200	calaccessd	Forwarding darwin notifications to modules.
standard	17:23:23.427422+0200	calaccessd	Not refreshing EKEventStore before handling database change notification because we don't have an EKEventStore right now.
standard	17:23:23.427500+0200	calaccessd	Database changed.
standard	17:23:23.427720+0200	calaccessd	Initialized event store with access to events only
standard	17:23:23.434096+0200	calaccessd	[0x1228e1ed0] activating connection: mach=true listener=false peer=false name=com.apple.CalendarAgent
standard	17:23:23.440598+0200	calaccessd	[0x121f56e50] activating connection: mach=false listener=false peer=true name=com.apple.CalendarAgent.peer.0x121f56e50
standard	17:23:23.441196+0200	calaccessd	ClientConnection trySetDatabaseInitializationOptions. clientProvidedOptions:<CADDatabaseInitializationOptions: 0x126870440>: {databaseInitOptions = 0, enablePropertyModificationLogging = 1, unitTesting = 0, changeTrackingID = No Custom ClientID or Suffix, databaseDirectory = (null), containerProvider = (null), allowDelegateSources: 1, allowedSourceIdentifiers: (null), privacyClientIdentity: (null), mockPermissions: (null), remoteClientIdentity: (null)}
standard	17:23:23.441287+0200	calaccessd	[0x122839970] invalidated after the last release of the connection object
standard	17:23:23.441354+0200	calaccessd	[0x122d8ef20] activating connection: mach=true listener=false peer=false name=com.apple.tccd
standard	17:23:23.441736+0200	calaccessd	[0x1229ee3c0] activating connection: mach=true listener=false peer=false name=com.apple.tccd
standard	17:23:23.442229+0200	tccd	AUTHREQ_ATTRIBUTION: msgID=1122.16536, attribution={accessing={TCCDProcess: identifier=com.apple.dock.extra, pid=1482, auid=501, euid=501, binary_path=/System/Library/CoreServices/Dock.app/Contents/XPCServices/com.apple.dock.extra.xpc/Contents/MacOS/com.apple.dock.extra}, requesting={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, },
standard	17:23:23.442292+0200	tccd	requestor: TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd is checking access for accessor TCCDProcess: identifier=com.apple.dock.extra, pid=1482, auid=501, euid=501, binary_path=/System/Library/CoreServices/Dock.app/Contents/XPCServices/com.apple.dock.extra.xpc/Contents/MacOS/com.apple.dock.extra
standard	17:23:23.443696+0200	tccd	AUTHREQ_CTX: msgID=1122.16537, function=TCCAccessRequest, service=kTCCServiceCalendar, preflight=yes, query=1, client_dict=(null), daemon_dict=<private>
standard	17:23:23.443917+0200	tccd	AUTHREQ_ATTRIBUTION: msgID=1122.16537, attribution={accessing={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, requesting={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, },
standard	17:23:23.443988+0200	tccd	requestor: TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd is checking access for accessor TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd
standard	17:23:23.444036+0200	tccd	Granting TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd access to kTCCServiceCalendar via entitlement 'com.apple.private.tcc.allow'
standard	17:23:23.444364+0200	calaccessd	[0x1229ee3c0] invalidated after the last release of the connection object
standard	17:23:23.452873+0200	calaccessd	[0x122d8ef20] invalidated after the last release of the connection object
standard	17:23:23.452917+0200	calaccessd	Changed database initialization options to [<CADDatabaseInitializationOptions: 0x1229f64e0>: {databaseInitOptions = 0, enablePropertyModificationLogging = 1, unitTesting = 0, changeTrackingID = No Custom ClientID or Suffix, databaseDirectory = (null), containerProvider = (null), allowDelegateSources: 1, allowedSourceIdentifiers: (null), privacyClientIdentity: (null), mockPermissions: (null), remoteClientIdentity: (null)}]
standard	17:23:23.452925+0200	calaccessd	[0x121f065d0] activating connection: mach=true listener=false peer=false name=com.apple.tccd
standard	17:23:23.453022+0200	calaccessd	[0x122a7ab60] activating connection: mach=true listener=false peer=false name=com.apple.tccd
standard	17:23:23.453572+0200	tccd	AUTHREQ_CTX: msgID=1122.16539, function=TCCAccessRequest, service=kTCCServiceCalendar, preflight=yes, query=1, client_dict=(null), daemon_dict=<private>
standard	17:23:23.453598+0200	tccd	AUTHREQ_ATTRIBUTION: msgID=1122.16539, attribution={accessing={TCCDProcess: identifier=com.apple.dock.extra, pid=1482, auid=501, euid=501, binary_path=/System/Library/CoreServices/Dock.app/Contents/XPCServices/com.apple.dock.extra.xpc/Contents/MacOS/com.apple.dock.extra}, requesting={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, },
standard	17:23:23.453643+0200	tccd	requestor: TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd is checking access for accessor TCCDProcess: identifier=com.apple.dock.extra, pid=1482, auid=501, euid=501, binary_path=/System/Library/CoreServices/Dock.app/Contents/XPCServices/com.apple.dock.extra.xpc/Contents/MacOS/com.apple.dock.extra
standard	17:23:23.454174+0200	tccd	AUTHREQ_ATTRIBUTION: msgID=1122.16538, attribution={accessing={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, requesting={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, },
standard	17:23:23.454245+0200	tccd	requestor: TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd is checking access for accessor TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd
standard	17:23:23.454292+0200	tccd	Granting TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd access to kTCCServiceReminders via entitlement 'com.apple.private.tcc.allow'
standard	17:23:23.454621+0200	calaccessd	[0x121f065d0] invalidated after the last release of the connection object
standard	17:23:23.454768+0200	calaccessd	Changed database initialization options to [<CADDatabaseInitializationOptions: 0x126899ef0>: {databaseInitOptions = 0, enablePropertyModificationLogging = 1, unitTesting = 0, changeTrackingID = No Custom ClientID or Suffix, databaseDirectory = (null), containerProvider = (null), allowDelegateSources: 1, allowedSourceIdentifiers: (null), privacyClientIdentity: (null), mockPermissions: (null), remoteClientIdentity: (null)}]
standard	17:23:23.456062+0200	dataaccessd	Notifying agents that the Calendar database has changed.
standard	17:23:23.456409+0200	suggestd	PPLocalEventStore: reloading events due to EKCalendarVisibilityManager visibilityChanged (0 invisible calendars)
standard	17:23:23.457030+0200	suggestd	PPEventStorage: loading calendars
standard	17:23:23.457269+0200	suggestd	[0x1281dd4a0] activating connection: mach=true listener=false peer=false name=com.apple.CalendarAgent
standard	17:23:23.458184+0200	calaccessd	[0x12293d2c0] activating connection: mach=false listener=false peer=true name=com.apple.CalendarAgent.peer.0x12293d2c0
standard	17:23:23.459899+0200	calaccessd	ClientConnection trySetDatabaseInitializationOptions. clientProvidedOptions:<CADDatabaseInitializationOptions: 0x1229f8e20>: {databaseInitOptions = 0, enablePropertyModificationLogging = 1, unitTesting = 0, changeTrackingID = No Custom ClientID or Suffix, databaseDirectory = (null), containerProvider = (null), allowDelegateSources: 0, allowedSourceIdentifiers: (null), privacyClientIdentity: (null), mockPermissions: (null), remoteClientIdentity: (null)}
standard	17:23:23.462655+0200	calaccessd	Commencing database save for client with identifier [com.apple.dataaccess.dataaccessd], name [dataaccessd].  Commit: [YES]
standard	17:23:23.462801+0200	calaccessd	Summary of changes being saved: Source (add: 0 mod: 1 del: 0)
standard	17:23:23.463031+0200	calaccessd	Disallowing reload for changes because they don't affect the widget
standard	17:23:23.464865+0200	calaccessd	[0x122a7ab60] invalidated after the last release of the connection object
standard	17:23:23.465435+0200	tccd	AUTHREQ_ATTRIBUTION: msgID=1122.16540, attribution={accessing={TCCDProcess: identifier=com.apple.dock.extra, pid=1482, auid=501, euid=501, binary_path=/System/Library/CoreServices/Dock.app/Contents/XPCServices/com.apple.dock.extra.xpc/Contents/MacOS/com.apple.dock.extra}, requesting={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, },
standard	17:23:23.465562+0200	tccd	requestor: TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd is checking access for accessor TCCDProcess: identifier=com.apple.dock.extra, pid=1482, auid=501, euid=501, binary_path=/System/Library/CoreServices/Dock.app/Contents/XPCServices/com.apple.dock.extra.xpc/Contents/MacOS/com.apple.dock.extra
standard	17:23:23.464909+0200	calaccessd	[0x122b1abc0] activating connection: mach=true listener=false peer=false name=com.apple.tccd
standard	17:23:23.467279+0200	calaccessd	[0x122839970] activating connection: mach=true listener=false peer=false name=com.apple.tccd
standard	17:23:23.469202+0200	dataaccessd	Calendar database changed. Refreshing account  "" (MobileCalDAVDaemonAccount E44C0B5F-0794-4174-AF8A-100A76CF649F)
standard	17:23:23.469410+0200	dataaccessd	Calendar database changed. Refreshing account  "" (MobileCalDAVDaemonAccount D9054009-5508-44CE-8166-66BE6D809344)
standard	17:23:23.469594+0200	dataaccessd	Calendar database changed. Refreshing account  "<private>" (MobileCalDAVDaemonAccount 1374C270-E314-499E-BDA8-FE14A343A245)
standard	17:23:23.469827+0200	dataaccessd	Calendar database changed. Refreshing account  "" (MobileCalDAVDaemonAccount B1BA93A3-1D8C-4379-8B24-AF1687F9EAC9)
standard	17:23:23.470623+0200	Calendar	[1.4149] [0.0495] [main] Loaded Calendar List Data Source Data
standard	17:23:23.471024+0200	tccd	AUTHREQ_CTX: msgID=1122.16541, function=TCCAccessRequest, service=kTCCServiceCalendar, preflight=yes, query=1, client_dict=(null), daemon_dict=<private>
standard	17:23:23.470663+0200	Calendar	[1.4149] [0.0000] [main] <private>
standard	17:23:23.471143+0200	tccd	AUTHREQ_ATTRIBUTION: msgID=1122.16541, attribution={accessing={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, requesting={TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd}, },
standard	17:23:23.471029+0200	Calendar	[1.4153] [0.0004] [main] <private>
standard	17:23:23.471298+0200	tccd	requestor: TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd is checking access for accessor TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd
standard	17:23:23.471057+0200	dataaccessd	Calendar database changed. Refreshing account  "" (MobileCalDAVDaemonAccount 64CD67EA-064D-4F5A-BCEA-706ECDA2D196)
standard	17:23:23.471456+0200	tccd	Granting TCCDProcess: identifier=com.apple.calaccessd, pid=1122, auid=501, euid=501, binary_path=/System/Library/PrivateFrameworks/CalendarDaemon.framework/Support/calaccessd access to kTCCServiceCalendar via entitlement 'com.apple.private.tcc.allow'
standard	17:23:23.471477+0200	Calendar	[1.4158] [0.0004] [main] <private>
standard	17:23:23.471369+0200	dataaccessd	Calendar database changed. Refreshing account  "<private>" (MobileCalDAViCloudDaemonAccount 758358E9-6BD6-415A-9623-36B0A2F04077)
standard	17:23:23.471857+0200	Calendar	[1.4161] [0.0004] [main] <private>
standard	17:23:23.471446+0200	dataaccessd	Calendar database changed. Refreshing account  "" (MobileCalDAVDaemonAccount 1BCC6344-6BEA-4DCF-B74F-C156A802D321)
standard	17:23:23.472242+0200	Calendar	[1.4165] [0.0004] [main] <private>
standard	17:23:23.471906+0200	dataaccessd	Calendar database changed. Refreshing account  "" (MobileCalDAVDaemonAccount 366EF59E-0974-495A-8F08-FB27CB0CF583)
standard	17:23:23.472647+0200	Calendar	[1.4169] [0.0004] [main] <private>
standard	17:23:23.472999+0200	Calendar	[1.4173] [0.0003] [main] <private>
standard	17:23:23.473347+0200	Calendar	[1.4176] [0.0003] [main] <private>

Hi,

This is a beta OS unsupported yet. As Apple frequently change calendar behaviour, this will be investigated (if needed) after mac os 14 release

Sebastien

Hi @poly01,

I have added Sonoma support (next nightly), the mac os 14 user agent was missing in the previous fix.
As I don't have any mac with Sonoma, I can't test it

Please test next nightly

Sebastien

I testet the nighty (together with @poly01 on his server) but git a different error message.
Should be translated to:

Your calendar could not be updated.
No calendar location was specified for the account.

(Tested on the latest Beta 4 of macOS 14.0 Sonoma, Build 23A5301h)

Bildschirmfoto 2023-08-03 um 15.24.41.png (205,135 bytes)   

Bildschirmfoto 2023-08-03 um 15.24.41.png (205,135 bytes)   

Confirmed to be an issue for Sonoma - my Mac updated automatically from Ventura (where previously installed CalDAV links were not an issue) - after that upgrade, all Personal Calendars disappeared from SoGo CalDav links, and Mac Calendar.app created new "Calendar"s.

Would be great to have the fix introduced asap also in an official release if possible!

You can try to remove and readd calendar according to https://bugs.sogo.nu/view.php?id=5639#c16901

If the issue persists, this will be investigated after mac os Sonoma release.

Sebastien

For your info: issue persists also in latest macOS Sonoma Beta 5. Also after removing and re-adding the CalDAV calendar.app account

Feel a little bit stupid, but anybody knows how to retrieve Apple's calendar logs ? I have enabled "Log HTTP Activity" in the debug menu, but no idea about how to get those logs ....

[EDIT] : Logs are in ~/Library/Calendars/TrafficLogs/

Hi SOGo community users,

I finally found the original issue (@ffried). It was related to the schedule-outbox tag in the caldav request.
I have removed the previous fix. You may have to delete and re/add caldav calendar account (last time I promise).

Commit : https://github.com/Alinto/sogo/commit/4f7c73143f38b1e7e00a51b9457b55ce609a02a9 in the next nightly build

Please provide a feedback if everything works on Mac OS Ventura and Mac OS Sonoma. If the issue persists on Sonoma, please open a new ticket.

Sebastien

Does anyone have a hint how I can try the nightly build in a productive mailcow-dockerized environment? Would love to try the SoGO nightly build and be able to revert back to official release after testing. Anyone a hint how to do this? BTW, Sonoma latest beta 6 of today also has the same issue, no change towards earlier versions.

Hi @sebastien

Encountering the issue described in this thread with a Mac mini M1 on macOS Ventura 13.5.1 (22G90), I have tried the demo server which works pretty well.
Events created from the webUI and the macOS Calendar app are synced well. I have tried recurrent events and events with notes including special chars. Calendar names and colours changed with the Calendar app are visible in the webUI. So I believe that you can make the pull request ;-)

Thank you for the feedback, I have updated documentation https://github.com/Alinto/sogo/commit/87b89ed0947fd33b953adf0b8d19d6293e853d8e

For Mac OS Sonoma, you need to open a new ticket

Sebastien