iCal broken in 5.0.6?

[frankske]

Excellent! I'll upgrade customer to 5.0.7 later today and let you know if that fixes the issue. Thanks

[frankske]

Sorry to inform you guys that upgrading to 5.0.7 didn't change anything Any other solutions I could try?

[John Munro]

Frank. A thought occurred to me that you might want to try using virtual domains. That way you wouldn't need to use the @czar.be etc.

You'd need to set up dns records to point the iCal machine to czar.be and use this domain name for connection in the Account URL field.

Catch is that I'm unsure if the CalDAV auth respects the virtual domain or not. John H may know this...

[JLee]

As far as I can see the behavior is unchanged from 5.0.6 to 5.0.7 and that is:

users in default domain should use only the username.
users not in default domain should use username@domain.

We may want to allow username@domain for users in default domain in the future. But there is a clear and simple workaround to get it working. Is the workaround not working for you, or are you running into other issues?

[frankske]

JLee, I don't get the error anymore, so that at least is a good thing However, I still don't get calendars for one particular mailbox, but I do see them for another account. Could this be the old "spaces in calendar names" bug again? Wasn't that one solved a while ago?

[y@w]

frankske, did you have to use a virtual domain for this to work?

[JLee]

iCal still has problem handling several characters in the calendar name including a space. For that there is no workaround.

[BarefootPanda]

I'm having a similar issue with iCal 3.0.4 (10.5.4) - had the same issue with 10.5.3 - with shared calendars in iCal.

iCal will update the info, but if I try to edit another users calendar that I have admin or manager rights to I get an error. I'm attaching a screenshot of the error.

I've been searching for weeks for a solution for this and 5.0.7 NE did not solve the issue.