Closed Bug 277731 Opened 16 years ago Closed 14 years ago
no way to convert task <-> event
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Users get confused about the terms "Event" and "Task". It is possible to create an event when you meant a task, or a task when you meant an event. Once you have done this, it is impossible to recover from the mistake and you have to tediously reenter all data. Reproducible: Always Steps to Reproduce: 1. Create a new event 2. Try to change the event to a task Actual Results: There was no quick and easy way to do this Expected Results: An option to choose what kind of calendar entry this would have solved this problem. Heh, I know because I did it. Normal users would probably have trouble with this too.
I agree. Editing the ICS file seems to be the most direct way to convert entries. But when other problems with the task list and event list are fixed, this one might just go away. For example, you might be able to convert an entry using drag and drop, or cut and paste.
Summary: poor usability, lack of task/event conversion → no way to convert task <-> event
The UI for it exist now, however it's not possible. When trying to convert I get this error in the JS console: Error: [Exception... "'Can not modify immutable data container' when calling method: [calIEvent::title]" nsresult: "0x80460002 (NS_ERROR_OBJECT_IS_IMMUTABLE)" location: "JS frame :: chrome://calendar/content/eventDialog.js :: onOKCommand :: line 526" data: no] Source File: chrome://calendar/content/eventDialog.js Line: 526 Does this require a new bug report or can we handle this in this bug?
(In reply to comment #2) > When trying to convert I get this error in the JS console I'm terribly sorry, forgot to mention, this is on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050814 Mozilla Sunbird/0.2+
*** Bug 310257 has been marked as a duplicate of this bug. ***
Confirming based on the duplicate and my own experience with the 20050924 nightly build on WinXP. The error in the JS console has changed a little bit, probably due to recent checkins to eventDialog.js: Error: [Exception... "'Can not modify immutable data container' when calling method: [calIEvent::title]" nsresult: "0x80460002 (NS_ERROR_OBJECT_IS_IMMUTABLE)" location: "JS frame :: chrome://calendar/content/eventDialog.js :: onOKCommand :: line 541" data: no] Source File: chrome://calendar/content/eventDialog.js Line: 541
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 321912 has been marked as a duplicate of this bug. ***
Reassigning all automatically assigned bugs from Mostafa to firstname.lastname@example.org Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
I love when code is architectured to make a problem simple. cloneItemBaseInto is exactly what we need here to make this work. Then it's just a matter of mapping the times around. dmose mentioned that some of the task-management programs he's been playing with offer this, and that he's found it extremely useful.
Assignee: nobody → jminta
Status: NEW → ASSIGNED
Attachment #231183 - Flags: first-review?(dmose)
It would be great to convert betwenn task and event (task <=> event), and using "drag&drop" would be perfect.
I doubt that there's a use case for this feature, so I'd vote against adding it at all.
When this bug was originally logged; it was possible to add tasks / events in a very similar fashion; and then impossible to change something to an event if you accidentally logged a task. thunderbird version 3 alpha 1 + lightning (20060921) no longer exhibit this behaviour.
But because there isn't many differences between tasks and events, why not let convert task to events, or event to tasks?
(In reply to comment #12) > But because there isn't many differences between tasks and events, why not let > convert task to events, or event to tasks? for two reasons. first, just because something is technically possible doesn't mean it should be integrated. as long as there's no real use case i can't see a reason for converting items back and forth. second, the dialog would most probably need to resize to fit the different ui blocks that are specific to items and events. this could probably mean that the whole window needs to resize to fit the different items, which could be distracting. the first reason is what i consider to be the real blocker, the second one is just a minor implementation issue. again, what is the use case for converting items?
I think is useful because a lot of people doesn't know the difference between task and events, (it's a bit strange that tasks has startdate and enddate as if it was an event). It is not necessary to change it from the dialog: a simple function like a menu entry on right click that says: "Convert this event to a task", or "Convert this task to an envent", could be useful.
I strongly support offering this functionality. Use case #1 (personal): I have to take my dog to the vet to get his vaccinations, so I put "Take Killer to the vet" in my task list, due by the end of the month. After seeing it there for a few days, I finally call up the vet and get an appointment scheduled for next Monday. Now I need to convert that task to an event that's scheduled from 2:00-4:00 on Monday. Use case #2 (business): I'm asked to put together a legal brief on a doctor's level of exposure for an upcoming trial being run by one of the firm's partners. This obviously goes in my task list. After gathering the required information, I bump into the partner in the hall and ask "When's a good time for me to talk with you about what I've found?" He suggests 3:00 tomorrow, at which point I need to convert the task into an event at that time. Both of these cases involve a situation where an item which previously did not have a fixed schedule suddenly gets a fixed set of times. Since our current UI requires that items without times be tasks and since once they get times they are clearly events, the conversion is necessary. I'll note in passing that it may be possible to avoid this conversion need by playing with semantics. You could offer 'unscheduled events' which would later be converted to scheduled events. No matter how you word-smith this, some version of this functionality needs to be available to handle these kinds of cases.
This all boils down to: 'what is a task, and what an event?' I suggest moving that discussion to the newsgroup.
(In reply to comment #16) > This all boils down to: 'what is a task, and what an event?' I suggest moving > that discussion to the newsgroup. I support this suggestion, obviously there are some fundamental bits and pieces that need to be resolved...
Comment on attachment 231183 [details] [diff] [review] use cloneItemBaseInto I moved the discussion to the newsgroup, as requested. There, the majority of respondents suggested that the ability to convert was a minimum requirement for making tasks and events correspond with their mental models. Use-cases (from misclicking a button to scheduling time for a task in the views) and usability arguments (that uniformed forced choices cause user-pain) were put forth. This patch has now been pending for 3 months and I'd really like to move it forward. Shifting reviewers to try and find available free time from peers.
We decided in the last calendar status meeting that we want to drop this feature (at least for 0.5). please see http://wiki.mozilla.org/Calendar:Status_Meetings:2006-10-25. the reason for this decision is that a simple conversion between task and event causes dataloss and we'd need a smarter way of handling this kind of feature (e.g. drag'n'drop but leave the original item intact, etc.)
(In reply to comment #19) The only dataloss I can think of here is completion information. There are two options, as I see it: (1) The user is implicitly accepting this, since they are choosing to change the model their item fits. (2) Preserve the data in X-Props. Neither is a difficult to handle, and if that's the only reason, it may be grounds for an r-, but not for an indefinite suspension of a bug that improves usability significantly.
(In reply to comment #20) > The only dataloss I can think of here is completion information. There are two options, as I see it: (1) The user is implicitly accepting this, since they are choosing to change the model their item fits. (2) Preserve the data in X-Props. exactly, the completion information would get lost, probably other stuff as well. 1) sounds horrible in terms of usability 2) you can't rely on x-props as you can't be sure they survive roundtrips to foreign providers. everybody found the basic idea interesting but the bottom line is that the *simple* conversion is not the way to go. i'm just repeating what was decided during the last meeting. wouldn't it be a bad idea to create tasks/events from their respective counterpart? this is what the discussion was heading towards. nobody wants to delay patches that improve usability significantly, but (as i already said) the 'simple conversion model' doesn't seem to be the right approach.
(In reply to comment #21) > exactly, the completion information would get lost, probably other stuff as > well. 1) sounds horrible in terms of usability 2) you can't rely on x-props as > you can't be sure they survive roundtrips to foreign providers. I'm not as convinced about (1) as you are. Clearly the two models aren't co-extensive, otherwise users wouldn't want to switch between them. The user's desire to convert signifies (a) They understand there is a difference in the model and (b) They want to exploit that difference to accomplish a goal. With regard to (2), that sounds entirely like a bug in the foreign provider. We've worked hard to make sure that we roundtrip everything sent to us (and have open bugs where we fail this goal). If another calendaring program fails to do that, we can advise our users to avoid that program, but we ought not hinder the usability of our own program simply because of bugs in other calendaring programs. In short, X-PROPS are a part of rfc2445, so we *should* be able to count on them.
(In reply to comment #22) > (b) They want to exploit that difference to accomplish a goal. The user has a problem: he wants to somehow store the date and time he is planning to work on the task. That's his problem. And we should allow a way of fixing that problem. I don't think that converting the task to an event is the solution (because the item is still a task) We should look for other ways to solve the user's problem.
Comment on attachment 231183 [details] [diff] [review] use cloneItemBaseInto r=lilmatt
Attachment #231183 - Flags: first-review?(lilmatt) → first-review+
Not wanting to hold users back while the above issues get sorted out, (I still don't understand why there's such strong opposition) I've released this code in an extension for now. You can find it for both Sunbird and Lightning at https://addons.mozilla.org/sunbird/3736/ Hopefully this bug will soon be fixed, rendering the extension obsolete.
Comment on attachment 231183 [details] [diff] [review] use cloneItemBaseInto I'm not at all convinced that this patch is the way to go. But I'm also not seeing any movement towards otehr solutions to the problem. r=mvl based on that. But we need some followup process.
Attachment #231183 - Flags: second-review?(mvl) → second-review+
patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061209 Calendar/0.4a1
Status: RESOLVED → VERIFIED
Whiteboard: [litmus testcase wanted]
Litmus testcase 2897 created
Whiteboard: [litmus testcase wanted]
There's no way to convert task <--> event in prototypes. Are you planning this feature?
Somehow yes, but not in the Event or Task dialog itself. Doing such in the Event/Task dialog itself, would cause the effect that too many ui-elements would change. I think the right place for switching task to events or vice versa are the calendar views itself. Depending on the properties set for a task the application could ask users how these should be converted. I'm thinking here on properties like Status, Due Date, Completeness.
You need to log in before you can comment on or make changes to this bug.