Hello Christian,

Do you know if this behavior has appeared in version 5.11 with fixed in ticket 0006031?

Sebastien

Hello Sebastien

This bug appeared in 5.11.0-Release.
I manually added the code change from 0006031 in our production system, in order to check again.
The fix for Bug 0006031 did not fix this problem.

Kind regards,
Christian

Ok, thanks for reporting I will have a look on that next week

Sebastien

FI this happens also on 5.10.0

Dear Christian,

The behavior is the same for events.
Technically, the event (or task) is linked to a folder_id in the database. When one occurrence is modified, the iCalendar data is updated but still contains all occurrences.

BEGIN:VTODO
UID:840B-66E43180-3-34BF88C0
SUMMARY:Bar
CLASS:PUBLIC
RRULE:FREQ=DAILY;COUNT=10
DTSTART;TZID=Europe/Berlin:20240913T143000
DUE;TZID=Europe/Berlin:20240913T143000
CREATED:20240913T123604Z
DTSTAMP:20240913T123604Z
LAST-MODIFIED:20240913T123604Z
END:VTODO
BEGIN:VTODO
UID:840B-66E43180-3-34BF88C0
SUMMARY:Bar2
CLASS:PUBLIC
DTSTART;TZID=Europe/Berlin:20240914T143000
DUE;TZID=Europe/Berlin:20240914T143000
CREATED:20240913T123841Z
DTSTAMP:20240913T123841Z
LAST-MODIFIED:20240913T123841Z
RECURRENCE-ID:20240914T123000Z
END:VTODO

The iCalendar data is not split and remains associated with the same folder_id.

Previously, it was possible to move only one instance/occurrence while keeping all other instances in the original calendar.

I'm really surprised by this, given the product/code architecture. Do you remember which version of SOGo this was?

For us, it is not necessary to keep that moved single task instance as part of a task series.
It could be converted to a standalone task if that’s easier to implement.

I agree, but this needs significant changes.

Best,
Sebastien

Hello Sebastien

This took some time.
I had to talk to multiple people in different departments.

The behavior is the same for events.
Technically, the event (or task) is linked to a folder_id in the database. When one occurrence is modified, the iCalendar data is updated but still contains all occurrences.

That is true, but I never had an use case for storing single instances of an event series into another calendar.
Therefore this is not a problem with repetitive events.

My remark:

This bug appeared in 5.11.0-Release.

was based on the information from one user.
She told me she did move single instances of a repetitive task in May.
Talking to other users, this seems unlikely.
It was possible to do that, but some years back.
I could not pin it down to a year or version, sorry.
Because of that it seems plausible to me, to change this report to "feature request".

Now to the use cases for moving single instances.

1) A department has a calendar, in which all open tasks are listed. Whenever someone has some time he/she takes a task and works on it. In order to prevent others from working on the same task, she moves it to her own calendar.

2) A department has an archive calendar, in which all done tasks are stored for documentation purpose. When a task is done by a department member, then it is moved into that archive calendar.

3) A task can not be done by a single user. Therefore one user starts working on it. And when done her part, she moves that task into the calendar of another user. That user continues the task, and moves it to the next user. That repeats till the task is done.

Currently the only workaround is to not use recurring tasks.
If the tasks repeats in less than a month, this gets very annoying and error prone.
As you have to create a task for every instance manually.

Kind regards,
Christian Mack

Hello Christian,

Thank you for your feedback and investigation. We will look into it later, as we are busy until Q1 2025.

Best regards,
Sebastien