Adding a time to a scheduled caldav task makes it repeat yearly

[kchousos]

To Reproduce Steps to reproduce the behavior:

1. Add a task to a Nextcloud calendar
2. Add a schedule date
3. Add a schedule time
4. See that it becomes repeating yearly

Expected behavior The yearly repetition should only be enabled when set explicitly.

Desktop (please complete the following information):

• OS or DE: Fedora 39, Gnome
• Version 4.6

[alainm23]

I have not been able to reproduce this bug, is it still happening?

[kchousos]

Yes. As far as I can tell, this repetition is shown the next time that you open the program, not when you create the task.

[alainm23]

I'm sorry, but it's not happening to me, maybe you could upload a video to see how to get to the bug, thanks.

[BeatLink]

I am seeing the bug as well. Some tasks are being set to repeat yearly with an end date in 1963 if i recall

[brokoli18]

I believe I have stumbled onto the cause of this phenomenon. To test this I created a task in nextcloud and ran planify from the terminal. When looking at the task it looked like this:

get_vtodo_by_url
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Nextcloud Tasks v0.15.0
BEGIN:VTODO
UID:28afe78e-6427-498c-9ec5-4caf90425ebd
CREATED:20240624T002500
LAST-MODIFIED:20240624T002512
DTSTAMP:20240624T002512
SUMMARY:HAILMARY
DUE:20240625T040000
END:VTODO
END:VCALENDAR 

I then opened tasks.org on my phone and triggered a sync. Syncing planify again shows the same task with much more (and different) metadata:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:+//IDN bitfire.at//ical4android (org.tasks)                                                                        
BEGIN:VTODO
DTSTAMP:20240623T232827Z
UID:28afe78e-6427-498c-9ec5-4caf90425ebd
SEQUENCE:1
CREATED:20240624T002500Z                                     
LAST-MODIFIED:20240623T232825Z 
SUMMARY:HAILMARY
STATUS:NEEDS-ACTION
DUE;TZID=Europe/London:20240625T040001
BEGIN:VALARM
TRIGGER;RELATED=END:PT0S
ACTION:DISPLAY                                               
DESCRIPTION:Default Tasks.org description
END:VALARM
END:VTODO
BEGIN:VTIMEZONE
TZID:Europe/London
LAST-MODIFIED:20231222T233358Z 
BEGIN:DAYLIGHT
TZNAME:BST
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
DTSTART:19810329T010000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:GMT
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
DTSTART:19961027T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD

It seems that tasks.org is actually overwriting whats on the server which is playing havoc with planify. I hope that the above can shed some light into which particular bit of metadata is causing the above bug but I believe other issues such as https://github.com/alainm23/planify/issues/1351 may be caused by this as well.

[fireball74]

I agree with brokoli18s observations. It seems planify is assuming "yearly repeat" after you edited and synced an item with Tasks (on Android, https://tasks.org ) for some reason. Even though there is specifically no repeat set in Tasks that is. It does not seem to break anything but it is a bit annoying.