350174 - Task list doesn't support displaying and editing of occurrences of repeating tasks

Status: RESOLVED FIXED

(Calendar :: Tasks, defect)

Description

[Omar Bajraszewski]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060824 BonEcho/2.0b2
Build Identifier: 20060824 

task list is not updated after editing recurrent task

Reproducible: Always

Steps to Reproduce:
1.Make sure task list and task in view are set on. In task list you can see title and due date
2.Create a task that repeats every week (set date and due date)
3.Select the task on calendar view and click 'edit selected event' (btw it should be 'edit selected task')
4.Select 'this occurrence only'
5.Change date and due date
6.click ok

Actual Results:  
Task is updated in calendar view but NOT in task list. You can see old due date

Expected Results:  
Task is updated in task list and calendar view

No error in console

Comment 1

[Omar Bajraszewski]

Sorry-> I can see an error:
Error: window.startDate has no properties
Source File: chrome://calendar/content/calendar-recurrence-dialog.js
Line: 86

Comment 2

[Joey Minta]

Note that the task list doesn't yet display anything related to occurrences.

Comment 3

[Stefan Sitter [:ssitter]]

*** Bug 360356 has been marked as a duplicate of this bug. ***

Comment 4

[Damian Szczepanik]

what more in multiweek view edited task just disappeard, problem with refreshing (I think this has been reported somehow) but the main problem that task panel is not updated is still valid

Comment 5

[Benjamin Kraus]

This looks like duplicate (or subtask) of Bug 155889.

Comment 6

[Stefan Sitter [:ssitter]]

Updating summary because this is a general issue, see comment #2.

Comment 9

[Daniel Boelzle [:dbo]]

I think this generally falls into "how do we want to display infinitely recurring items in unbound lists". I can imagine we could
a) Avoid/don't offer unbound lists (e.g. remove "All Events" in unifinder, "All" tasks in task mode).
b) Dynamically expand the list while scrolling the output.

Comment 11

[jane.2494]

See https://bugzilla.mozilla.org/show_bug.cgi?id=373775#c29 for a possible resolution.

Comment 12

[Bas van den Bosch]

(In reply to comment #11)
> See https://bugzilla.mozilla.org/show_bug.cgi?id=373775#c29 for a possible
> resolution.

bug 272775 comment 29 says this bug should be resolved first. bug 438310 is related. 

I think for unbound tasklists (no start and end-date) only the masteritem should be shown. For date-bound taskslists the recurrences within the date-range should be shown. The today-pane has a tasklist which is by definition bound to a range.

Comment 13

[Matthew Mecca [:mmecca]]

I believe that if there is an unbound date range offered that shows only parent items, there should also be an additional UI cue that the item is repeating, perhaps also disabling the check box to prevent the user from inadvertently marking the entire series complete as in bug 373775.

It also makes sense to me to limit the unbound date ranges offered on the task view (i.e. replacing "All" with "All current tasks" to imply a date range), while offering a separate option to show "Repeating tasks" that would show the parent items only. This would help to ensure that that the parent of a repeating item, as opposed to the next occurrences, is really what the user expects to see in the list.

Comment 14

[Matthew Mecca [:mmecca]]

Attachment: [after beta] Proposed Patch for bug 350174 v1

Proposed Patch v1

1) Modifies the getItems function in calMemoryCalendar.js to allow returning of expanded occurrence sets of repeating tasks when the start date is not specified. Only the end date of a date range is necessary to determine a finite occurrence set, as the start date can be determined by the DTSTART property of the parent item.
2) Adds a new style for non-expanded parent items of repeating tasks, to distinguish between parent items and occurrences. This style will only appear in non-datebound lists. Repeating tasks are shown with blue text, as well as a "greyed out" check box to prevent inadvertantly marking the entire series as complete.
3) Disables toggling of completed status via clicking the check box for repeating parent items to resolve bug 373775.
4) Creates a new non-datebound filter option "Repeating Tasks" to show only parent items of repeating tasks .
5) Creates a new date-bound filter option "Current" to show expanded occurrences of all tasks through the selected date of the current view (the current date by default). 
6) Modifies the other filter options besides "All" and "Repeating Tasks" show expanded occurrences of all tasks through the selected date of the current view.
7) Reorders the filter options to show "Current Tasks" as the default first option, as occurrences of repeating tasks are most likely what the user expects to see by default. The non-datebound "All" tasks option moved to the bottom of the list.
8) Sets the date filter of the task list in the today pane to show expanded occurrences of tasks through the current date.

