View Issue Details

IDProjectCategoryView StatusLast Update
0002865SOGoWeb Calendarpublic2017-01-09 20:49
Reporterams077 Assigned Toludovic  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Platform[Server] LinuxOSDebianOS Version7 (Wheezy)
Product Version2.2.6 
Fixed in Version3.2.5 
Summary0002865: SOGo does not interpret date-time without timezone correctly
Description

According to <http://www.ietf.org/rfc/rfc2445.txt>, datetimes without timezone information should be taken as 'local time'.

The SOGo calendar UI fails to do this. It seems to interpret timezone-less datetimes as GMT and then apply an offset to convert to local time.

For example:

"""
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20140721T110612Z
LAST-MODIFIED:20140721T112437Z
DTSTAMP:20140721T112437Z
UID:5a4d1b1c-f099-4c4c-a741-05aec48167aa
SUMMARY:Local Time Test
ORGANIZER;PARTSTAT=ACCEPTED;SCHEDULE-AGENT=CLIENT;ROLE=CHAIR;RSVP=TRUE;CN=D
r Alex Sheppard:mailto:alex@das-computer.co.uk
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Alex Sheppard;RSVP=TRUE:
mailto:ams@corefiling.com
DTSTART:20140721T130000
DTEND:20140721T140000
TRANSP:OPAQUE
X-MOZ-RECEIVED-SEQUENCE:0
X-MOZ-RECEIVED-DTSTAMP:20140721T110655Z
END:VEVENT
END:VCALENDAR
"""

This event should show as starting at 1300 in whatever timezone the client happens to be. Thunderbird and Lightning using a SOGo CALDAV calendar displays this at the correct time. The SOGo UI displays the same event (same calendar) an hour later (my current timezone is BST, which is GMT+1). If I change my timezone in SOGo preferences, the event time moves around.

Steps To Reproduce
  1. Get an event, that has no timezone information with its DTSTART and DTEND properties, into SOGo.

  2. Notice that it displays at

    Event time + current timezone offset from GMT

instead of

Event time

TagsNo tags attached.

Relationships

has duplicate 0002716 resolvedludovic SOGo Wrong time/timezone for Calendar Invite when accepted on iPhone, OK when accepted on Thunderbird 
has duplicate 0002707 resolvedludovic SOGo Integrator Wrong Time/timezone for accepted event showing in iPhone and Thunderbird, shows correct in SOGo web GUI 

Activities

pbra

pbra

2015-04-08 12:46

reporter   ~0008401

Last edited: 2015-04-08 12:47

I have the same problem and I think that the severity is major, some people in our organisation miss their appointmnt due to this bug !
Sogo need to respect rfc2445 :


FORM 0000001: DATE WITH LOCAL TIME

The date with local time form is simply a date-time value that does
not contain the UTC designator nor does it reference a time zone. For
example, the following represents Janurary 18, 1998, at 11 PM:

 DTSTART:19980118T230000

Date-time values of this type are said to be "floating" and are not
bound to any time zone in particular. They are used to represent the
same hour, minute, and second value regardless of which time zone is
currently being observed.

Sergey Urushkin

Sergey Urushkin

2015-11-06 11:27

reporter   ~0009077

I agreed with pbra, it's really a major issue, since it may confuse users/managers/directors.
But I think it is somewhat wider than mentioned earlier.
If it's required to file a new report about all next - please, let me know.
Here are my thoughts/tests/examples...

I see 13 common cases about formatting ICS and time/timezones.
In my opinion, SOGo violates RFC with 1,3 and also should be fixed with 4,6,8.
There is two main problems with SOGo:

  • it doesn't treat the first case as local time
  • it doesn't use it's own VTIMEZONE definitions, if none (or wrong) specified within the event.
    Despite I haven't met 3,9,10,12,13 cases in real life, they will help to form the right algorithm (which is at the end of the message).

