Closed EngelPika32 closed 1 year ago
Originally waiting a few days to see, if the repeat tasks trigger… but no luck.
Hence, I just took a look at my config & backups (as I really need my scheduled & repeatTasks working) and noticed the lastTaskCreation
field, which proves as well, that there are no new instances created.
Anyway, here are two examples from the backups (entities of taskRepeatCfg
):
# pre 7.10.1 (was 7.8.x iirc)
# "__modelVersion": 1.3
# backup from last Friday; Jan 28
"PcnZq5y4w": {
"lastTaskCreation": 1643303738475,
"title": "===DO_STUFF===",
"defaultEstimate": 1800000,
"projectId": "FYAE7fbwU",
"monday": true,
"tuesday": true,
"wednesday": false,
"thursday": true,
"friday": false,
"saturday": true,
"sunday": false,
"tagIds": [],
"order": 0,
"id": "PcnZq5y4w"
},
"WPUZtmywd": {
"lastTaskCreation": 1643122489482,
"title": "===OTHER_STUFF===",
"defaultEstimate": 1800000,
"projectId": "AcLII2VXn",
"startTime": "9:00",
"remindAt": "AtStart",
"monday": false,
"tuesday": true,
"wednesday": false,
"thursday": false,
"friday": false,
"saturday": false,
"sunday": false,
"tagIds": [
"TODAY",
"qpVUXPYSIb"
],
"order": 0,
"id": "WPUZtmywd"
}
# after update to 7.10.1
# "__modelVersion": 1.41
# backup of today; Feb 04
"PcnZq5y4w": {
"lastTaskCreation": 1643303738475,
"title": "===DO_STUFF===",
"defaultEstimate": 1800000,
"projectId": "FYAE7fbwU",
"startDate": "2022-01-31",
"repeatEvery": 1,
"isPaused": false,
"quickSetting": "CUSTOM",
"repeatCycle": "WEEKLY",
"monday": true,
"tuesday": true,
"wednesday": false,
"thursday": true,
"friday": false,
"saturday": true,
"sunday": false,
"tagIds": [],
"order": 0,
"id": "PcnZq5y4w"
},
"WPUZtmywd": {
"lastTaskCreation": 1643122489482,
"title": "===OTHER_STUFF===",
"defaultEstimate": 1800000,
"projectId": "AcLII2VXn",
"startTime": "9:00",
"startDate": "2022-01-31",
"repeatEvery": 1,
"remindAt": "AtStart",
"isPaused": false,
"quickSetting": "CUSTOM",
"repeatCycle": "WEEKLY",
"monday": false,
"tuesday": true,
"wednesday": false,
"thursday": false,
"friday": false,
"saturday": false,
"sunday": false,
"tagIds": [
"TODAY",
"qpVUXPYSIb"
],
"order": 0,
"id": "WPUZtmywd"
}
I hope, this helps resolve this issue. (Though, it probably lays somewhere else?).
Hey there! Thanks for opening this up! This is an intentional design decision, as you might end up with a lot of tasks if you haven't started the app in a while. I can see why one might want this to be otherwise and I am open for adding this optionally (opt-in) as feature (but I won't work on this myself).
Hey, thanks for the response. This decision is unfortunately a huge deal-breaker for me. I need the repeated tasks to show up. And I don't think it currently works as intended. I've used SP nearly daily over the past week and none of my repeated tasks got a new instance!! Like they are frozen in time.
This is an intentional design decision,
Sorry, that I couldn't find this change in the changelog, as I wouldn't have updated SP if I'd known about this decision… And if this was the intentional behavior all the time, then I probably relied on a [unknown] bug :/
as you might end up with a lot of tasks if you haven't started the app in a while.
It's very simple. If the due date lies in the past, then create a new instance, but only one. That way, I didn't have to care about duplicates over Christmas-NewYear. The due date was ~2 weeks in the past, but only one new instance was created.
And even if multiple instances are created, I can delete them. I'd rather have a hundred instances of the same task than forgetting a task.
To wrap things up a bit, here is a use case/example (why you should overthink your design decision): Monthly and even yearly tasks are now available. However, if a monthly task is always created on, let us say the 1st, but the next 1st is a Sunday (and you don't open SP Sundays), what should happen?? A: Task is created the next time you open SP (presumably Monday) B: SP wasn't active during the scheduled time; hence the task wasn't created and won't be afterward [design decision you mentioned]
Now, to extend this further. If you (for some reason) don't open SP for another month. What do you want? A1: Two tasks being created the next time you open SP, as you missed it two times now A2: One task being created the next time you open SP (because we only check, if the scheduled time lays in the past, but not how often/how far). B1: SP wasn't active during the scheduled time; hence the task wasn't created and won't be afterward B2: Your lucky day, the second 1st is a Monday and you opened SP. One task is being created :)
So, I ask you: How should SP behave? Which design decision should be made!?
To add some more examples:
This can be transferred directly to weekly tasks as well.
Having the task Read a book 45m +health #today #c
scheduled for every Saturday – aka. 'weekend'. It doesn't matter if I do that on Saturday or Sunday. But if I don't open SP on Saturday, we'll have the same scenario as above^.
And I do actually have a rather important task, which I've to do once a week. Though, it's not important when I do them each week. I just do them as they fit in. And if I'm off on the day I scheduled it, then I still have to do it the day after. – Same goes if the day I scheduled it is a public holiday. And there are actually quite a few holidays in the year which can extend the weekend.
Thank you very much for your honest feedback. I have to think about it.
Hey there,
any updates on your side? I mean, it's been a whole month and you wanted to think about it.
I've recently created some additional tests to src/app/features/task-repeat-cfg/store/task-repeat-cfg.reducer.spec.ts which clearly show how easy it is to forget your regular tasks with SP.
Anything except daily (which has its own issues #1915 ) doesn't work at all if SP isn't opened on the exact scheduled day.
Monthly and yearly tasks are practically unusable as the chance of hitting a non-work day is relatively high.
(Though, this year February-March is pretty lucky by having the exact same weekdays. Good for writing tests as well.)
Looking back at the original feature request (resulting in the issues mentioned above) #948 – where was the (user-)testing?? But I guess it was really your [unmentioned] design decision then. Which is fine, your app after all… And what was the concept/spec? lastTaskCreation doesn't seem to be used at all (and I can't see any way of implementing above correctly without it).
After taking my time to look into this whole issue I'm truly wondering: How? Why? …
Anyway, will open a PR with the tests when I get time (no promises on my end, though).
dot.
There is a LOT on my plate (not to mention that a war in Europe broke out, which didn't leave me unaffected). I am not sure if you're aware of this, but there are many issues raised every week and working on this project is not my main job.
This is a complicated subject on many different levels and not something I can quickly skim and then provide some input. I scheduled this for the next time I have a couple of days off, which will be in April (no promises made, since I might also want to have some real vacation). To be honest: For my personal needs the repeating tasks are working very well, but I can see why this might not be the case for everyone and given you spent a considerable amount of time on providing input on this subject (for which I am honestly grateful), I want to do this justice rather than to provide some half backed rushed and possibly slightly annoyed feedback.
Just coming because this issue also interests me a lot (eg. for my "check bank report" monthly recurring task), but I also think it's important to be mindful of what an open-source maintainer's role is.
@EngelPika32 I agree with you that I also would really like this to happen. Right now I have a task "check recurring task list to verify nothing slipped through during the week-end", and I'd love to be able to get rid of it.
However, the way you're asking for this to happen is wrong: it feels like you requiring something to happen, plus you're writing walls of bad-feelings-conveying text, which is a very easy way to make a maintainer not look at your messages with a good eye.
Overall, I think @johannesjo gave the best response an OSS maintainer could give in their first message:
I can see why one might want this to be otherwise and I am open for adding this optionally (opt-in) as feature (but I won't work on this myself).
You may think that an even better response would be "yes I'll do it", but this is not actually an OSS maintainer's response. This would be a contributor's response, and the OSS maintainer (sure, the same person)'s response would be the same.
Pushing more for this won't make anything happen faster, the only result it could have would be to reduce the maintainer's goodwill towards continuing maintaining this software for you for free. Do you think picking a random contributor and asking them to implement the feature for you would actually work if they already mentioned the fact that they're not willing to work on it? I'm thinking less time would be wasted if you just became a contributor yourself.
So now you have a choice: either you do it, or you wait for someone who actually has the same issue and also has time to fix it, or you pay someone to submit a PR to this project with the fix (which would be reasonable as the intent to merge such a PR has already been mentioned).
But let's not tire out OSS maintainers, it won't have any positive result for anyone :)
PS: as this is getting off-topic, please contact me to the email address in any of my recent git commits if you want to reply, and let's keep this issue focused on short messages containing just new use cases or implementation ideas.
EDIT: Just recognized that you made the same suggestion (just creating the last instance) in the original post. So yes, let's go for it! :)
EDIT2: Thinking further about this, I think it's best to give the users the option to decide what should happen via a dialog, because we cannot reliably predict what is preferable to them. In case we need it, we can expand on this and also add support for creating multiple past instances.
I spent a little bit of time thinking on this (thanks for your input on this!). I absolutely understand the problem the current behavior causes for monthly and maybe even weekly tasks. At the same time I also want to avoid the case, that there a ton of tasks created in case someone hasn't opened the app in a while. (not great, if you come back from a vacation ;)).
To re-frame your original suggestion to a scenario:
This likely also simplifies the required code by quite a bit, since we only have to check for one date per repeating task.
This issue has not received any updates in 90 days. Please comment, if this still relevant!
Still relevant
I just want to say this is something that has been quite an issue for me. I have meetings I need to prepare for weekly along with emails I need to send out to teams/groups of people. I usually have this as a weekly reminder on monday and then get to it hopefully monday, but sometimes it needs to be tuesday. When I have monday off (or it's a holiday) I may not open SP on monday and then when tuesday comes and I open the app I never get those reminders at all. I agree that some may want it that way, but having the option to "display if date has passed" or something like that, would be great. please.
Johannes, thank you for all you are doing with this app, it is almost a daily use for me and the only one that I could find that would do what I wanted, be cross platform, and keep me in control of my data.
but having the option to "display if date has passed" or something like that, would be great. please.
Thanks @realmrealm this could be an approach!
as an addition to this, one other thing that I have observed is that if you have a recurring task and you have the program open prior to that day and do not close it the task will not be picked up on the day it is set to remind/display.
Example: if there is a task scheduled to come up on a tuesday, and you open SP on monday on your computer and do not close it (I'd assume this is a normal thing for people to do) when tuesday comes the task will not display unless you close and then reopen SP, further I'm assuming that if you kept it open until wednesday and then closed and reopened you would miss the scheduled task completely
I'm not a programmer, but I'm aware that it is probably that a check of date/time and scheduled tasks only happens at opening. Is it possible to have SP be aware of the date/time at time of sync? (I'd assume most people have a sync happening at some regular interval), or maybe a hard-coded check every x minutes makes more sense for those that don't sync. maybe that would help it display scheduled items if the app had been open prior to the scheduled task.
If this should be a separate issue let me know and I can submit separately.
If this should be a separate issue let me know and I can submit separately.
Yes please! This sounds like a separate issue to me!
This issue has not received any updates in 90 days. Please comment, if this still relevant!
Still relevant, I would also really like to see this feature. :)
Example use case: I have several tasks that need to be done on the first day of the week (e.g., "submit timecard") so I have them scheduled to recur on Monday. However, if Monday is a holiday and I don't open Super Productivity, then I would like for those tasks to be created on the next day that I open it. On the other hand, tasks like weekly meetings make sense to skip if the app is not opened on that day. Regarding the point you made above about wanting to avoid a ton of repeated tasks if the app hasn't been opened in awhile, I feel that creating a single instance of each missed repeated task would make sense.
Maybe a good way to present this to the user would be to add a checkbox in the repeat task config saying something like, "skip task if app is not opened" and have it checked by default. For example:
Then let's say I take a week and a half vacation, miss two Mondays, and open the app on a Tuesday. I'd get one instance of "check email," one instance of "submit timecard," but no instances of "team meeting." This behavior would be ideal for me, although I know it might be challenging to implement.
Super Productivity is awesome! Ever since I started needing to track not only my to-do list but also my time spent it's become an indispensable part of my daily routine, and the fact that it's free and keeps my data private is incredible. Thank you for your hard work developing it! 🙏🏻
Thank you @lisakmalins ! Makes a lot of sense to do it like this. PRs are welcome! :-)
So, I have a bunch of tasks that repeat every week. It doesn't matter when I do that within the week, so I just chose a fitting day (eg. Monday). However, sometimes I take that day off and hence don't start SP at all. In the past (pre 7.10) these tasks would be added to my 'today' when I open SP the next time (with the neat 'overdue' pop-up :) and I'd simply add them to my 'today' – However since I updated to 7.10 (7.10.1 to be precise) last week, those tasks don't show up anymore.
I checked the repeat config (due to the migration) and it seems fine with 'custom repeat' set to the previous day(s). So, I really think there is just smth. going on with days SP wasn't used on. And if so, then it might be a huge issue for any monthly or even weekly repeatTask…
Your Environment
Expected Behavior
RepeatTask/Tasks are created even if their due date lays days in the past (IIRC, it even created multiple instances, if multiple due dates laid in the past; though not sure about that one)
(Keep in mind, though probably unrelated) New instances should be created, even if a previous instance isn't marked as 'done' (again, pre 7.10 behavior I saw).
Current Behavior
No new instances of the tasks were created when one day was skipt.
Steps to Reproduce (for bugs)
Migrate from pre 7.10 to 7.10 or later. (However, I don't think that's related, as the repeatTask configs seem fine; and I had no errors(console/logs) or other issues after migrating)
Console Output
- Can't see any useful logs/stuff about repeat; Is there some sort of tag I can filter for like the
[M]
for migration? -Error Log (Desktop only)
- Just non helpful
[info]
entries