Details
Diff Detail
- Repository
- rS syncroton
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| lib/kolab_sync_data_email.php | ||
|---|---|---|
| 408 | The fact an event has exceptions does not mean this specific invitation is an exception. If the invitation includes exceptions I'd say it's definitely not an exception. | |
| 410 | MeetingRequest has a different structure than Event. E.g. it has Recurrences property, but the later has recurrence. Look at 4th argument of recurrence_from_kolab(), but it's not that simple, I'm afraid. | |
| 459 | The property might be unset, then itt defaults to MESSAGE_TYPE_NORMAL. | |
| lib/kolab_sync_data_email.php | ||
|---|---|---|
| 399 | I don't think we should for performance reasons. | |
| 408 | Right, I confused it with how we store exceptions separately in storage, but that is more a recurrenceId thing and doesn't apply to invitations (I think?). | |
| 410 | I'm just not going to implement recurrences until we see a need to, so I'll comment/remove this entire section. | |
| 459 | That's the idea (per spec 0 is the default). | |
| lib/kolab_sync_data_email.php | ||
|---|---|---|
| 399 | I think get_invitation_event_from_message() is smart enough to not have a performance penalty when there's no invitation. My point is that it has a more sophisticated way to determine the invitation part. So, we'd have parity between syncroton and webclient in this regard. | |
| 445 | My point was that the else could be removed. I also wonder what we should do when method=CANCEL (or REPLY). | |
| lib/kolab_sync_data_email.php | ||
|---|---|---|
| 399 | I think you might be right. | |