These cases are:

  1. DTSTART/DTEND without TZID. According to RFC2445, it should be displayed using local time (floating). Lightning/DAVdroid/iCal/iOS uses local time. SOGo uses UTC.

  2. DTSTART/DTEND ending with "Z". Should be displayed using UTC+local_timezone_offset despite any VTIMEZONE definitions are given. Lightning/DAVdroid/iCal/iOS/SOGo uses UTC.

  3. DSTART/DTEND ending with "Z" and TZID. Should be displayed using UTC+local_timezone_offset despite any TZID/VTIMEZONE definitions are given. Lightning/DAVdroid/iCal do so. iOS/SOGo uses event's VTIMEZONE definition.

  4. DTSTART/DTEND with TZID, without VTIMEZONE definition. Lightning/DAVdroid/iCal/iOS uses it's own VTIMEZONE definitions. SOGo uses UTC.

  5. DTSTART/DTEND with TZID and VTIMEZONE definition the same as client's VTIMEZONE definition. Lightning/DAVdroid/iCal/iOS/SOGo uses VTIMEZONE definition.

  6. DTSTART/DTEND with TZID and VTIMEZONE that differs from client's VTIMEZONE definition. Lightning/iOS uses client's VTIMEZONE definition. DAVdroid/iCal/SOGo uses event's VTIMEZONE definition.

  7. DTSTART/DTEND with TZID and VTIMEZONE that is unknown to client. Lightning/DAVdroid/iCal/iOS/SOGo uses event's VTIMEZONE definition.

  8. DTSTART/DTEND with TZID, without VTIMEZONE and VTIMEZONE is also unknown to client. Lightning/DAVdroid/iCal/iOS uses local time (floating). SOGo uses UTC.

  9. DTSTART/DTEND without TZID and VTIMEZONE, with VALUE=DATE and date-time format is yyyymmddThhmmss. Lightning/iCal/SOGo ignores VALUE, the time is as in 1. DAVdroid treats as all-day event.

  10. DTSTART/DTEND without TZID and VTIMEZONE, with VALUE=DATE-TIME and date-time format is yyyymmdd. Lightning/iCal/SOGo ignores VALUE and shows as all-day. DAVdroid shows as all-day, but the time is also set (to 00:00:00).

  11. DTSTART/DTEND without TZID and VTIMEZONE, with VALUE=DATE. Lightning/DAVdroid/iCal/iOS/SOGo uses all-day event.

  12. DTSTART/DTEND without TZID and VTIMEZONE, DTSTART with VALUE=DATE-TIME, DTEND with VALUE=DATE. Lightning/DAVdroid/iCal/iOS uses DTSTART as local time, SOGo uses UTC (as in 1). Lightning/iCal calculates DTEND as 00:00:00, DAVdroid as 00:00:00+local_timezone_offset, iOS??, SOGo as 00:00:00(UTC)+local_offset.

  13. DTSTART/DTEND without TZID and VTIMEZONE, DTSTART with VALUE=DATE, DTEND with VALUE=DATE-TIME. Lightning/DAVdroid. iCal/iOS/SOGo displays as all-day+1day event.

For better understanding I've created test events for every case. You can upload them to your CalDAV server using curl:
curl --insecure --basic --request PUT --header \
"Content-Type: text/calendar; charset=utf-8" \
-u USR:PASS -T FILENAME \
https://host/path/to/calendar

Attached test events (T01.ics, ... , T13.ics) start at 20151103T120000 (with various Z/TZID/VTIMEZONE/VALUE modifications).