Comment 15

[Matthew Mecca [:mmecca]]

Attachment: Screen Shot 1 for UI review

Comment 16

[Matthew Mecca [:mmecca]]

Attachment: Screen Shot 2 for UI review

Comment 17

[Matthew Mecca [:mmecca]]

Attachment: Screen Shot 3 for UI review

Comment 18

[Matthew Mecca [:mmecca]]

Attachment: Screen Shot 4 for UI review

Comment 19

[jane.2494]

Cool!!

Comment 20

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 386860 [details] [diff] [review]
[after beta] Proposed Patch for bug 350174 v1

First of all, thanks for the patch! Recurring tasks is an area we definitely need to improve.

I'll need some time to look into this, but I've noticed there are some hardcoded strings. These need to be converted to locale strings in property or dtd files. Since we are in string freeze for the beta, I'll review this after the beta.

Comment 22

[Matthew Mecca [:mmecca]]

Attachment: [after beta] Proposed Patch v2

1) Fixes l10n strings
2) Updates the date filters for the corresponding task list controls when a new date is selected (ie. selecting a date in the future will show expanded occurrences of tasks starting on or before that date). In the Task View the date range is updated from the minimonth (only if _not_ defined explicitly in the selected filter, as in "All", "Today", "Next Seven Days"). In the Today Pane the getInitialDate extended binding is used to update the date range to the currently selected date in the today pane. In Sunbird the date range is determined by the date selected in the current view.

Comment 23

[Thomas Edwards]

Nice one!
How do I apply this patch?

Comment 25

[Thomas Edwards]

Would someone please be able to help me apply this patch? I've looked around the net for how to apply patches but I still can't figure out what to do. What p level do I use? Where do I apply this patch?
This fix would be the one thing that will get me using the task list in thunderbird, which is otherwise awesome for organising things.

Comment 26

[Matthew Mecca [:mmecca]]

Attachment: [long,l10n,theme] Proposed Patch v3

Fixes issue with currently started tasks not appearing in the task view if a previous date was selected. Sets the end date for the current filters to the later of the selected date in the view or the current date.

Comment 27

[Chuck Clayton]

One possible behavior would be to just show the "most recent" non-completed task.   Or you may have an option to display multiple non-completed recurring tasks.  

One way to do this would be to spawn a new task, identical to the parent task with the exeption of the due date.  The new task would be spawned when the current task is marked as complete.

So, It's 1/1/09 and I want to create a task that due due on the 15th of each month.  I create a new task, set the due date to 1/15/09, the start date could be set the same as the 'initial' due date.  I set the recurrence to "monthly" and set the reminder to 5 minutes, or whatever.

On 1/15/09, I am reminded to do my task.  But, I'm lazy so I hit the snooze button a few times.  Finally, I do my task, dismiss the reminder and mark the recurring task complete.

When I check the "complete" box, it is struck-though as completed and a "new task" is created that is identical to the task I just completed but the due date of the new task is 2/15/09, also with a reminder.

I think this behavior ideal since althoug seeing multiple incomplete tasks may be a bonus in some cases.

Any idea when the new functionality will be available or if it is avaialable, how do I install it?  I'm moving over from outlook and not having working recurring tasks is a deal breaker for me.  I hate to say that since I love all the other features.

Comment 28

[WTarrasque]

As others have said: the ineffectiveness of repeating tasks is a major gamebreaker in the functionality of Sunbird or Lightning as compared to Outlook.

As far as I can tell, this bug and those it "blocks" bug 373775 , bug 438310 , and bug 500114 , have not been worked on in several months. I do not know what the proposed patch about does, but if it helps make repeating tasks more functional, what is delaying it's integration into a Thunderbird build? And if it will not be, is there a standalone patch or addon that helps the functionality of tasks in Thunderbird?

Comment 29

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 404433 [details] [diff] [review]
[long,l10n,theme] Proposed Patch v3

