Open
Bug 553928
Opened 14 years ago
Updated 2 years ago
Switching a Calendar Readonly disables all event dialog controls
Categories
(Calendar :: Dialogs, defect)
Calendar
Dialogs
Tracking
(Not tracked)
NEW
People
(Reporter: Fallen, Unassigned)
Details
(Keywords: uiwanted)
Attachments
(3 files)
48.93 KB,
image/jpeg
|
Details | |
10.44 KB,
image/png
|
Details | |
39.02 KB,
patch
|
Fallen
:
review-
andreasn
:
ui-review-
|
Details | Diff | Splinter Review |
STR: 1. Make sure you have two writable calendars A and B. 2. Open an event on calendar A. 3. Switch the calendar dropdown to calendar B. 4. Mark calendar A readonly 5. Switch the dropdown back to calendar A. Actual Result: * Most (but not all) dialogs controls are disabled Expected Result: * Either we should really disable all controls, but I'd prefer the next option: * After Step 4, a notification bar should show at the top telling the user he cannot save the event on the current calendar since its not writable. * While bar is showing, disable all save related controls and when closing.
Updated•14 years ago
|
Assignee: nobody → Mozilla
Comment 1•14 years ago
|
||
The proposed solution sounds very elegant. Only one question arises: Should we really let someone edit an event that can not be saved at the moment? I think yes, but maybe we should add an advice shown that one can save it if he changes to a writable calendar. Marking uiwanted to get some more feedback.
Status: NEW → ASSIGNED
Keywords: uiwanted
Comment 2•14 years ago
|
||
Some additional comments: The choose-calendar control is also disabled, so one can't switch back to a writable calendar. when canceling the dialog on a read-only calendar, the confirmation asks "save, don't save or cancel?". This also has to be changed.
Comment 3•14 years ago
|
||
This is a screenshot of how the Dialog will look.
Comment 4•14 years ago
|
||
Since the event can not be saved in a read only calendar, the confirmation prompt on canceling the dialog has to be different. I thought about just leaving out the "save" button, but with the prompt if you want to save, this is confusing.
Comment 5•14 years ago
|
||
The patch has one known problem: If the current selected calendar in the event-dialog changes it's status to "read-only", the dialog does not get updated. A similar problem was already adressed in a comment to bug 402421 [1] and I think this is related. This will be checked in after 1.0b2, because of the string changes. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=402421#c8
Attachment #445995 -
Flags: ui-review?(clarkbw)
Attachment #445995 -
Flags: review?(ssitter)
Attachment #445995 -
Flags: feedback?(philipp)
Updated•14 years ago
|
Whiteboard: [not needed beta]
Target Milestone: --- → 1.0
Updated•14 years ago
|
Attachment #445995 -
Flags: review?(ssitter) → review?
Updated•14 years ago
|
Attachment #445995 -
Flags: review?(philipp)
Attachment #445995 -
Flags: review?
Attachment #445995 -
Flags: feedback?(philipp)
Reporter | ||
Updated•14 years ago
|
Attachment #445995 -
Attachment description: Patch V1 → [needs ui-r] Patch V1
Comment 6•14 years ago
|
||
Adding andreas who's going to take over the review
Updated•14 years ago
|
Attachment #445995 -
Flags: ui-review?(clarkbw) → ui-review?(nisses.mail)
Comment 7•14 years ago
|
||
This is a good step forward, as you no longer end up in a dead-end-street where you can't even switch back to the writable calendar. I'm wondering though, are you sure you even want to be able to switch to a unreadable calendar from this dialog? As far as I can tell, this is the only way to get to a new event in an unwritable calendar, so what about this: Since you're doing a check if it's readable or not, would it be possible to do that on the dropdown click and just gray out the unwritable calendar there?
Comment 8•14 years ago
|
||
Sounds reasonable. The only case when this is'nt enough, would be if we get the notification to this dialog, when a calendar gets unwritable while editing an event. If this is some time implemented, we would have to think again. Should we have that in mind now or is it likely, that this notification will never be omplemented?
Reporter | ||
Comment 9•14 years ago
|
||
Comment on attachment 445995 [details] [diff] [review] Patch V1 Since the behavior should be slightly changed, r- on this patch. Keeping ui-r? to answer comment 8.
Attachment #445995 -
Flags: review?(philipp) → review-
Reporter | ||
Comment 10•14 years ago
|
||
Comment on attachment 445995 [details] [diff] [review] Patch V1 Some comments on the code of the current patch: >+ // increment choice by one, because the prompt has one button less. >+ choice += 1; choice++; >+askSaveTitleReadOnly=Can not Save I believe the correct wording is "Cannot Save", maybe a native speaker can confirm. >+askSaveMessageReadOnly=Current calendar is Read only. Do you want to close the dialog and discard changes? Please check how we've written it elsewhere and whats correct: read only vs readonly vs read-only vs ... In any case, read needs to be lower case, and I'd start with "The current calendar...".
Attachment #445995 -
Attachment description: [needs ui-r] Patch V1 → Patch V1
Comment 11•14 years ago
|
||
(In reply to comment #8) > Sounds reasonable. > The only case when this is'nt enough, would be if we get the notification to > this dialog, when a calendar gets unwritable while editing an event. > If this is some time implemented, we would have to think again. > > Should we have that in mind now or is it likely, that this notification will > never be omplemented? Perhaps we should do that as a new bug report in that case. Making it impossible to select in the first case as I described in comment 7 would take care of the issue described in this bug.
Comment 12•14 years ago
|
||
Comment on attachment 445995 [details] [diff] [review] Patch V1 Giving ui-r minus on this, as I think it can be done in a more elegant way.
Attachment #445995 -
Flags: ui-review?(nisses.mail) → ui-review-
Reporter | ||
Updated•13 years ago
|
Target Milestone: 1.0 → ---
Comment 13•13 years ago
|
||
How do we continue on this one? Is the proposal from comment 7 a solution that can be agreed on?
Updated•4 years ago
|
Assignee: Mozilla → nobody
Status: ASSIGNED → NEW
Whiteboard: [not needed beta]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•