Repeat Every X Days (Monthlies) [$140]

[lemoness]

This is a Github ticket for this much-requested Trello card feature so that people can put Bounties on it!

From card: Tasks that repeat every "n" days

Examples: Every 5 days after last Clean Bathroom On Aug 1st every year, Send birthday card Every 2 weeks ... Every 3 days ...

The original card is here: https://trello.com/c/XuVokK2V/108-repeat-every-days-weeklies-monthlies

There is a $140 open bounty on this issue. Add to the bounty at Bountysource.

[crookedneighbor]

Maybe look at the way Todoist handles repeating events: https://todoist.com/Help/timeInsert

[lemoness]

A lot of people on Trello recommend the way Todoist handles things so that's a good suggestion.

On Tue, Oct 21, 2014 at 6:03 AM, Blade Barringer notifications@github.com wrote:

Maybe look at the way Todoist handles repeating events: https://todoist.com/Help/timeInsert

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/4173#issuecomment-59923496.

[lemoness]

I've just added an additional $50 to this ticket.

[me-and]

I've not published it widely yet because it works but isn't commented/documented, but if you have a handy system that can run a Python3 script on a regular basis, the Python3 module I've been writing has a script that implements recurring tasks and might work as an interim solution.

My next task with the module is to get it commented to a point at which I'm happy advertising it more widely, but I thought it might be useful here as an interim solution.

[breadstrings]

Would this also include weeklies and yearlies?

[lemoness]

Yes, ideally, since there was talk of implementing it as "repeat every X days."

On Monday, November 3, 2014, breadstrings notifications@github.com wrote:

Would this also include weeklies and yearlies?

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/4173#issuecomment-61477643.

[breadstrings]

But considering leap years, and the different days of the month, would it really be "repeat every X days" or should it also include a specific date it repeats on as well as a task that appears on the first of week/month/year and lasts for the duration of the month/year if ticked off, but clears the tick on the next first of week/month/year?

Did that make sense? I know it was one of the things requested on Trello, but I can't remember if it's the same card or a different feature.

[crookedneighbor]

@lemoness Will this be in addition to dailies, or replacing dailies?

[breadstrings]

@crookedneighbor - I believe this will be in addition to dailies.

[paglias]

I think the biggest blocker here is the design. Someone has an idea on where to put them? I believe another 2 columns are out of question for a lot of reasons, starting from space

[lemoness]

What about having them as tabs, or a toggle-able checkbox? How do other sites do this?

On Fri, Nov 28, 2014 at 11:37 AM, Matteo Pagliazzi <notifications@github.com

wrote:

I think the biggest blocker here is the design. Someone has an idea on where to put them? I believe another 2 columns are out of question for a lot of reasons, starting from space

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/4173#issuecomment-64923730.

[crookedneighbor]

@paglias I agree, adding even one more column would be undesirable.

@lemoness The best implementation I've seen of it is Todoist. Takes some getting use to using natural language processing instead of a series of buttons, but it becomes very efficient.

The difficult thing is dealing with making it translation friendly. Could be a reason to take it off the table entirely.

iCal on Macs use this for repeating events:

Here are the options for custom:

It might be worth doing both a natural language option and a dropdown/button option.

[Alys]

I think where they're put would depend on whether the user wanted to be punished if they did not do the task on the exact day specified (Dailies) or not punished (To-Dos). I could see people wanting both options.

[woop]

I'd like to develop this feature since it is in very high demand. The problem I have is that there isn't a consensus on exactly what functionality is required, and how the user interface must accommodate this. At the moment we have loads of people pitching in ideas and features that they would like, but I don't know which I should include.

If somebody can give me a breakdown of exactly what is required then I can start coding it.

[deilann]

I think there are two separate features desired: monthlies and repeating tasks.

Monthlies would be due on a specific day of the month, just like weeklies are due on a specific day of the week. In other words, they are more like Dailies.

Repeating tasks would be tasks not tied to a specific day -- in other words, they are To-Dos that should auto-generate with a deadline.

On Sat, Nov 29, 2014 at 1:18 AM, Willem Pienaar notifications@github.com wrote:

I'd like to develop this feature since it is in very high demand. The problem I have is that there isn't a consensus on exactly what functionality is required, and how the user interface must accommodate this. At the moment we have loads of people pitching in ideas and features that they would like, but I don't know which I should include.