> function minimonthPick(aNewDate) {
>-  if (isSunbird() || gCurrentMode == "calendar") {
>+  if (isSunbird() || gCurrentMode == "calendar" || gCurrentMode == "task") {
Go ahead and use cal.isSunbird() instead, here and elsewhere.


>+              // prevent toggling completed status for parent items of repeating tasks
>+              if (!task || task.recurrenceInfo)
>                   return;
While you're here, please add {}, even for one-line if's

>           onAddItem: function tTO_onAddItem(aItem) {
...
>+                  let occs;
>+                  if (this.binding.mFilter.endDate) {
>+                      occs = aItem.getOccurrencesBetween(this.binding.mFilter.startDate,
>+                                                         this.binding.mFilter.endDate,
>+                                                         {});
Lets be more robust here and also check if the start date isn't null.


>+                  }
>+                  for each (let occ in occs) {
>+                      this.binding.mTreeView.removeItem(occ);
>+                  }
If you like:
  occs.forEach(this.binding.mTreeView.removeItem, this.binding.mTreeView);

> 
>-                  if (savedThis.mFilter.startDate && savedThis.mFilter.endDate) {
>+                  if (savedThis.mFilter.endDate) {
>                       filter |= aCalendar.ITEM_FILTER_CLASS_OCCURRENCES;
>                   }
Same comment as before, this time I have the feeling you did it for a reason :-) Why only check for end date here? Can't we be more robust and also check for the start date?


>+                let oneDay = createDuration();
Please prefix everything you use from calUtils.js with "cal.", we are transitioning to the use of the calUtils.jsm module. If you get an error that it is not defined, add

Components.utils.import("resource://calendar/modules/calUtils.jsm");

in the constructor.



>+    // add listener to update the date filters
>+    getViewDeck().addEventListener("dayselect", updateCalendarToDoUnifinder, false);
>+    
> function getDatesForFilter(aFilter) {
>-    var EndDate = createDateTime();
>-    var StartDate = createDateTime();
>-    var Duration = createDuration();
>+    var endDate = createDateTime();
>+    var startDate = createDateTime();
>+    var duration = createDuration();
>     var oneDay = createDuration();
Go ahead and change all var's to let's in this function.

>+.calendar-task-tree > treechildren::-moz-tree-cell-text(repeating) {
>+    color: blue;
>+}
The css style rules seem the same between windows and mac. Please put the rules in the respective files in base/themes/common. If there is no file for the task tree, then go ahead and create one, including it via @import (similar to how the other common files are included)



>             if (itemReturnOccurrences && item.recurrenceInfo) {
>+                let startDate  = aRangeStart;
>+                if (!aRangeStart && isToDo(item))
>+                    startDate = item.entryDate;
Please use {} for this if statement. If you like, please also change var to let.

The code looks fine, r- just to get a new patch with nits fixed. Waiting for ui-review now, I'll be testing it in the meanwhile.

Comment 30

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Proposed Patch v3 - debitrottee

For testing I needed to make the patch apply, so here is the debitrotted patch. I did notice some issues with the patch though. For me, changing the task filter doesn't change the displayed tasks at all. STR:


* Apply patch, start Lightning, go to task view
* Create a few tasks with the quick add feature
* Switch through the filters

Result:

* All tasks are shown, regardless of what filter is chosen.

Comment 31

[Philipp Kewisch [:Fallen][📱📆]]

>+    // add listener to update the date filters
>+    getViewDeck().addEventListener("dayselect", updateCalendarToDoUnifinder, false);

If you add the listener here, you need to remove it somewhere too. I believe we have a finish function for the unifinder too.

Comment 32

[Matthew Mecca [:mmecca]]

> I did notice some issues with the patch though. For me, changing the task
> filter doesn't change the displayed tasks at all. STR:
> 
> 
> * Apply patch, start Lightning, go to task view
> * Create a few tasks with the quick add feature
> * Switch through the filters
> 
> Result:
> 
> * All tasks are shown, regardless of what filter is chosen.

I'm not able to reproduce this - for me the old filters work the same way as without the patch applied until some tasks are set as repeating (which is how its supposed to work). Can you provide more details of which filter is selected and which tasks are still showing when they shouldn't? Do you show any errors?


> >           onAddItem: function tTO_onAddItem(aItem) {
> ...
> >+                  let occs;
> >+                  if (this.binding.mFilter.endDate) {
> >+                      occs = aItem.getOccurrencesBetween(this.binding.mFilter.startDate,
> >+                                                         this.binding.mFilter.endDate,
> >+                                                         {});
> Lets be more robust here and also check if the start date isn't null.
 
> >-                  if (savedThis.mFilter.startDate && savedThis.mFilter.endDate) {
> >+                  if (savedThis.mFilter.endDate) {
> >                       filter |= aCalendar.ITEM_FILTER_CLASS_OCCURRENCES;
> >                   }
> Same comment as before, this time I have the feeling you did it for a reason
> :-) Why only check for end date here? Can't we be more robust and also check
> for the start date?

In both cases the startDate is now made optional for expanding occurrences by this:

> >             if (itemReturnOccurrences && item.recurrenceInfo) {
> >+                let startDate  = aRangeStart;
> >+                if (!aRangeStart && isToDo(item))
> >+                    startDate = item.entryDate;

If the startDate is set it is used, and if it isn't the start date of the each parent task is used. The check remains for the endDate, if it is not provided then occurrences are not expanded. This allows for for filters like "show occurrences for all repeating tasks through 3/2/2010", and is the basis for allowing expansion of a finite occurrence set based on the date selected in the view or today pane. I added the isToDo() check to avoid inadvertently breaking any other code that relies on the old expansion requirements.

Comment 33

[Matthew Mecca [:mmecca]]

Attachment: Proposed Patch v4

Patch with requested fixes

Comment 34

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 429933 [details] [diff] [review]
Proposed Patch v4

Seems my task filter problem was just a temporary one, but definitely not related to this bug. I can't reproduce it anymore now.

One more issue, sorry I didn't notice this earlier:
>+.calendar-task-tree > treechildren::-moz-tree-cell-text(repeating) {
>+    color: blue;
>+}
>+
>+.calendar-task-tree > treechildren::-moz-tree-row(repeating, selected, focus) {
>+    background-color: blue;
>+}
>+
>+.calendar-task-tree > treechildren::-moz-tree-cell-text(repeating, selected, focus) {
>+    color: HighlightText;
>+}
Using color/background-color: blue here might cause problems with native theming, i.e if the HighlightText color is a blue  tone for the operating system. I think we should just keep repeating tasks colored normally. Would this be ok with you?


r=philipp, waiting for ui-review now.

Comment 35

[Matthew Mecca [:mmecca]]

(In reply to comment #34)
> Using color/background-color: blue here might cause problems with native
> theming, i.e if the HighlightText color is a blue  tone for the operating
> system. I think we should just keep repeating tasks colored normally. Would
> this be ok with you?

I think we need something to visually distinguish a parent repeating task from an expanded one. Maybe another color besides blue?

Comment 36

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to comment #35)
> I think we need something to visually distinguish a parent repeating task from
> an expanded one. Maybe another color besides blue?

I'm not sure I agree. The average user just thinks in terms of tasks. He knows the tasks are repeating, but he might not understand the technical detail that these tasks are stored totally different.

What value can the user gain from knowing that the tasks are expanded?

Comment 37

[Benjamin Kraus]

(In reply to comment #36)
> (In reply to comment #35)
> > I think we need something to visually distinguish a parent repeating task from
> > an expanded one. Maybe another color besides blue?
> 
> I'm not sure I agree. The average user just thinks in terms of tasks. He knows
> the tasks are repeating, but he might not understand the technical detail that
> these tasks are stored totally different.
> 
> What value can the user gain from knowing that the tasks are expanded?

I don't think it is as important to distinguish expanded repeating tasks from regular non-repeating tasks, but it *is* important to distinguish a parent repeating task from any other task (expanded repeating or non-repeating) simply to avoid accidentally marking every occurrence of the repeating task as complete, or accidentally deleting *every* occurrence when you intend to delete only one.

I admit I haven't look in detail at the proposed patch, but if it hasn't been done in the proposed patch, perhaps the check box on the parent task should be disabled, or a warning dialog should be shown when marking a parent task as complete or deleting a parent task? (That would help with Bug 373775 and Bug 438310 as well.)

An alternative to different colors is an icon next to the text of the task that indicates "parent repeating", "expanded repeating", or "regular task".

Comment 38

[Matthew Mecca [:mmecca]]

(In reply to comment #36)
> What value can the user gain from knowing that the tasks are expanded?

(In reply to comment #37)
> I don't think it is as important to distinguish expanded repeating tasks from
> regular non-repeating tasks, but it *is* important to distinguish a parent
> repeating task from any other task (expanded repeating or non-repeating)

Right, the idea was to distinguish just the parent (non-expanded repeating) tasks from a single occurrence, in the few cases where the parents are shown, since a modification there would affect the whole series. We would be showing the user that the task was *not* expanded to reinforce that. The expanded occurrences wouldn't need to be distinguished because they would behave like any other non-repeating task.

> perhaps the check box on the parent task should be disabled

This patch does already disable the check box for parent tasks to avoid inadvertently marking the whole series as complete (as in Bug #373775), and the check box is shown as grayed out, but I think the additional distinguishing feature for parent tasks would help to show why it is being disabled.

Comment 39

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #38)
> Right, the idea was to distinguish just the parent (non-expanded repeating)
> tasks from a single occurrence, in the few cases where the parents are shown,
> since a modification there would affect the whole series.

In the normal event view, there is no indication if an event is expanded or not. I don't even know what that exactly means.
I think the task list should behave in the same way as the event view: just show the occurrences of the task, and when editing a task that recurs, ask if the user want to edit the whole series, or just this one instance.

Comment 40

[Benjamin Kraus]

(In reply to comment #39)
> In the normal event view, there is no indication if an event is expanded or
> not. I don't even know what that exactly means.

The patch being discussed is supposed to fix the fact that (among other things) there currently is no indication if an event is expanded or not (which is why you don't see it in release versions yet).

> I think the task list should behave in the same way as the event view: just
> show the occurrences of the task, and when editing a task that recurs, ask if
> the user want to edit the whole series, or just this one instance.

This is along the lines of what the proposed patch is trying to do. However, this doesn't work in all situations. If you look at "Screen Shot 3 for UI review" (link at the top of the page), you will notice that "Next Seven Days" is selected, and the list shows many instance of the both "Feed the dog" and "Walk the dog". This is the behavior you are requesting, and the expected behavior. Now imagine if you picked "All" instead of "Next Seven Days", you would have an infinitely long list, which is impossible to display. Instead of picking an arbitrary number of repetitions to show (you can have endless debate about how to pick the correct number of items to show) the proposed patch chooses to show one "parent task" for "Feed the dog" and another "parent task" for "Walk the dog". You can see this in "Screen Shot 2 for UI review".

This problem doesn't come up with the event view (except the event finder) because you are always looking at a bounded time-range (month, week, day, etc).

Comment 41

[Christopher Bratchell]

What is important to the ordinary user is to know one can rely on task reminders and have a simple interface to mark completed or dismiss an occurrence of the task.  It should not be possible by clicking one of two equally prominent options to inadvertently edit the parent.  Editing of the parent should require a different operation explicitly opening the task to edit it, and simply marking an occurrence as completed should not ever give any options to change the repeat frequency or other aspects of the task.  Showing all occurrences is not usually helpful to the ordinary user.  There should be a warning or other defined action if an occurrence is marked as complete before earlier occurrences of the same task.

Comment 42

[WTarrasque]

(In reply to comment #41)
> What is important to the ordinary user is to know one can rely on task
> reminders and have a simple interface to mark completed or dismiss an
> occurrence of the task.  It should not be possible by clicking one of two
> equally prominent options to inadvertently edit the parent.

I believe this is the essence of the bug. A Task list is meant to be checked off when the task is done. A repeated task is done many times. This means every time the task would be checked, there should be another to takes its place.

Checking off the task should be quick and easy. Editing the repetition could be more difficult, but that is completely acceptable. In my personal experience, preparing an organizational system one expects to spend more time. When completing the task however, its gotta be a quick "check."

Comment 43

[Benjamin Kraus]

(In reply to comment #41)
> It should not be possible by clicking one of two equally prominent options to
> inadvertently edit the parent.

Just to make sure I understand, are you suggesting that there shouldn't be an "All" filter (so that all choices are bounded lists, removing the problem of infinite lists)? I understand that perspective, but I also could imagine someone wanting to be able to list all the tasks in a calendar in a concise way. Perhaps there should be an option (set by default?) to remove the "All" filter, to simply things in the default case, but without removing that functionality for those who want it.

(In reply to comment #42)
> Checking off the task should be quick and easy. Editing the repetition could be
> more difficult, but that is completely acceptable. In my personal experience,
> preparing an organizational system one expects to spend more time. When
> completing the task however, its gotta be a quick "check."

I think we can all agree that the situation before this patch isn't ideal, and the patch looks (to me) like it makes a pretty big step in the right direction. Thank you Matthew Mecca for your work on this patch, it is very much appreciated. Matthew and Philipp, is there anything that can be done to help this patch make it into Lightening before 1.0 is released?

Comment 44

[Christopher Bratchell]

Not suggesting removing "All" filter but do not think parents should be displayed in this list, if I understand the functionality correctly it is too easy to set completion on the parent. Either a separate "List Parents" or a very clear warning that a parent is being modified with default to not edit the parent. But of course all this is a great improvement on current situation.

Comment 45

[Matthew Mecca [:mmecca]]

With the current proposed patch, instances of repeating tasks will appear and behave the same as normal tasks, except in 2 special cases - the "Repeating Tasks" filter and the "All" filter - in which the single "parent task" is shown (with a disabled check box to prevent marking the whole series complete). 

This is similar to how repeating events are currently handled, where the only equivalent to the "All" task filter (which is not bound to any specific time period) is in the Event finder with "All Events" selected, in which case only the "parent" event is shown for repeating events (see Bug #299651). 

I think it makes sense in these cases to show only a single parent rather than filling the list with occurrences (that could be infinite in number and would need to be expanded dynamically as the list was scrolled), as it would make it difficult to find other single items. However, the parent events in the "All Events" case don't have any special color or formatting, which could cause some confusion as it appears that only a single non-repeating event is being shown. It's outside the scope of this bug, but I think it might be useful there as well as with the task lists to use a distinct text color or other formatting to signify that a single entry is representing a larger set of repeating occurrences.

On the other hand, this issue could be resolved for the task list by removing the non-date-bound filters. Since the current proposed patch also allows the task list to be filtered based on any selected date, the "All" filter could be removed, and the "Repeating Tasks" filter could be removed as well. This would eliminate the need to show parent tasks at all, but personally I think that both of these are useful features if you work with a lot of repeating tasks.

My suggestion would be to take the current patch, either as-is or with the blue-text formatting part removed (keeping the handling of repeating tasks and events consistent), and file a follow-up bug to discuss possible formatting changes for both repeating tasks and events in the special cases where only a single parent entry is shown, or whether these single parent items should be shown at all.

Comment 46

[Bas van den Bosch]

+1 for Matthew's suggestion. Let's take this and file follow-ups for outstanding issues, perhaps take the suggestion in comment 34. A fix has been lying around for quite a long time and this is a long requested feature. From here we can see what has to be done in the dependant bugs.

Comment 47

[Matthew Mecca [:mmecca]]

Attachment: [needs ui-r] Repeating tasks v5 - no blue text / "Repeating" filter

Removes blue text for parent items. Also removes "Repeating" filter for now until the parent item formatting issues are addressed in a followup bug.

Comment 48

[Matthew Mecca [:mmecca]]

Attachment: Screenshots - Repeating tasks v5

Two screen shots showing repeating tasks - top screen shot shows "Current Tasks" filter applied, with expanded occurrences; bottom screen shot shows "All" filter applied, with single parent items shown for repeating tasks, with disabled check boxes.

Comment 49

[jane.2494]

Thank you to those developers who took the time to work on this issue.  We very much appreciate it.

Thank you.

Comment 50

[David O'Leary]

This doesn't appear to be assigned to a milestone yet. What do we need to do to get this released?

Comment 51

[Philipp Kewisch [:Fallen][📱📆]]

Andreas, Bryan, could one of you take care of this ui-review? I'd like to get this bug off my radar :-)

Comment 52

[Andreas Nilsson (:andreasn)]

Taking this on

Comment 53

[Andreas Nilsson (:andreasn)]

I finally understood this now :)
My only worry with this is that Lightning is lying if I select Show all. If I've created a task that happens on a Friday, make it happen every week and move the first one to Saturday, I get the impression it still happens on Friday, even though there is nothing happening on Friday.

Comment 54

[Matthew Mecca [:mmecca]]

(In reply to comment #53)
> If I've created a task that happens on a Friday, make it happen every week and
> move the first one to Saturday, I get the impression it still happens on
> Friday, even though there is nothing happening on Friday.

One solution to this could be to show something like "repeating" or "multiple occurrences" in place of the date fields on repeating tasks when the All filter is selected - what do you think Andreas?

Comment 55

[Matthew Mecca [:mmecca]]

Attachment: [needs ui-r] Repeating tasks v6 - Show dates as "(Repeating)" in All filter

Shows "(Repeating)" in place of the start, due, and completed dates for parent tasks in the All filter.

Comment 56

[Matthew Mecca [:mmecca]]

Attachment: Screenshots - Repeating tasks v6

Screen shots for patch v6. Top shows the "Current Tasks" filter applied, bottom shows the "All" filter applied. The repeating tasks in the All filter show "(Repeating)" in place of the date fields to show that the entry represents a series of occurrences, some of which may have modified.

Comment 57

[Andreas Nilsson (:andreasn)]

Comment on attachment 474315 [details] [diff] [review]
[needs ui-r] Repeating tasks v6 - Show dates as "(Repeating)" in All filter

If I go to the menu View > Tasks, I get a slightly different task list that lists "All" on the top and lacks "Current tasks". ui-r minus because of that.

Comment 58

[Matthew Mecca [:mmecca]]

Attachment: Repeating tasks v7 - Fixes Tasks menu

Comment 59

[Andreas Nilsson (:andreasn)]

Comment on attachment 475720 [details] [diff] [review]
Repeating tasks v7 - Fixes Tasks menu

This seems to have bitrotted a bit, but apart from that this feels like it fixes the bug.

Comment 60

[Andreas Nilsson (:andreasn)]

Comment on attachment 474317 [details]
Screenshots - Repeating tasks v6

Minus on this, as it's just a screenshot of a previous version of the patch I just approved.

Comment 61

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 475720 [details] [diff] [review]
Repeating tasks v7 - Fixes Tasks menu

Ok, lets do this! Patch looks great, r=philipp.

Comment 62

[Philipp Kewisch [:Fallen][📱📆]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/200dcbfaafff>
-> FIXED

Comment 63

[Rimas Kudelis [use needinfo to ping]]

Sorry, I don't quite get how to localize "Current tasks". Could anyone please explain in detail what it is and what it's not, and how it differs from All tasks?

Thanks!

Comment 64

[Matthew Mecca [:mmecca]]

"Current Tasks" will show all tasks except those with a Start date set that is after today and after the selected date. If a task repeats, a separate entry will be shown for each of the occurrences that happen on or before today (or the selected date, whichever is later).

"All Task" will show all tasks regardless of their start date. Tasks that repeat will show only one entry with "(Repeating)" indicated instead of the start/due dates.

Comment 65

[Rimas Kudelis [use needinfo to ping]]

Thanks Matthew! You may want to add an l10n comment about it to the dtd file.

Comment 66

[Philipp Kewisch [:Fallen][📱📆]]

Added the localization note in comm-central changeset f4a93ad5efb5

Comment 67

[Rimas Kudelis [use needinfo to ping]]

Thanks Philipp!

Comment 68

[Philipp Kewisch [:Fallen][📱📆]]

Backported to comm-1.9.2 <http://hg.mozilla.org/releases/comm-1.9.2/rev/1c13079ddb3c>

a=philipp

Comment 69

[Ilja Sekler]

The checkin <http://hg.mozilla.org/releases/comm-1.9.2/rev/1c13079ddb3c> has broken the filter for incomplete tasks in the tasklist and in the Today Pane. No incomplete tasks are shown anymore when using this filter or unchecking "Show completed Tasks" in the Today Pane. Verified by a complete local backout of the patch.

At least for the Today Pane, reverting 

+    // update the filter
     tree.showCompleted = showCompleted;
-    tree.refresh();
+    tree.updateFilter();

in calendar/base/content/calendar-unifinder-todo.js makes the incomplete tasks appear again. 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14pre) Gecko/20101205 Lightning/1.0b3pre Thunderbird/3.1.8pre

SourceStamp=4043214c5eb4

Comment 70

[Matthew Mecca [:mmecca]]

(In reply to comment #69)
> The checkin <http://hg.mozilla.org/releases/comm-1.9.2/rev/1c13079ddb3c> has
> broken the filter for incomplete tasks in the tasklist and in the Today Pane.
> No incomplete tasks are shown anymore when using this filter or unchecking
> "Show completed Tasks" in the Today Pane.

This is working for me. 

Do the tasks that are missing for you have a start date set in the future? This patch binds the task list in the Today Pane to the currently selected date in the Today Pane, so tasks with a Start date set after that will not show up, regardless of the completed status. Tasks starting on or before the selected date, or without a Start date set, should show up. Moving the date forward in the Today Pane should allow looking ahead to tasks starting on future dates.

Comment 71

[Ilja Sekler]

(In reply to comment #70)

> Do the tasks that are missing for you have a start date set in the future?

No, the start date is not set.

> This patch binds the task list in the Today Pane to the currently
> selected date in the Today Pane, so tasks with a Start date set
> after that will not show up, regardless of the completed status.

Oh, I see.

> Tasks starting on or before the selected date, or without a Start
> date set, should show up.

The former show up, the latter do not - this is the issue.

> Moving the date forward in the Today Pane should allow looking
> ahead to tasks starting on future dates.

Yes, it does.

Comment 72

[Matthew Mecca [:mmecca]]

(In reply to comment #71)

> > Tasks starting on or before the selected date, or without a Start
> > date set, should show up.
> 
> The former show up, the latter do not - this is the issue.

I'm not able to reproduce this - for me the incomplete tasks without a start date are showing up, and the completed tasks without start dates are obeying the "Show completed Tasks" setting.

Can you reproduce this with a new profile? If so, would you create a new calendar & task that shows this behavior, export and post the file contents?

Comment 73

[Matthew Mecca [:mmecca]]

And also if you see anything in the Error Console.

Comment 74

[Ilja Sekler]

Attachment: A calendar with a single incomplete task

(In reply to comment #72)

> (In reply to comment #71)
> 
>>> Tasks starting on or before the selected date, or without a Start
>>> date set, should show up.
>> 
>> The former show up, the latter do not - this is the issue.
> 
> I'm not able to reproduce this - for me the incomplete tasks without a start
> date are showing up, and the completed tasks without start dates are obeying
> the "Show completed Tasks" setting.

Just to be sure: is it the comm-1.9.2 branch you are testing? I speak only about the branch, not the trunk.

> Can you reproduce this with a new profile?

Yes. And no errors/warnings/whatsoever in the EC.

A calendar with a single incomplete task with 2010-12-10 as due date and no start date attached. This task doesn't show up in the filter for incomplete tasks in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14pre) Gecko/20101205 Lightning/1.0b3pre Thunderbird/3.1.8pre with a clean new profile if due date and time is more than 24h ahead of the selected date in the minimonth.

Comment 75

[Matthew Mecca [:mmecca]]

(In reply to comment #74)
> Just to be sure: is it the comm-1.9.2 branch you are testing? I speak only
> about the branch, not the trunk.

Yes, I'm testing on comm-1.9.2 also.

> This task doesn't show up in the filter for incomplete
> tasks in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14pre) Gecko/20101205
> Lightning/1.0b3pre Thunderbird/3.1.8pre with a clean new profile if due date
> and time is more than 24h ahead of the selected date in the minimonth.

I see what you mean now, the task with no Start Date and a Due date of 12/10 does not show up if a date earlier than 12/10 is selected in the today pane. This is happening because the task is not matching the date filter, but I think this is the intended behavior. 

From http://tools.ietf.org/html/rfc5545#section-3.6.2
"A "VTODO" calendar component without the "DTSTART" and "DUE" (or "DURATION") properties specifies a to-do that will be associated with each successive calendar date, until it is completed."

So, a task with no Start date AND no Due Date will always match the date filter. However, if a Due date is specified without a Start date, the Due date is used in place of the Start Date to determine if the task matches the given date range.

In this test case, if today's date 12/6 is selected, the filter looks for task occurrences through 12/6, but the test case task is associated with 12/10, so it doesn't match the date filter and isn't shown.

This behavior existed before this patch, but is more obvious now that today pane is bound to a date range. IMHO if we want to reevaluate this we should do so in a different bug.

A workaround would be to always set a Start date as the date you want the task to show up in the list whenever a Due date is set.

Comment 76

[Stefan Sitter [:ssitter]]

Ilja, Matthew maybe you should file a new bug to discuss the new problem?

Comment 77

[Ilja Sekler]

(In reply to comment #76)
> Ilja, Matthew maybe you should file a new bug to discuss the new problem?

Filed Bug 617277.