359026 - [proto event dialog] all-day events not included in calculating availability (even if set up so)

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Frank Schönheit]

- using Sun Java(TM) System Calendar Express (I'm unable to find the
  concrete version anywhere in the application)
- in the web frontend:
  - create a new all-day even, using all defaults
  - check the "Include this event in calculating availability" checkbox
    in the event properties
  - save this event
- start Thunderbird with Lightning 0.3, the WCAP-enabled version
- create a new event for the same day
- change to the "Attendees" tab
=> in the availability overview, you (the creator) are listed to be
   available all day. The all-day event is not included in calculating
   the availability.

Comment 1

[Daniel Boelzle [:dbo]]

AFAIK this is already implemented in the current prototype event dialog: Menu Options->Show Time as [Free|Busy].
=> FIXED?

Comment 2

[Michael Büttner (no reviews TFN)]

This is not fixed since it behaves as it is currently designed. The free/busy grid shows busy-times for already stored items. In case the user modifies an event (e.g. selecting all-day) and immediately switches to the "invite attendees"-dialog , those changes won't be reflected (since the modification is still pending). but immediately storing the item isn't an option (at least not until we have a decent undo/redo stack in place). another option would be to filter the busy-times for the current event from the result-set the provider returns and calculate those times based on the current modifications made in the dialog. Opinions?

Comment 3

[Frank Schönheit]

> This is not fixed since it behaves as it is currently designed. The free/busy
> grid shows busy-times for already stored items.

Hmm? I do not know the prototyp you're talking about, but the original bug actually *is* about a stored item - an all-day event - whose "Use this even when Calculating availability" property is *set*. It's *not* about changes I just did in the dialog.

In particular, this hits when others do invite me: Thunderbird reports me as available, which isn't the case. It hasn't to do with the event others are just creating, it's only about the server-stored event of mine.

Comment 4

[Daniel Boelzle [:dbo]]

(In reply to comment #2)
> This is not fixed since it behaves as it is currently designed. The free/busy
> grid shows busy-times for already stored items. In case the user modifies an
> event (e.g. selecting all-day) and immediately switches to the "invite
> attendees"-dialog , those changes won't be reflected (since the modification is
> still pending). but immediately storing the item isn't an option (at least not

IMO we can live with that. Even now, when opening the event dialog by menu will get me a yet unsaved event with a free-busy grid that does not reflect the yet unsaved event, of course. If at all, we could reflect the in-the-change item programmatically in the free-busy grid, but storing the item is IMO a no-no.
As I understand Frank's initial RFE, it is about having that option at all.

Comment 5

[Frank Schönheit]

> As I understand Frank's initial RFE, it is about having that option at all.

Hmm. No.
My initial *bug* says that TB doesn't respect if I set up - in the web frontend, bypassing TB - an all-day event to affect availability.

With the build I'm using currently, this means all-day events become rather useless for this purpose (indicate non-availability).

With the new builds, which have this option ("include in availability") in the UI, this becomes less severe (if it works :), which I do not know), but nonetheless it's still a bug then.

Comment 6

[Frank Schönheit]

ooops, clicked the wrong radio button in my previous submission. Sorry. assigning back.

Comment 7

[Frank Schönheit]

also correcting QA contact, sorry

Comment 8

[Daniel Boelzle [:dbo]]

(In reply to comment #5)

Ah, got you now and have reproduced that bug. It seems to be in the attendee freebusy grid:
I have created an all-day busy event via web-frontend. Then creating a new event via double-click
- on that same day has no red busy indication although the server returns a busy entry for the whole day
- on the day before everything works fine, the preceeding day is marked as busy

Comment 9

[Michael Büttner (no reviews TFN)]

Attachment: patch v1

I was obviously a bit tired at the time I wrote the original code ;-) the calculation of the end-time for a busy-range didn't work for ranges that start at 0:00 (which is the case for all-day events, of course). besides not working for this case the calculation was totally crap. this two-line patch fixes the problem.

Comment 10

[Michael Büttner (no reviews TFN)]

Checked in on trunk and MOZILLA_1_8_BRANCH