Summary of problems and/or bugs creating and publishing a new calendar

[jmfoleyjr]

This is a summary of the problems I reported in https://github.com/Kozea/Radicale/issues/956. Debug dumps, configs, etc. can be found there if anyone chooses to pursue these problem.

I have a heterogeneous office environment with Windows 7, Window 10, Linux and Mac workstations, all members of an Active Directory domain. Thunderbird is a mail client on all the above types of workstations. In addition, some Windows 7 workstations use Outlook 2010 with CalDavSynchronizer. Some Windows 10 workstations use Outlook 365 with CalDavSynchronizer. Some Mac are running Outlook 365 (which currently has no non-Exchange calendar subscription capability) and the Macs also use Mac Calendar.

Here are my issues trying to create and publish to a new radicale calendar. Some of the problems may be usage issues on my part (and if so I would appreciated being straightened out on what I did wrong), and at least one I think is an actual bug: a "400 Bad Request" error.

Problem 1: I attempted to create a new calendar from a user workstation. I could not do so via Thunderbird/Lightning. I tried specifying the URL of my desired new calendar: https://mydom.org:5232/OfficeCalendar. The radicale debug output is shown in the initial post of issue 956 (link listed above) and I'll not clutter this post by repeating that here. It seem to me that radicale should be able to create a new calendar from the calendar client program. If that is possible, and I did it wrong, please advise. If not possible I'd suggest that as a future enhancement as most calendar users are not technical.

Problem 2: Next I tried opening the URL https://mydom.org:5232 in a browser. I was not able to log in with the known correct credentials and got a "403 Access Forbidden" error (debug output in issue 956). The config uses auth type httpasswd and rights type from_file. This user is able to access published radicale calendars using these credentials, but not able to log into the URL with them. This may be a usage issue on my part, but if so I don't know what. The rights file is:

[owner-write]
user = .+
collection = %(login)s(/.*)?
permission = rw

[conference]
user = .+
collection = ConferenceCalendar(/.*)?
permission = rw

[office]
user = .+
collection = OfficeCalendar(/.*)?
permission = rw

Which was pretty much taken from https://radicale.org/rights/. If I disabled authentication and rights I was then able to log in and create the calendar.

Problem 3: The newly created calendar folder was ~/collections/collection-root/joe/, where "joe" is the workstation user, and is presumably derived from the username on the radicale login page. 'Edit'ing does not let me rename the calendar name (also what do attributes Title, Description and Color do?). I did figure out that, with no authentication enabled, if I specify the desired name of the calendar as the username on the login page that it will create the calendar with that name: ~/collections/collection-root/OfficeCalendar, but that is not at all obvious and I think renaming should be doable in the 'Edit' section, or at least the above "trick" should be documented on the login screen.

Problem 4: I still could not publish a Thunderbird/Lightning calendar to radicale using the correct URL (https://mydom.org:5232/OfficeCalendar/) if authentication and rights were set. Again, possible a usage issue on my part. If so, and given the rights file shown above, please advise.

Problem 5: With authentication and rights disabled, I then tried to publish the Thunderbird/Lightning calendar. This was the most frustrating bit. I continually got the python error, "can't compare offset-naive and offset-aware datetimes", and "400 Bad Request" (see issue 956 for debug details). The debug output gave no information as to which event from the source .ics file was causing the problem; no .ics file line number, no event UID or SUMMARY, nothing at all to identify the culprit. I painstakingly did a binary-search on the 253 events in the original .ics file to find the problem event (i.e. chopping the file into smaller and smaller segments and attempting to publish each segment to radicale). I finally identified the one problem event, removed it and was finally able after several days of work and experimentation to publish this calendar to radicale. The troublesome event is posted in issue 956.

I believe this is a bug. The various calendar clients mentioned above are all able to handle this event: Thunderbird on Mac, Linux and Windows; Outlook 2010 and 365 on Windows 7, 10 and Mac; and Mac Calendar. Only radicale chokes with this "can't compare offset-naive and offset-aware datetimes" python error, so I think the specified program and line number needs to be debugged. Even so, there should be some debug information telling the user which event is a problem in order to save time trying to track it down. Perhaps also there should be an option (config, or command line) to skip bad events and continue processing. As it is, all publishing is aborted and zero events are create in the radicale folder.

I hope this information help with the ongoing development of Radicale.

[jmfoleyjr]

Problem #2 (unable to log in via browser) is mostly resolved. This does work if the 'username' and 'password' are in the rights file, but if the user is trying to create a non-user-specific calendar (e.g. OfficeCalendar in the 'username' field), then if fails. The only solution for this I've found is to disable [auth] and [rights] and restart Radicale. It will then create the new calendar. I can live with that.

The main problem among those listed (#4) is if there is a bad event in an ics file being published the publication to Radicale fails, but does not indicate which event is the problem. As mentioned, I have to binary search the source ics file and repeatedly retry the publication until I can find and remove the offending event. If the Radicale debug output could be enhanced to indicate either the event number, title, date, UUID, or some such indicator which would make it easy to find the bad event, that would really help.

[pbiering]

solved now?

[pbiering]

closing now, in case still reproducable with current version (which should also support #4 now) reopen