Infer tasks created date from note name

[johanfriis]

I spoke with @claremacrae about a week ago about adding a feature to Tasks that enabled a tasks created date to be inferred from it's parent filename.

There is already a similar feature for scheduled dates implemented, so ideally we would want to reuse as much of that code as possible, while refactoring to encompass multiple cases.

I had a look at the code, and it seems to be pretty tied to the concept of scheduling, but I believe some refactoring could uncouple that part.

One way of tackling this, is to change the "Use filename as Scheduled date for undated tasks" settings option to a dropdown (and change the wording obviously), that allows the user to select whether they want the filename to reflect the scheduled or the created date. If turned on, the default should obviously be schduled, to keep backwards compatibility.

I would be interested in hearing any thoughts on this feature and would most likely be happy to take a stab at implementing anything that is decided makes the most sense.

[claremacrae]

Hi @johanfriis!

I spoke with @claremacrae about a week ago about adding a feature to Tasks that enabled a tasks created date to be inferred from its parent filename.

Super - many thanks for following up on this...

There is already a similar feature for scheduled dates implemented, so ideally we would want to reuse as much of that code as possible, while refactoring to encompass multiple cases.

Definitely...

I had a look at the code, and it seems to be pretty tied to the concept of scheduling, but I believe some refactoring could uncouple that part.

Agreed.

Design of the feature

One way of tackling this, is to change the "Use filename as Scheduled date for undated tasks" settings option to a dropdown (and change the wording obviously), that allows the user to select whether they want the filename to reflect the scheduled or the created date. If turned on, the default should obviously be schduled, to keep backwards compatibility.

My feeling about this suggestion is that it then encompasses 2 people's personal choice of field, rather than the current 1 person's...

And it would soon be followed by people asking for the same for Starts and Due (my personal preference!)

So that might suggest a checkbox against each of the date types (except Done 😄 )

Use filename as date for undated tasks

Created     [ ]
Starts      [ ]
Scheduled   [ ]
Due         [ ]

The current default is for 'Use filename as Scheduled date for undated tasks' to be turned off. So none of the checkboxes above would be on by default (unless the user had previously turned on the Scheduled option.)

Soon there will be a Reminder field too.

I might like then to use the file date as a default for both Due and Reminder.

Which would be easy:

Use filename as date for undated tasks

Created     [ ]
Starts      [ ]
Scheduled   [ ]
Due         [x]
Reminder    [x]

Arrangement of the settings

The Tasks settings currently look something like this:

{
  "globalQuery": "",
  "globalFilter": "",
  "removeGlobalFilter": false,
  "taskFormat": "tasksPluginEmoji",
  "setCreatedDate": false,
  "setDoneDate": true,
  "autoSuggestInEditor": true,
  "autoSuggestMinMatch": 0,
  "autoSuggestMaxItems": 12,
  "provideAccessKeys": true,
  "useFilenameAsScheduledDate": false,
  "filenameAsDateFolders": [],
  "recurrenceOnNextLine": false,
  "statusSettings": {
    "coreStatuses": [
      {
        "symbol": " ",
        "name": "Todo",
        "nextStatusSymbol": "x",
        "availableAsCommand": true,
        "type": "TODO"
      },
      {
        "symbol": "x",
        "name": "Done",
        "nextStatusSymbol": " ",
        "availableAsCommand": true,
        "type": "DONE"
      }
    ],
    "customStatuses": [
      {
        "symbol": "/",
        "name": "In Progress",
        "nextStatusSymbol": "x",
        "availableAsCommand": true,
        "type": "IN_PROGRESS"
      },
      {
        "symbol": "-",
        "name": "Cancelled",
        "nextStatusSymbol": " ",
        "availableAsCommand": true,
        "type": "CANCELLED"
      }
    ]
  },
  "features": {
    "INTERNAL_TESTING_ENABLED_BY_DEFAULT": true
  },
  "generalSettings": {},
  "headingOpened": {
    "Core Statuses": true,
    "Custom Statuses": true
  },
  "debugSettings": {
    "ignoreSortInstructions": false,
    "showTaskHiddenData": false
  }
}

For newer settings, I am favouring putting them in to groups, as the flat list at the top is getting a bit too long, subjectively.

In this case, the list of date types is definitely going to grow, so grouping them together in some way would be helpful, I feel.

Backwards compatibility of the settings

I do not know how to do this, but ideally on first run, the new code would read the old Scheduled setting and copy it to the new settings location.

I know a few other plugins do this kind of thing, so it must be possible...

---

I would be interested in hearing any thoughts on this feature and would most likely be happy to take a stab at implementing anything that is decided makes the most sense.

Thank you - I would be interested in hearing your comments on the above...

As you're presumably new to the Tasks code, I would be very happy to have an initial pairing session to talk you through the relevant bits of code to get you started... It might save quite a lot of time for us both...

---

Any other business....

As I write this, I realise that the wording 'undated tasks' is interesting now that 'Created' has been added. Is a task with Created date considered as Dated, from the perspective of the current implementation. I don't know the answer to that....

[johanfriis]

Great followup Clare. Let me talk to some of your points

My feeling about this suggestion is that it then encompasses 2 people's personal choice of field, rather than the current 1 person's...

And it would soon be followed by people asking for the same for Starts and Due (my personal preference!)

I agree, we should definitly arrive at a common solution that could work for any type of date inheritance

So that might suggest a checkbox against each of the date types (except Done 😄 )

The issue I can see with a checkbox is that it implies that multiple dates can be inferred from the title and I'm not sure that is feasible. If we agree on that, then I would propose the following UI:

For newer settings, I am favouring putting them in to groups, as the flat list at the top is getting a bit too long, subjectively.

I agree on that. A proposed shape, assuming the above implementation could be:

{
  inferDateFromFileName: {
    dateType: 'createdDate' | 'scheduledDate' | 'startDate' | 'dueDate',
    enableReminder: boolean,
    supportedFolders: string[] // or maybe TFolder[]?
  }
}

ideally on first run, the new code would read the old Scheduled setting and copy it to the new settings location.

We could definitely look at doing something like that. Not 100% sure how it would be done specifically, but I'm certain it can be done :)

I wonder if you would want to deprecate the old setting and the migration code at some point though 🤔 Ideally this migration code should not be coupled directly to the feature itself, but perhaps be something a bit generic that can be scrapped without impacting the feature?

I would be very happy to have an initial pairing session to talk you through the relevant bits of code to get you started... It might save quite a lot of time for us both...

I would definitely be open for this. I'm sure it would save a bunch of time 😄.

Is a task with Created date considered as Dated, from the perspective of the current implementation

I would say that tasks are considered dated differently, depending on the settings of this feature. If I am inferring createdDate, I don't care if the task has a scheduledDate already. If I'm inferring scheduledDate, I don't care if the task already has a createdDate. The current implementation of this feature already looks at whether the task has a startDate or dueDate, so probably that should be respected.

[claremacrae]

I would be very happy to have an initial pairing session to talk you through the relevant bits of code to get you started... It might save quite a lot of time for us both...

I would definitely be open for this. I'm sure it would save a bunch of time 😄.

Oh that's great news. 😄

My email address is in my profile here... If you would like to drop me a line we can find a time that works for us both, and we continue the conversation then...