Details
Diff Detail
- Repository
- rS syncroton
- Branch
- master
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 43637 Build 17447: arc lint + arc unit
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. | |
451 | 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. | |
451 | 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. | |
437 | 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. |