If somebody can give me a breakdown of exactly what is required then I can start coding it.

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/4173#issuecomment-64946169.

[paglias]

@deilann but repeating tasks wouldn't behave like dailies in terms of damage? If I create a "weekly" I would like it to do damege if I didn't complete it during the whole week

[paglias]

@willempienaar I think we're still brainstorming it :)

@crookedneighbor I like what iCal does, I would love it under a tab that is the current Dailies (with changed name) which cover all the different uses

[crookedneighbor]

@paglias makes a good point. There are two kinds of repeating tasks here:

1) Tasks that repeat at a set interval and should be completed on a specific day. IE, every Monday, every 3 days or every 2nd of the month.

2) Tasks that repeat within a set interval and must be completed within that time frame, but not on a specific day. IE, once a week or twice a month.

The first seem like they should be treated like dailies, but the second should be treated like todos.

For simplicity's sake, it might be best to leave dailies as is, for tasks that occur at regular intervals in a week, and allow todos to have a repeating option for everything else.

If not that, I think that dailies would need to be overhauled completely to make this (proposed and still unclear) system work, and I'm not sure that it's worth it.

Thoughts?

[Alys]

"For simplicity's sake, it might be best to leave dailies as is, for tasks that occur at regular intervals in a week, and allow todos to have a repeating option for everything else."

I like this. At the very least, it could be the first solution that's made for this issue, and then later Dailies could be modified if there still seemed to be a need for it.

[lemoness]

I'm also a fan of expanding Dailies to encompass Weeklies/Monthlies, and then leaving the repeating for a different feature! I think iCal does it well. Should I change the name of this ticket?

[crookedneighbor]

For the todos, one approach would be this:

After a todo is checked as completed, check if it has the repeating flag. If it does, change the due date to the next applicable date and uncheck the todo.

So if the repeating flag is once a month, and it's November, my due date will be November 30th. If I complete the task in November, the due date will be changed to December 31st. If the November todo doesn't get completed until some time in February, the due date would change to March 31st (rather than December, since that has already passed).

[lemoness]

Should I split off a separate ticket and give it the $50 December Bounty? If so, should I branch off Monthlies, or Repeat Every X Days?

On Sun, Nov 30, 2014 at 8:25 AM, Blade Barringer notifications@github.com wrote:

For the todos, one approach would be this:

After a todo is checked as completed, check if it has the repeating flag. If it does, change the due date to the next applicable date and uncheck the todo.

So if the repeating flag is once a month, and it's November, my due date will be November 30th. If I complete the task in November, the due date will be changed to December 31st. If the November todo doesn't get completed until some time in February, the due date would change to March 31st (rather than December, since that has already passed).

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/4173#issuecomment-64990406.

[Alys]

"After a todo is checked as completed, check if it has the repeating flag. If it does, change the due date to the next applicable date and uncheck the todo."

Another option would be to clone the To-Do and leave the original one untouched (and still ticked off). This would be a more "pure" approach because the original To-Do really has been completed and there might be people who care enough about their statistics to want the number of completed To-Dos to be accurate.

It would also make a difference to anyone using the Beeminder integration (see also this) to track their number of completed To-Dos. Keeping the original To-Do uncompleted could make the difference between remaining on track on their goal versus falling off it and losing real money. From that point of view, I think it's definitely worth keeping the original To-Do ticked off.

[crookedneighbor]

@Alys Good thinking on that.

[kusold]

Following because this will directly impact the my todoist-habitrpg sync.

My personal opinion is that very infrequent tasks such as "yearly" tasks would be a better fit for someone's calendar than a todo manager. The monthly and after last tasks do have direct value here, but habitrpg should be careful implementing this as to not break backwards compatibility without notice.

[crookedneighbor]

I'm working with @Kusold on the todoist-habitrpg module.

For repeating Todos, I like @Alys's suggestion that the task be copied, but I think if the task is completed via the API, there should be some kind of option to force it to not automatically copy itself. That will allow a one-way-sync third party service to recreate the event instead, and remain in sync.

If that provision is not in place, this module in particular would have no way of linking the copied todo with the original repeating todo in Todoist.

Does that make sense?

[Alys]

That does make sense, but if the task is coming from a third-party service (todoist in this case), isn't that service where repeats would be set up, not in HabitRPG? Or am I misunderstanding what you're saying (sorry!)?

