Closed Bug 352872 Opened 18 years ago Closed 16 years ago

improve UI for moving to readonly calendars in the event dialog

Categories

(Calendar :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mvl, Unassigned)

Details

(spin off from bug 352865)
When editing an event, you can still select readonly calendars as target calendar. That does show an error now, but that is still not optimal.

One solution would be ths that for events that are in writable
calendars, don't show any readonly calendars in the menu. And for events that
are in a readonly calendar, we should somehow be disabling that UI entirely, perhaps by making it a label instead of a menu.

Another solution would be to disable readonly calendars from the menulist, to make it more clear that they are not gone, but readonly.
can we close this issue? since we moved to new event/task UI this seems to be not valid any more
Whiteboard: [qa discussion needed]
Probably this issue is indeed no longer relevant, as the new event dialog filters out calendars that are readonly, see [1]. Furthermore, displaying items from readonly calendars will now be handled by the new summary dialog, see Bug 361977.

[1] http://lxr.mozilla.org/mozilla/source/calendar/prototypes/wcap/sun-calendar-event-dialog.js#310
We need to figure out what to do with all of these "old event dialog bugs".

I don't think that closing them outright is proper if there are ways to still turn the old event dialog back on.

Let's discuss this in the newsgroup after 0.7 is released so that end-users can voice their opinions on the two dialogs.

Leaving on the QA Discussion List Until this ^^ discussion happens.
This is only happening in the old event dialog. Since 0.7 we've moved to a new dialog.

--> WONTFIX
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Whiteboard: [qa discussion needed]
You need to log in before you can comment on or make changes to this bug.