Closed Bug 195580 Opened 21 years ago Closed 16 years ago

Can't use delete button to delete task or calendar

Categories

(Calendar :: Internal Components, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Lil46john, Assigned: Fallen)

References

Details

(Keywords: access)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030228
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030228

I make a new task and can delete it with right-click delete, but can't with the
toolbar.

Reproducible: Always

Steps to Reproduce:
1. Create a new task
2. Try to delete with toolbar.
3.

Actual Results:  
Delete button on toolbar is greyed out.

Expected Results:  
Not have it greyed out.
If an event is selected and then you select a task, the delete button is not
greyed out but the selection of the event is not deactivated either. The delete
button is still related to the selected event. Furthermore, hitting the key
<del> would even delete the event instead of the task without any warning. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
Also happens to Calendar Files
Summary: Can't delete task with delete button on toolbar. → can't use delete button to delete task or calendar
New contact from mikep@oeone.com to mostafah@oeone.com
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.
Assignee: mikep → mostafah
I see this on Linux too.
OS: Windows XP → All
The problem seems to be ambiguity about which selected item will be acted upon
by the toolbar buttons (edit, delete) or menu commands (copy, etc.)

One approach is to make selecting a task to deselect any events.  This
particularly makes sense for tasks and events, which can appear in the same
schedule.

Another approach is for the command to use the selection in the focussed pane. 
This requires changing the appearance of the selected item in the defocussed
panes, so it is clear which one will be acted upon.  For example, the selected
item in the focused pane can be highlighted by background color, and the
selected item in a defocused pane could be highlighted by outline.
The new Sunbird menu wants one "Delete" item rather than both "Delete Selected
Events" and "Delete Selected Tasks".

It seems the root of this issue -- multiple items (and event and a task) being
selected at once -- are the reason for the discrete delete menuitems in the
first place.

IMHO: Selecting a task and hitting Del or Bkspce deleting a different event,
which may not even be in my current view, is not a "minor" issue, but borders on
dataloss. 

Maybe this can we fixed in the reworking of the views?

Setting severity to normal, milestone to SB0.3
Blocks: 275695
Severity: minor → normal
Hardware: PC → All
Target Milestone: --- → Sunbird 0.3
'delete' should delete whatever item is deleted in whatever pane is currently
active. compare to mailnews: selecting a folder, then pressing delete on the
menubar deletes the folder. seleting an email deletes the mail.

In my current build, if i first select an event it gets a bleu background. After
selecting a task, the event gets a gray background. So the problem in comment 5
already worksforme.
ALL views with selection need to indicate focus.

Comment #7 sounds like the Calendar/Sunbird event list.  
The selection in the Calendar/Sunbird event list or calendar list does gray out
when the pane loses focus. 

However, last time I checked, the selection in the task list or in any of the
grid views does not change appearance when it loses focus, that's where the
problem is.  In fact, I don't think the Calendar/Sunbird grid views implement
focus, only selection.
Hmm, yes, true. Only the event list grays out.
Another solution would be to use a focus rectangle on the pane, just like
mailnews. The selection is always blue there, but one pane has a focus
rectangle. That pane is hat the delete button will act on.
I think that's easier to implement than to make every view implement focus and
selection.
QA Contact: gurganbl → general
*** Bug 333625 has been marked as a duplicate of this bug. ***
Assignee: mostafah → base
Component: General → Base
QA Contact: general → base
Summary: can't use delete button to delete task or calendar → Can't use delete button and key to delete task or calendar
Version: unspecified → Trunk
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
Not going to make the 0.3 train.
Target Milestone: Sunbird 0.3 → ---
This bug should block calendar 0.5
Flags: blocking-calendar0.5?
This would be nice to have for 0.5, but we won't be holding the release for it.
Flags: blocking-calendar0.5? → blocking-calendar0.5-
Flags: blocking-calendar0.7?
Christian, is this still a valid bug for 0.7 considering the UI changes that we are going to make?

If not, please WONTFIX it.
Delete key works now for removing tasks
Summary: Can't use delete button and key to delete task or calendar → Can't use delete button to delete task or calendar
Forget what I said. I can reproduce it with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9pre) Gecko/20071103 Calendar/0.8pre

0.7 is released- removing request for blocking 0.7
Flags: blocking-calendar0.7? → wanted-calendar0.8?
Version: Trunk → unspecified
This is fixed for Calendars, but not for tasks in task mode. The delete button in mail mode also applies only to mails.

Mickey, Berend, can you perhaps look into this?
Flags: wanted-calendar0.8?
Flags: wanted-calendar0.8+
Flags: blocking-calendar0.5-
Flags: wanted-calendar0.8+ → blocking-calendar0.8+
This could become quite easy if bug 402325 is fixed. The command should be renamed to delete_selected_calendar_item_command / edit_selected_calendar_item_command or similar.
Depends on: 402325
Assignee: nobody → philipp
This patch goes the route of using a command controller for lightning, The more general lightning_delete_item_command either executes calendar_delete_todo_command or calendar_delete_event_command, depending on mode.

Also, some changes to the storage provider were needed to make sure its possible to delete all non-readonly selected items.
Attachment #297170 - Flags: review?(michael.buettner)
Status: NEW → ASSIGNED
Comment on attachment 297170 [details] [diff] [review]
Make Delete/Edit respect mode

Didn't find anything to complain about. r=mickey.
Attachment #297170 - Flags: review?(michael.buettner) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.8
Needs additional patch to not produce errors on sunbird. Checking in now.
Either I don't understand the interface, or this bug is not fixed. I put a screenshot online which shows the problem:
http://staff.science.uva.nl/~jliem/bugs/lightning-cannotdeletecalendar.png

I'm using Thunderbird 2.0.0.9, and I've tried Lightning 0.8rc1, and the latest nightly build of Lightning (2008031319). I'm on a Linux Fedora Core 8 box.

In the meantime, is there any other way to remove a calendar? By removing files for instance?
(In reply to comment #26)
You can't run Sunbird/Lightning without any calendar. Therefore at least one calendar must exist. If you want to replace the existing calendar with a new one: First create the new calendar, than delete the old calendar.
This is verified fixed. Thunderbird 2.0.0.12 / Lightning RC1 on Fedora
Jochem's pic might as well be mine as there seems no way possible to throw away an existing calendar.  (Sunbird 0.8 on PPC G4 10.4.x)  Thunderbird 2.0.0.14(20080421)/Lightning on OLD Pentium PC works well.

Love my Mac/iCal.  No complaints, just FYI.
(In reply to comment #29)
I followed Stefan's suggestion (comment #27), create another calendar, and then delete the old version. This solved the issue for me.

I do think this is an interface issue. There is no way for a user to know that there has to be at least one calendar. It would be nicer if the delete option would be available, and its selection would give an insightful error.
You need to log in before you can comment on or make changes to this bug.