[crookedneighbor]

@Alys Right, but if you wanted the data for how the task repeats to be displayed in the todo on habit, that could cause a conflict. Let's say we added a text box underneath "due date" called "repeat every..." and lets say we add some kind of symbol somewhere on the collapsed version of the task to show that it is a repeating event.

The todoist-habitrpg module could just ignore the repeating event information in Todoist, and create a new todo every time, but then there could be some confusion when examining the details of the task on habit as to whether or not the todo repeats.

It's not a huge deal, since if you're using this module, you're mainly going to be working from Todoist anyway, but it is nice to be able to sync as many data points as possible between task services.

Does that clarify what I meant @Alys?

The more I think about it though, the more I think that @Kusold should just not sync the information about repeating events to Habit. Just the conversion from Todoist's way of doing things to Habits (once it gets implemented) will be a huge headache, for very little pay off, since the only gain is maybe a small symbol that the event repeats and information about the task that can also easily be seen in Todoist.

[kusold]

I think the primary focus should be on what makes the most sense for HabitRPG. I can work around most limitations that arise.

However, one pitfall that we've encountered with the way Todoist implements daily tasks, is that there is no difference between "completing" and "postponing". It simply just changes the due date which makes it difficult for 3rd Party devs to determine what exactly the action was. Therefore I think it would be useful for HabitRPG to maintain a last-completed state on repeating objects.

[sadanyagci]

I posted some suggestions in this area here: https://github.com/HabitRPG/habitrpg/issues/4477

1. Summary of mentioned issues this feature needs to take into account.
   1. Strings translating into repeat calculations.
   2. Difference between completed and postponed.
   3. Difference between todo and daily, and what belongs in which category.
   4. Postponing sometimes carrying over into following repeat calculations, and sometimes not.
   5. How to display.
2. Other issues to take into account:
   1. Notes on individual repeats.
   2. Individual rescheduling rather than postponing.
   3. Accepted feature request: start and end dates.
   4. Accepted feature request: alarms, reminders, times.
   5. Future calendar implementation possibilities.

I propose this solution:

1. Make the difference between a repeat and a todo whether or not it happens more than once. This will make it easy to differentiate when a user is making the task (so a user knows what's being made while making it, rather than having to keep rules in their heads), and easy to differentiate software-wise. _1iii_
2. Subtasks in the database
   • Store all tasks under Default task. Subtasks override parent task information, making it easy for people to set defaults that apply to every task and only change what they want. Useful for alarms, reminders, start and end times, dates, and functions as a more functional version of daystart. _2iii, 2iv_
   • Store all changes to individual repeats under their task with their own task ID. This will take care of postponing and individual task or daily rescheduling. _1iv, 2i, 2ii_
   • If repeater is changed, past event default labeled "archive" so as to keep history for calendars (repeater date string modified with a start and end date). This would allow multiple archives, each with their own list of past events. Previous changes made to future events are discarded. _2v_
3. Add a button for marking a task not done at all. _1ii_
4. Task editing in modal box rather than inline. _1v_
   • Ask a question, when changing a sub-task, whether the change should apply to the parent or just that one event. AND/OR have two save buttons (save just this occurrence, and save to repeater) AND/OR clicking edit opens menu to choose between editing that event or all future events _1iv_
5. I agree with implementing string interpretation for dates and times, like todoist. _1i_
6. Rename "Dailies" "Repeaters"

This should keep everything more-or-less as-is and yet allow a lot of additional features and future implementations in unobtrusive ways.

[sadanyagci]

By the way, I have a local habitRPG instance running and am learning the site code. I'd be willing to implement the changes myself or help with implementation or testing.

[crookedneighbor]

One thing to keep in mind with the "Strings translating into repeat calculations." (similar to Todoist) is that HabitRPG is a multilingual site and we shouldn't force non-English speakers to use English phrases to create repeating events.

[sadanyagci]

True. Why not have the system check what language the user uses and run the strings through for interpretation based on that?

[kusold]

I'm not good at languages, but you might run into grammar issues.

Examples with how languages might strictly be translated into English:

every month vs month every every X days vs X every days vs every days X vs something other variation

[sadanyagci]

Fetch a different interpretation function depending on the language, and/or provide a key for how they should type things in the box, grammatically. If a language doesn't have a function yet, default to the current system.

Two possible options for creating translations are:

1. Create a translation questionnaire and have popup messages for people who use languages that have no functions, requesting they answer a few questions for you. They type some answers, perhaps one translator looks them over to make sure answers don't have errors and possibly fill in a few blanks, and you've got it working.
2. Let people type what ever they want into the box. If something isn't understood, show it in the date/time box as pending review. Have answers that aren't understood compiled into a database list, holding the user, task ID, language, and string for each item. With that list, we create functions to fit them, looking up the words as we go and using their grammar. If we find an item completely unintelligible, we mark it rejected. We'll need a system for a task to display that a date wasn't understood after-the-fact, perhaps changing color or showing a bunch of question marks in the date box, or both. This way, it can continually increase in capability and no translators are needed, nor questionnaires.

[sadanyagci]

Would anyone object to me starting development on this project in the way I described above, with option 2 of the other above comment of mine, keeping as much exactly as is as possible?

[deilann]

Yes. Your translation solution causes a significant amount of overhead for Habit's developers, where there was previously none.

The subtask solution is a major change that may not be desired implementation.

I don't like the idea of editing tasks in modal.

I don't like the term Repeater.

(Brief because I'm running out the door not because I'm trying to be passive-aggressive.)

[Alys]

I'm troubled by the natural language translation idea. I think unless it's very clear to the users how to use it, it would be confusing and prone to user-error, and because so many languages are involved (some of them translated by inexperienced translators, or not translated at all), the possibility for confusion is increased.

Initially, I think I'd like to see a less flexible but easier to understand interface where you pick from a small range of options (e.g., drop-down for selecting day/week/month and then an integer field for specifying a number). That would cover a large range of use cases, with only a small requirement for new translations, and with little chance of user confusion.

Then once that was working well, an additional natural language interface could be added over the top of it to give extra flexibility (with the original interface always remaining available).

[lemoness]

For ease of explanation and user onboarding, I would like repeating To-Dos to be kept as simple as possible - I liked the previous ideas that Blade and Alice were discussing. We already have complaints that HabitRPG is not intuitive enough for the average user, and I'd like to avoid exacerbating that.

On Fri, Jan 16, 2015 at 4:38 PM, Alice Harris notifications@github.com wrote:

I'm troubled by the natural language translation idea. I think unless it's very clear to the users how to use it, it would be confusing and prone to user-error, and because so many languages are involved (some of them translated by inexperienced translators, or not translated at all), the possibility for confusion is increased. Initially, I think I'd like to see a less flexible but easier to understand interface where you pick from a small range of options (e.g., drop-down for selecting day/week/month and then an integer field for specifying a number). That would cover a large range of use cases, with only a small requirement for new translations, and with little chance of user confusion. Then once that was working well, and additional natural language interface could be added over the top of it to give extra flexibility (with the original interface always remaining available).

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/4173#issuecomment-70345098.

[sadanyagci]

Ok, editing in modal was to fix something that could be fixed without it, so I can skip that.

We should probably vote on a word at some point. Daily will need replacing eventually, as it's hardly even applicable now, what with being able to make a daily weekly, and now further adding functionality.

Subtasks would keep the user side of things as-is and allow minute changes to individual dailies, such as postponing, rescheduling, making notes, setting alarms independent of the main daily, etc. What would be undesirable in that?

Ok, Gmail has a box with options for when searching. Changing one of those options or typing in one of those boxes writes in the main search box exactly what is desired. We make a default string form, making the options write that, so people can learn the exact ways they need to write if they click "advanced" or select "advanced" as their default. The "when" section of the event settings would have a "schedule" button. Click it and it pops up the options "pick date" (brings up a calendar), "every day", "weekly" (brings up selecting the days of the week), "monthly" (brings up selecting the days of the month. If the 29th, 30th, or 31st are chosen, show an option for rescheduling those for the last day of the month if the month doesn't have those days), "yearly" (pick from calendar or type it in), "every ... days", "... days after last". Then, after options are chosen, it shows the text as replacing that "schedule" button in the language format we choose. After the text is a delete button and an edit button, with the next line having a link that says "add". If add is clicked, it does the same as clicking "schedule", and then adds it to the next line, with a comma on the end of the previous line. That way people can learn how to write the advanced text if they want, but don't have to. If advanced is clicked, or selected as default, this is all replaced by a text box with a link for help with how to write in the box. Would that work?

[sadanyagci]

Future possible addition to that. Schedule a task to be completed after a different task. Perhaps you want to do something, but only after you've already done something else, or at the very least you want a reminder to do that following thing, so you can if you do need to do it, but if you don't need to do it you can press "N/A" and it will know you don't need to do it.

[Alys]

How would subtasks work from a user's perspective? What would they do to create a subtask? How would they see subtasks in relation to the parent task? Would there be potentially many subtasks for a single parent task? If so how would they all be displayed to avoid confusion?

If subtasks are done for Dailies, how is damage from incomplete subtasks and/or the parent task handled?

[sadanyagci]

It would only be a subtask from a development standpoint. A daily would be one task that schedules itself for multiple days and times. Each event would have that daily's settings, except if the person wanted to change something, like click an N/A button so they don't have to do it that day, or add a note, or change it from 4:30 to 5:30, or postpone it to tomorrow. From a database perspective, the daily doesn't change, but the event is added under the daily, with what ever setting is changed saved under it.

Above the daily, and todo's, would be the default settings for all tasks, set by the user in their settings page. This would allow users to set default reminder times and types, default task start and expire times (which would work better than daystart as it would have the same functionality but be more flexible), add default labels that they can remove on a per-task basis, and basically anything they want to make default for when they make tasks (perhaps a default note, like "GET IT DONE, SOLDIER"). We would set the initial default. They would change it only if they want to.

[Alys]

Subtasks really do seem like a big change for the backend - changes to the database structure, much extra code, and differences in how cron processes damage for Dailies. We've had various issues with cron over the past many months which we are only recently getting under control; I wouldn't like to see more changes made to cron until our current code is proved to be stable and correct in the long term. I'm not saying that subtasks are necessarily undesirable, but I think it's best that they are not implemented right now.

Instead, can we take a staged approach to your suggestions? For example, first implement a less flexible but easy to understand interface for allowing Dailies to have better repeat options. Even just a few, simple options would improve the current situation and we could see how the users react to them before going further. We do have a lot of non-technical and young users, so clear, intuitive options are important, and gaining user feedback at a very early stage would be very beneficial.

After some simple repeat options have been proved successful, more work could be done to expand them and to implement some of your other ideas, in further stages.

An extra benefit of a staged approach with each stage being relatively small, is that each pull request you make could be examined and tested much more quickly compared to one large submission with many new features in it. Ease of review is important because we have only a few devs that are highly experienced with our code base (almost all volunteers), and their availability is limited.

Let us know what you think of this approach!

[sadanyagci]

Stages. Ok, I like that idea as well. I'll start on it the way you suggested.

I can understand not wanting to destabilize cron again. I wouldn't say subtasks would make a difference for how cron processes damage for dailies though. There would be changes to what it considers a daily, but other than that the only difference would be that if one of a daily's events is rescheduled for the next day or set to N/A, no damage is taken for it.

[sadanyagci]

I'd like to implement java through npm in order to load Google's rfc2445 implementation in order to handle this. https://www.npmjs.com/package/java https://code.google.com/p/google-rfc-2445/ http://google-rfc-2445.googlecode.com/svn/trunk/README.html

This has the added benefit of being compatible with the iCalendar format and is what is currently being used by Google Calendar and a large number of other popular products.

Are there any objections to this proposal?

[lemoness]

@sadanyagci I think some of the programmers are concerned about this solution. Definitely wait to start programming until they've had some time to weigh in.

[kusold]

I'm not very active outside of this one issue, but I would definitely be wary of importing a dependency as big as the JRE into a project. While this is a robust solution, based on previous comments in this thread an MVP would be more appropriate. Probably something not as flexible but involving dropdown menus.

[Alys]

@sadanyagci What do you think about implementing this in a way that doesn't need a big dependency?

[sadanyagci]

I've been looking at other options. There's a javascript implementation here. It looks like it could work out with some modification. It functions to return correct days when working with daily, weekly, monthly, yearly, hourly, minutely... not too sure about secondly... all multiples of the previous. I haven't fully checked out its ability to work with time zones yet. It successfully returns lists of correct days within the limits specified, basically seeming to handle RFC2445 well. I'm unsure how I want to handle incorporating it yet, and my development environment is currently out of commission. If anyone wants to take a look and see what can be done, they can go right ahead. Or I can start right back up when I'm back up and running and not so busy.