Repeat scheduled dates independently of due dates.

[FilSalustri]

As a professor, my life is divided into 13-week clusters of repeating tasks.

As a result, I often end up with tasks that I have to do, say, every week, but only for Fall semester.

One way to do this is how org-mode does it: having separate recurrence rules for scheduled dates and for due dates. I could in that way repeat a task every week between Sep and Dec by repeating the start and due dates every year but repeating the scheduled dates every week.

Dunno if that's possible within the current implementation, but I expect there are many other use cases where this could be beneficial.

[claremacrae]

Hi, thank you for the question.

Please could you give some concrete examples of what you are trying to achieve, preferably that doesn't require mugging on on org mode? Thanks in advance!

[FilSalustri]

I don't understand "mugging on on org mode" in this context, but whatever.

I mentioned one use case in my original post: a task that starts, say, 1 Sep, is due by, say, 22 Dec, and appears as "scheduled" for, say, every Tuesday and Thursday. Such tasks would involve certain activities to be done on Tuesdays and Thursdays, and that cumulatively complete by 22 Dec.

After the due date, I needn't worry about the task again till the following 1 Sep.

I could also implement this if I could limit recurrences by number or date, but I believe the doc explicitly says neither of those are possible.

I'm open to other ways to implement this with existing features.

[claremacrae]

Thank you. With that explanation, I think I understand what you're after.

With the current capabilities of Tasks, here's how I would do that:

• Task due on 1st September, every year, that says "set up the weekly tasks to do thing X on Tuesdays on Thursdays
• Task due every week on Tuesdays and Thursdays to do the thing X
• Task due on 22 December, every year, that says "remove last of the weekly tasks to do thing X on Tuesdays on Thursdays, to cancel the recurrence

(The last one is optional, if you would see the next task after the 22 Dec and cancel it)

[FilSalustri]

Sure, I could do that. But it would be friction-y. It would be more "natural" to be able to at least set the number of recurrences or the date of last recurrence.

I appreciate that this is all freeware and the devs are very busy. I'm just suggesting this might be a worthwhile addition to Tasks's functionality in time.

[claremacrae]

Of course, thank you for the suggestion.

[OogieM]

Looking at that it looks like for number 2 fixing that bug in rrule should cover most of my use cases.

There is a link to similar issue in the issues in rrule issue #486

with a possible work around I don't know enough to know if that might fix the issue in tasks as well.

[claremacrae]

Thank you for finding the rrule bug - I had searched before and not found it. As it was logged by the original author of the Tasks plugin, I'm sure it is the right one.

I'm a bit confused by your answer though, as I thought I was linking to an issue about setting the number of recurrences, not about choosing a fixed end date.

[OogieM]

I'm trying to come up with some alternatives that will work. My ideal is a set number of re-ocurrances but a fixed end date will work.

[claremacrae]

I realised yesterday that set number of occurrences is probably quite easy to code. Just decrease the remaining number with exact new copy.

[claremacrae]

Repeating for a set number of times is now logged in:

• Add support for recurrence rules containing 'for n times' #1729

[claremacrae]

As a professor, my life is divided into 13-week clusters of repeating tasks.

That should be covered quite easily in future by #1729, which is a request for a rather more mainstream, widely useful facility.

So I am going to close this in favour of #1729.

I'll mark this as 'not planned' rather than 'won't do' - meaning that if someone came up with an implementation which fitted Tasks well, and they discussed how it would work in advance, I would consider a PR but not actively support the work, due to the sheer quantity of other much more highly-requested and up-voted requests.