Closed
Bug 395187
Opened 17 years ago
Closed 17 years ago
Creating events for read only calendar
Categories
(Calendar :: Calendar Frontend, defect)
Calendar
Calendar Frontend
Tracking
(Not tracked)
VERIFIED
FIXED
0.8
People
(Reporter: omar.bajraszewski, Assigned: Fallen)
References
Details
Attachments
(1 file)
1.83 KB,
patch
|
michael.buettner
:
review+
Fallen
:
ui-review+
|
Details | Diff | Splinter Review |
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
Comment 1•17 years ago
|
||
I'd propose to plain do nothing when double clicking on the views and disable the menu items "New Event / Task".
Comment 2•17 years ago
|
||
... 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.
Assignee | ||
Updated•17 years ago
|
Flags: blocking-calendar0.7?
OS: Windows XP → All
Hardware: PC → All
Assignee | ||
Comment 5•17 years ago
|
||
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 6•17 years ago
|
||
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+
Updated•17 years ago
|
Flags: blocking-calendar0.7? → blocking-calendar0.7+
Comment 7•17 years ago
|
||
(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.
Comment 8•17 years ago
|
||
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+
Assignee | ||
Comment 9•17 years ago
|
||
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
Assignee | ||
Updated•17 years ago
|
Attachment #282236 -
Attachment description: fix v1 → [checked in] fix v1
Attachment #282236 -
Flags: ui-review?(christian.jansen) → ui-review+
Assignee | ||
Comment 10•17 years ago
|
||
Fixed by bug 379174.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.8
Comment 11•17 years ago
|
||
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.
Description
•