Closed Bug 395187 Opened 17 years ago Closed 17 years ago

Creating events for read only calendar

Categories

(Calendar :: Calendar Frontend, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: omar.bajraszewski, Assigned: Fallen)

References

Details

Attachments

(1 file)

Selecting 'new event' for read only calendar opens event summary dialog which is wrong. A warning message should be opened instead of it

1)Mark a calendar as read only
2)double click in calendar view

Result:
A summary dialog is opened

Expected result:
A warning message
I'd propose to plain do nothing when double clicking on the views and disable the menu items "New Event / Task".
... or to introduce a "This is my primary calendar" flag. With that flag users would have some kind of "fall back" calendar which would be used, if users try to create an event in a read only calendar.

Flags: blocking-calendar0.7?
OS: Windows XP → All
Hardware: PC → All
This patch makes sure the new item's calendar is not readOnly, changing if
needed. There are a few considerations that need ui-review:

With this patch, if all calendars are marked readonly, clicking on the new
event/task button or double clicking in the views will not do anything. We
might need to disable the event creation commands when all calendars are
readonly, but given that we are very near to a release, this might increase
regression risks.

The question for 0.7 is, do we want the useless event dialog to show, or have
buttons that do not do anything? Or do we want to hold the release to disable
all creation commands?
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #282236 - Flags: ui-review?(christian.jansen)
Attachment #282236 - Flags: review?(michael.buettner)
Comment on attachment 282236 [details] [diff] [review]
[checked in] fix v1

The logic is indeed horrible, but from a code perspective I don't have any complaints. I think this solution is good enough to take for 0.7 (at least it's better than the current solution), but should be revised soon after the release is out. But as always, I leave the final decision to Christian. r=mickey.
Attachment #282236 - Flags: review?(michael.buettner) → review+
Flags: blocking-calendar0.7? → blocking-calendar0.7+
(In reply to comment #5)
> Created an attachment (id=282236) [details]

> The question for 0.7 is, do we want the useless event dialog to show, or have
> buttons that do not do anything? Or do we want to hold the release to disable
> all creation commands?

If all calendars are read only, creating event/tasks should be disabled in menus respectively toolbars.
I discussed this with Christian, and we came to basically the same conclusion as stated in comment #6: we want the patch for 0.7 as it improves the situation, but will revise the overall "default calendar for writing" handling post 0.7.
Taking this bug from blocker list and keeping it open for further discussion (if necessary).

Checked the patch in on HEAD and MOZILLA_1_8_BRANCH; thanks Philipp!
Flags: blocking-calendar0.7+
Thanks for taking care. As soon as bug 379174 is fixed, we can take care of keeping track if all calendars are readonly or not, and disable event creation if needed.
Depends on: 379174
Attachment #282236 - Attachment description: fix v1 → [checked in] fix v1
Attachment #282236 - Flags: ui-review?(christian.jansen) → ui-review+
Fixed by bug 379174.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.8
Verified with Lightning 0.8pre (2007111404) on WinXP.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.