Let's view them with SOGo 2.3.2:
If client's timezone is Europe/Moscow (UTC+03). We get:

  • 1,2,4,8,9 starts at 15:00 (UTC + 3)
  • 3,5 starts at 12:00 (event's VTIMEZONE)
  • 6,7 starts at 11:00 (event's VTIMEZONE)
  • 10,11 is all-day event
  • 12 starts at 15:00, ends at 03:00 (UTC + 3)
  • 13 is 2-days-long all-day event
    If client's timezone is Asia/Shanghai (UTC+08). We get:
  • 1,2,4,8,9 starts at 20:00 (UTC + 8)
  • 3,5 starts at 17:00 (event's VTIMEZONE)
  • 6,7 starts at 16:00 (event's VTIMEZONE)
  • 10,11 is all-day event
  • 12 starts at 20:00, ends at 08:00 (UTC + 8)
  • 13 is 2-days-long all-day event

Since Lightning uses the most correct logic (at least as I think), let's view events with Lightning 4.3.0.1 .
If client's timezone is Europe/Moscow (UTC+03). We get:

  • 1,4,5,6,8,9 starts at 12:00 (1,8,9 - localtime, 4,5,6 - client's VTIMEZONE)
  • 2,3 starts at 15:00 (UTC + 3).
  • 7 starts at 11:00 (event's VTIMEZONE)
  • 10,11,13 is all-day event
  • 12 starts at 12:00, ends at 00:00
    If client's timezone is Asia/Shanghai (UTC+08). We get:
  • 1,8,9 starts at 12:00 (localtime)
  • 2,3 starts at 20:00 (UTC + 8).
  • 4,5,6 starts at 17:00 (client's VTIMEZONE)
  • 7 starts at 16:00 (event's VTIMEZONE)
  • 10,11,13 is all-day event
  • 12 starts at 12:00, ends at 00:00

You could test these events with any client you like, there will be different results with different clients...

I'm not a developer, but this generic code could be used to implement Lightning logic:

Variables:

DTSTR # DTSTART/DTEND/other string
DT # DTSTART/DTEND/other date-time without "Z" and "TZID" and "VALUE"
Z # true if DATE used with "Z" in the end (UTC)
TZID # TZID used with DT

all offsets are calculated for the given date-time, including daylight/standart handling

and time offset can also change the date

ETZO # event's VTIMEZONE TZID offset from UTC
CTZO # client's VTIMEZONE TZID offset from UTC
LTZO # local time offset from UTC
RDT # resulting date-time

let's call next code "f_datetime" function,

which input is any DTSTR-formatted string

and output is resulting date-time for current client's timezone (RDT).

This is the detailed "hard" logic (next you'll see the optimized logic):

DTSTR is given with "Z"

if Z then

despite any TZID or VTIMEZONE given (the time can not be "UTC" add "with offset" simultaneously),

use UTC + local time offset

RDT=DT+LTZO

No "Z"

else
if TZID is empty then

according to RFC, use localtime (floating)

RDT=DT

else

if event has no VTIMEZONE data about TZID offset

# (it could have data about another VTIMEZONE-TZID, but we don't care)...
if ETZO is empty then
  # ... and client has no VTIMEZONE data about TZID (including TZ aliases)
  if CTZO is empty then
    # we have no TZID offset data at all, use local time (floating)
    RDT=DT
  # ... but client has VTIMEZONE data about TZID offset
  else
    # use client's TZID offset and local time offset from UTC
    RDT=DT+LTZO-CTZO
  fi
# if event has VTIMEZONE data about TZID offset...
else
  # ... and client has no data about TZID offset (including TZ aliases)
  if CTZO is empty then
    # use event's TZID offset and local time offset from UTC
    RDT=DT+LTZO-ETZO
  else
    # ... and client has the same VTIMEZONE data about TZID offset as event has
    if CTZO = ETZO then
      # use event's or client's TZID offset and local time offset from UTC
      RDT=DT+LTZO-CTZO
    # ... and client's TZID offset data differs from event's TZID data.
    else
      # this is the moot point:
      #  * from one side, ORGANIZER should know the correct time of event.
      #    If the calculated time he gets using his own client is correct, all is ok, isn't it?
      #  * from another side, ORGANIZER's client could have wrong (old) timezone data and/or current time.
      #    This may lead client to display correct time with both wrong TZ and wrong current time settings.
      #    So, if this event is shared with someone else (which has correct TZ data and
      #    correct current time settings), his client's time will differ from ORGANIZER's time.
      #    This rule also works in reverse direction - when ORGANIZER has the right settings,
      #    but ATTENDEE doesn't.
      # We should choose, which TZID offset to use. Both choices may lead to a difference in time between clients.
      # But broken client is free to set another timezone (there are many),
      # which will give the same correct offset/time used by another participant - this is an easy workaround.
      # So, I take the side of fresh-updated clients and correctly configured time/timezone.
      # Like lightning does. Client's TZID offset overrides event's TZID offset.
      RDT=DT+LTZO-CTZO
    endif
  endif
endif

endif
endif

Here is the optimized variant:

if Z then
RDT=DT+LTZO
else
if TZID is empty then
RDT=DT
else
if CTZO is empty then
if ETZO is empty then
RDT=DT
else
RDT=DT+LTZO-ETZO
endif
else
RDT=DT+LTZO-CTZO
endif
endif
endif
return RDT


About 9,10, they are anyway inconsistent. DAVdroid treats them closer to RFC, but others get more "human" info from such events.
If we'd like to treat cases 9,10 as DAVdroid, we should skip all code above if VALUE=DATE, and set both DTSTART/DTEND to 00:00:00 if VALUE=DATE-TIME and the given format is yyyymmhh.

About 11,12,13 - here is the Lightning-like algorithm:

Variables:

DTS # true if current DTSTR is DTSTART
DTE # true if current DTSTR is DTEND
D # true if current DTSTR is yyyymmdd formatted
ADE # current event is all-day event flag, defaults to false
RD # resulting date, yyyymmdd
RT # resulting time, hhmmss

f_datetime(DT) functions is described above

f_date(DT) is a function which input is any DTSTR

and output is the resulting date (yyyymmdd formatted).

f_d(RDT) is a function which input is RDT-formatted string, output - yyyymmdd formatted date

f_t(RDT) is a function which input is RDT-formatted string, output - hhmmss formatted time

The next function input is DTSTR,DTS,DTE

and output ADE,RD,RT.

if DTS then
if not D then
RD=f_d(f_datetime(DTSTR))
RT=f_t(f_datetime(DTSTR))
else
ADE=true
RD=f_date(DTSTR)
RT=000000
fi
fi
if DTE then
if not ADE and not D then
RD=f_d(f_datetime(DTSTR))
RT=f_t(f_datetime(DTSTR))
else
RD=f_date(DTSTR)
RT=000000
fi
fi
return ADE,RD,RT

similar if-else could be made about DUE,EXDATE,RDATE,TRIGGER


As I can see the required changes should be made near "SOPE/NGCards/iCalDateTime.m"

Hope this will help to fix this bug (and may be others). I'm ready to provide more info, tests, etc.

Thanks for attention!

Sergey Urushkin

Sergey Urushkin

2015-11-06 11:28

reporter  

T01.ics (225 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d01
SUMMARY:T01
DESCRIPTION:without Z/TZID/VTIMEZONE/VALUE
DTSTART:20151103T120000
DTEND:20151103T130000
END:VEVENT
END:VCALENDAR
T01.ics (225 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:28

reporter  

T02.ics (233 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d02
SUMMARY:T02
DESCRIPTION:with Z. without TZID/VTIMEZONE/VALUE
DTSTART:20151103T120000Z
DTEND:20151103T130000Z
END:VEVENT
END:VCALENDAR
T02.ics (233 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:29

reporter  

T03.ics (419 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Moscow
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0300
TZNAME:MSK
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d03
SUMMARY:T03
DESCRIPTION:with Z/TZID/VTIMEZONE. without VALUE
DTSTART;TZID=Europe/Moscow:20151103T120000Z
DTEND;TZID=Europe/Moscow:20151103T130000Z
END:VEVENT
END:VCALENDAR
T03.ics (419 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:29

reporter  

T04.ics (269 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d04
SUMMARY:T04
DESCRIPTION:with TZID. without Z/VTIMEZONE/VALUE
DTSTART;TZID=Europe/Moscow:20151103T120000
DTEND;TZID=Europe/Moscow:20151103T130000
END:VEVENT
END:VCALENDAR
T04.ics (269 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:29

reporter  

T05.ics (417 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Moscow
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0300
TZNAME:MSK
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d05
SUMMARY:T05
DESCRIPTION:with TZID/VTIMEZONE. without Z/VALUE
DTSTART;TZID=Europe/Moscow:20151103T120000
DTEND;TZID=Europe/Moscow:20151103T130000
END:VEVENT
END:VCALENDAR
T05.ics (417 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:29

reporter  

T06.ics (423 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Moscow
BEGIN:STANDARD
TZOFFSETFROM:+0400
TZOFFSETTO:+0400
TZNAME:MSK
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d06
SUMMARY:T06
DESCRIPTION:with TZID/wrong-VTIMEZONE. without Z/VALUE
DTSTART;TZID=Europe/Moscow:20151103T120000
DTEND;TZID=Europe/Moscow:20151103T130000
END:VEVENT
END:VCALENDAR
T06.ics (423 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:29

reporter  

T07.ics (449 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Euro1pe/M123oscow1
BEGIN:STANDARD
TZOFFSETFROM:+0400
TZOFFSETTO:+0400
TZNAME:MSK1
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d07
SUMMARY:T07
DESCRIPTION:with unknown-TZID/unknown-VTIMEZONE. without Z/VALUE
DTSTART;TZID=Euro1pe/M123oscow1:20151103T120000
DTEND;TZID=Euro1pe/M123oscow1:20151103T130000
END:VEVENT
END:VCALENDAR
T07.ics (449 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:29

reporter  

T08.ics (287 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d08
SUMMARY:T08
DESCRIPTION:with unknown-TZID. without Z/VTIMEZONE/VALUE
DTSTART;TZID=Euro2pe/M234oscow2:20151103T120000
DTEND;TZID=Euro2pe/M234oscow2:20151103T130000
END:VEVENT
END:VCALENDAR
T08.ics (287 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:30

reporter  

T09.ics (288 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d09
SUMMARY:T09
DESCRIPTION:with VALUE=DATE and format is yyyymmddThhmmss. without Z/TZID/VTIMEZONE
DTSTART;VALUE=DATE:20151103T120000
DTEND;VALUE=DATE:20151103T130000
END:VEVENT
END:VCALENDAR
T09.ics (288 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:30

reporter  

T10.ics (282 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d10
SUMMARY:T10
DESCRIPTION:with VALUE=DATE-TIME and format is yyyymmdd. without Z/TZID/VTIMEZONE
DTSTART;VALUE=DATE-TIME:20151103
DTEND;VALUE=DATE-TIME:20151104
END:VEVENT
END:VCALENDAR
T10.ics (282 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:30

reporter  

T11.ics (258 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d11
SUMMARY:T11
DESCRIPTION:with DTSTART/DTEND-VALUE=DATE. without Z/TZID/VTIMEZONE
DTSTART;VALUE=DATE:20151103
DTEND;VALUE=DATE:20151104
END:VEVENT
END:VCALENDAR
T11.ics (258 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:30

reporter  

T12.ics (290 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d12
SUMMARY:T12
DESCRIPTION:with DTSTART-VALUE=DATE-TIME and DTEND-VALUE=DATE. without Z/TZID/VTIMEZONE
DTSTART;VALUE=DATE-TIME:20151103T120000
DTEND;VALUE=DATE:20151104
END:VEVENT
END:VCALENDAR
T12.ics (290 bytes)   
Sergey Urushkin

Sergey Urushkin

2015-11-06 11:30

reporter  

T13.ics (290 bytes)   
BEGIN:VCALENDAR
PRODID:-//Test//
VERSION:2.0
BEGIN:VEVENT
UID:d2240999-ab22-410e-97e9-8f562cb87d13
SUMMARY:T13
DESCRIPTION:with DTSTART-VALUE=DATE and DTEND-VALUE=DATE-TIME. without Z/TZID/VTIMEZONE
DTSTART;VALUE=DATE:20151103
DTEND;VALUE=DATE-TIME:20151104T130000
END:VEVENT
END:VCALENDAR
T13.ics (290 bytes)   
martin.grotzke

martin.grotzke

2016-11-20 09:37

reporter   ~0010894

Are there any news regarding this issue, plans to improve the situation?

ludovic

ludovic

2016-12-22 20:53

administrator   ~0011097

I've had a look today and this is fairly nasty because in all SOPE/NGCards/* classes, we don't have access to the user's timezone.

Related Changesets

sogo: master 477c06a7

2016-12-30 12:26

ludovic


Details Diff
(fix) fix events in floating time during CalDAV's PUT operation (fixes 0002865) Affected Issues
0002865
mod - SoObjects/Appointments/SOGoAppointmentFolder.m Diff File
mod - SoObjects/Appointments/SOGoAppointmentObject.m Diff File

sogo: v2 72c03390

2016-12-30 12:26

ludovic


Details Diff
(fix) fix events in floating time during CalDAV's PUT operation (fixes 0002865) Affected Issues
0002865
mod - SoObjects/Appointments/SOGoAppointmentFolder.m Diff File
mod - SoObjects/Appointments/SOGoAppointmentObject.m Diff File

sogo: maint 78373433

2016-12-30 12:26

ludovic

Committer: francis


Details Diff
(fix) fix events in floating time during CalDAV's PUT operation (fixes 0002865) Affected Issues
0002865
mod - SoObjects/Appointments/SOGoAppointmentFolder.m Diff File
mod - SoObjects/Appointments/SOGoAppointmentObject.m Diff File

Issue History

Date Modified Username Field Change
2014-07-21 11:42 ams077 New Issue
2015-04-08 12:46 pbra Note Added: 0008401
2015-04-08 12:47 pbra Note Edited: 0008401
2015-11-06 11:27 Sergey Urushkin Note Added: 0009077
2015-11-06 11:28 Sergey Urushkin File Added: T01.ics
2015-11-06 11:28 Sergey Urushkin File Added: T02.ics
2015-11-06 11:29 Sergey Urushkin File Added: T03.ics
2015-11-06 11:29 Sergey Urushkin File Added: T04.ics
2015-11-06 11:29 Sergey Urushkin File Added: T05.ics
2015-11-06 11:29 Sergey Urushkin File Added: T06.ics
2015-11-06 11:29 Sergey Urushkin File Added: T07.ics
2015-11-06 11:29 Sergey Urushkin File Added: T08.ics
2015-11-06 11:30 Sergey Urushkin File Added: T09.ics
2015-11-06 11:30 Sergey Urushkin File Added: T10.ics
2015-11-06 11:30 Sergey Urushkin File Added: T11.ics
2015-11-06 11:30 Sergey Urushkin File Added: T12.ics
2015-11-06 11:30 Sergey Urushkin File Added: T13.ics
2016-11-20 09:37 martin.grotzke Note Added: 0010894
2016-12-22 20:53 ludovic Note Added: 0011097
2016-12-22 20:56 ludovic Relationship added has duplicate 0002716
2016-12-22 20:56 ludovic Relationship added has duplicate 0002707
2016-12-22 20:56 ludovic Severity minor => major
2016-12-30 17:27 ludovic Changeset attached => sogo master 477c06a7
2016-12-30 17:27 ludovic Assigned To => ludovic
2016-12-30 17:27 ludovic Resolution open => fixed
2016-12-30 17:28 ludovic Changeset attached => sogo v2 72c03390
2016-12-30 17:30 ludovic Status new => resolved
2016-12-30 17:30 ludovic Fixed in Version => 3.2.5
2017-01-09 20:49 francis Changeset attached => sogo maint 78373433