-
Notifications
You must be signed in to change notification settings - Fork 417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change calendar for existing event on iOS doesn't work #1461
Comments
I have similar setup here, having shared calendar by softlinking, clients are
I had similar issue in the past and finally it was solved by fixing code in the "move.py" section together with verifcation of the reverse proxy config in case "radicale" is behind the proxy. Your description look like the same, the event is only moved on iOS client, but not successful executed on server side. Check log of "radicale", it should mention here something. If required, enable debug mode. |
Ran radicale from console, and indeed here is what I got
(I changed user name, sernver name, ip address, and uuid's). |
The "MOVE" code was extended related to such detection between 3.1.8 and 3.19, are you using latest version? And can you confirm your "nginx" configuration is similar to what is documented? https://radicale.org/master.html#reverse-proxy |
Yes, I am definitely on 3.1.9. Just ran
That config was made after I found a comment how to setup radicale to work with iOS. |
Sorry, I think the link to reddit is not the real source of the config. Looks like I saved a wrong one to my notes. |
Is it working now? If not, the related code is here: https://github.com/Kozea/Radicale/blob/master/radicale/app/move.py Check also why your config misses
|
Investigated. Condition on line 57 of move.py fails, and we see "Unsupported destination" |
My guess is that initial code was to compare netloc1 and netloc2 without ports but someone wanted to run several servers on one machine utilizing different ports, and hence comparison is with ports. |
That works (for me at least)
|
will investigate next days |
Is your case also working if you simply change this line
BTW: nobody else is currently complaining about issues with MOVE since the last code change here (2023-04) |
As I said above, |
Is there a way to determine (in code) whether radicale is working behind reverse proxy? If yes, the condition should be without port, if no as it was. |
BTW: I was considering not to use radicale because of the bug. Maybe this is the reason why noone else complains? |
"MOVE" is working fine behind an Apache reverse proxy using config sniplet from documentation Can you add following line to your "nginx" configuration
This is conditionally set in the Apache example in case HTTPS is active, see also #1301, the examples for other reverse proxies are missing this still potentially. |
Added header to nginx config. Honestly, I don't understand how is it effective to try different stuff and see what sticks to the wall. Maybe better is to understand what is happening (see result of my investigation above)? |
Running Radicale 3.1.9 on Linux (Debian; nginx as reverse proxy, ssl via letsencrypt).
For calendar sharing we use symlinks the following way:
/var/lib/collections/collection-root
has one foldercalendars
and few user folders which are symlinks tocalendars
folder in the same directory.Every user can see (!), read and write to other users' calendars.
The problem is that after event was created, changing calendar for the event has no effect. The user who made the change (put it from calendar1 to calendar2) sees the change. All other users don't see the change and see the old version.
That's weird because all other changes work as expected.
Download ics file via web interface I can find event in the original calendar, but not in the calendar the event was put into.
That explains why all users see event in the "old" calendar.
That doesn't explain why the user who made the change continues to see the change.
Will try to dig deeper into this some time later. In the meantime if anyone could test and reproduce the same feature - it would be helpful.
The text was updated successfully, but these errors were encountered: