288925 - event end datetime displayed incorrectly in event list (unifinder) [trunk]

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: trunk

event end datetime displayed incorrectly in event list (unifinder).

Problem is in unifinder.js -- erroneously adding the duration to the end
datetime (previously added duration to next occurrence *start* datetime, but
currently does not look for next occurrence so uses the bare end datetime).

Reproducible: Always

Steps to Reproduce:
1.  Create an event of non-zero duration (end later than start).
2.  Make sure end date column is visible in event list.

Actual Results:  
End datetime shown is long after actual end datetime (edit event to bring up
event dialog)

Expected Results:  
End datetime shown in table is same as actual end datetime.

Comment 1

[gekacheka]

Attachment: unifinder.js patch: comment out addition of duration since not adding to start of occurence

(patch -l -p 2 -i file.patch)

Since eventEndDate is initially the end date rather than the start of the next
occurrence, this patch just comments out the code that adds the event duration
to it.

(It looks like getNextOccurrence is not yet implemented, so it is not possible
to fix this for reccurrences yet.  It is defined to return calIItemOccurrence,
but that interface doesn't seem to be defined.
http://lxr.mozilla.org/seamonkey/source/calendar/base/public/calIRecurrenceInfo.idl#88


Also need getPreviousOccurrence (or getLastOccurrence), to be able to show the
times of the last occurrence if now is after the last occurrence.)

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

i don't think this is the right fix. We should fig bug 285033 and then look for
the right thing here.

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 179549 [details] [diff] [review]
unifinder.js patch: comment out addition of duration since not adding to start of occurence

(requesting review from nobody isn't the fastest way to get review...)
this is now fixed with bug 286070.

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

Resolving for real now.