Closed Bug 359026 Opened 13 years ago Closed 13 years ago

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

Categories

(Calendar :: General, defect)

Lightning 0.3
x86
Windows XP
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: frank.schoenheit, Assigned: michael.buettner)

Details

Attachments

(1 file)

- 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.
AFAIK this is already implemented in the current prototype event dialog: Menu Options->Show Time as [Free|Busy].
=> FIXED?
Assignee: nobody → michael.buettner
Component: Provider: WCAP → General
Summary: all-day events not included in calculating availability (even if set up so) → [proto event dialog] all-day events not included in calculating availability (even if set up so)
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?
> 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.
(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.
> 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.
Assignee: michael.buettner → nobody
QA Contact: wcap-provider → general
ooops, clicked the wrong radio button in my previous submission. Sorry. assigning back.
Assignee: nobody → michael.buettner
also correcting QA contact, sorry
QA Contact: general → wcap-provider
(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
Attached patch patch v1Splinter Review
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.
Checked in on trunk and MOZILLA_1_8_BRANCH
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
QA Contact: wcap-provider → general
You need to log in before you can comment on or make changes to this bug.