Tasks: extract tasks like this - [ ] this is a task (See obsidian data view)

[rufuspollock]

extract tasks like this - [ ] this is a task (See obsidian data view)

Acceptance

• File object has a tasks property with list of tasks ✅2023-11-27 in PR [ #60 , extract tasks ] #71
• Each task has a description (the full text) and checked (true/false) ✅2023-11-27 in PR [ #60 , extract tasks ] #71
• BONUS: summary of what dataview does in detail below
  • short intro text
  • copy/paste the full interface definitions
  • highlight what a task is versus a list item
  • describe how we differ (may be obvious but still briefly spell out)

Design

This is the ListItem interface for DataView

ListItem {
    /** The symbol ('*', '-', '1.') used to define this list item. */
    symbol: string;
    /** A link which points to this task, or to the closest block that this task is contained in. */
    link: Link;
    /** A link to the section that contains this list element; could be a file if this is not in a section. */
    section: Link;
    /** The text of this list item. This may be multiple lines of markdown. */
    text: string;
    /** The line that this list item starts on in the file. */
    line: number;
    /** The number of lines that define this list item. */
    lineCount: number;
    /** The line number for the first list item in the list this item belongs to. */
    list: number;
    /** Any links contained within this list item. */
    links: Link[];
    /** The tags contained within this list item. */
    tags: Set<string>;
    /** The raw Obsidian-provided position for where this task is. */
    position: Pos;
    /** The line number of the parent list item, if present; if this is undefined, this is a root item. */
    parent?: number;
    /** The line numbers of children of this list item. */
    children: number[];
    /** The block ID for this item, if one is present. */
    blockId?: string;
    /** Any fields defined in this list item. For tasks, this includes fields underneath the task. */
    fields: Map<string, Literal[]>;

    task?: {
        /** The text in between the brackets of the '[ ]' task indicator ('[X]' would yield 'X', for example.) */
        status: string;
        /** Whether or not this task has been checked in any way (it's status is not empty/space). */
        checked: boolean;
        /** Whether or not this task was completed; derived from 'status' by checking if the field 'X' or 'x'. */
        completed: boolean;
        /** Whether or not this task and all of it's subtasks are completed. */
        fullyCompleted: boolean;
    };

What might be beneficial for us:

1. Symbol: It could be '*', '-', '1.', or another character.

2. Link:

   • Represents a link pointing to the task or the closest block containing the task.

3. Text:

   • Represents the text of the list item, which may consist of multiple lines of Markdown.

4. Tags:

   • Represents the tags contained within the list item.
   • Scenario in which we might need it: Tags could be utilized to categorize tasks or list items. This allows users to easily filter and search for specific types of tasks, such as those related to a particular project or with a specific priority level.

5. Parent and Children Information:

• parent?: number;
  Represents the line number of the parent list item, if present. If undefined, this is a root item.
• children: number[];
  Represents the line numbers of children of this list item.
  Scenario in which we might need it: When organizing tasks in a hierarchical manner, the parent and children information becomes crucial. For instance, in a project management tool, a parent task could represent a project, and its children could be individual tasks or subtasks. This hierarchy helps in visualizing and managing the project structure.

12. Fields:

• Represents any fields defined in this list item. For tasks, this includes fields underneath the task.
  • created: This field could be used to show when a task was initially created.
  • due: It provides the due date for a task.
  • start: Represents the start date of a task.
  • scheduled: Indicates the scheduled date for a task.

Distinguishing Tasks from List Items:

In DataView, tasks and list items are distinct entities. Tasks are characterized by the presence of checkboxes and associated status indicators.

Notes

interface Task {
  description:
  checked: true/false
}

And then give an example e.g.

- [ ] publish hello world

turn into ...

Unique Features That DataView has and we don't:

• Comprehensive Task Completion Status:
  DataView surpasses basic completion tracking by assessing not only the task's completion status but also examining whether all subtasks associated with it are fully completed.

• Selective Property Extraction:

  In addition to task completion analysis, DataView offers the functionality to selectively extract specific properties related to time management. The properties considered for extraction are:

  • created: If available, the 'created' property is extracted and incorporated into the DataView result.
  • due: If present, the 'due' property is extracted and included in the DataView result.
  • start: If the 'start' property exists, DataView extracts and integrates it into the result.
  • scheduled: DataView also considers the 'scheduled' property, extracting and including it if available.

• List of Children:

  This might be needed to check for subtasks.

[mohamedsalem401]

Just to be on the same page:

1. We will only be extracting description and completed (boolean) for now.
2. I will only add the generated tasks to the generated TypeScript fileObject and not in the SQL table, at least for now, unless you think otherwise.

Those are not needed for now, but I will leave them here anyway:
In addition to extracting the description and completion status (boolean), we might also consider extracting:

1. Task Priority: Allow users to assign priorities to tasks, such as high, medium, or low. You could look for patterns that indicate priority levels like !, !!, !!!, or similar symbols.

   Example: [!] High-priority task

2. Due Date: If tasks include due dates, you could extract information related to dates. This could be in various formats like due: 2023-11-30 or by: tomorrow.

   Example: [ ] Complete project by: 2023-11-30

3. Assignee: If tasks are assigned to specific individuals, you could look for mentions of user names or initials.

   Example: [ ] Assign task to @JohnDoe

4. Labels or Tags: Categorize tasks with labels or tags. Look for patterns like #tag or [label].

   Example: [ ] Review document #urgent

[rufuspollock]

@mohamedsalem401 good analysis and i think i would start by defining the JS/TS object that a task gets converted to

e.g.

interface Task {
  description:
  checked: true/false
}

And then give an example e.g.

- [ ] publish hello world

turn into ...

[rufuspollock]

Is this now done?

[mohamedsalem401]

@rufuspollock

The code is ready, and tests were added/updated. However, one question remains: where should the tasks be added?

1. Add tasks to file metadata.
2. Add a table for tasks.
3. Only add tasks for the generated fileObject (this will have no effect on the user).

[rufuspollock]

@mohamedsalem401 add to file metadata and don't worry about sqlite for now. Just have an attribute on File called tasks.

[mohamedsalem401]

This is the old analysis

interface Task {
    /** The text in between the brackets of the '[ ]' task indicator ('[X]' would yield 'X', for example.) */
    status: string;
    /** Whether or not this task has been checked in any way (its status is not empty/space). */
    checked: boolean;
    /** Whether or not this task was completed; derived from 'status' by checking if the field 'X' or 'x'. */
    completed: boolean;
    /** Whether or not this task and all of its subtasks are completed. */
    fullyCompleted: boolean;
};

Key Features:

• Task Definition:
  • Status: Represents the text enclosed in the brackets of the '[ ]' task indicator.
  • Checked: Indicates whether the task has been checked (non-empty status).
  • Completed: Reflects whether the task is marked as completed ('X' or 'x' in the status).
  • Fully Completed: Determines if the task and all its subtasks are completed.

Distinguishing Tasks from List Items:

In DataView, tasks and list items are distinct entities. Tasks are characterized by the presence of checkboxes and associated status indicators, while list items are managed independently. This clear differentiation ensures the precise handling of tasks within DataView.

Unique Features:

Task Completion Analysis:

• Comprehensive Task Completion Status:

  • DataView surpasses basic completion tracking by assessing not only the task's completion status but also examining whether all subtasks associated with it are fully completed.

• Selective Property Extraction:

  • In addition to task completion analysis, DataView offers the functionality to selectively extract specific properties related to time management. The properties considered for extraction are:
    • created: If available, the 'created' property is extracted and incorporated into the DataView result.
    • due: If present, the 'due' property is extracted and included in the DataView result.
    • start: If the 'start' property exists, DataView extracts and integrates it into the result.
    • scheduled: DataView also considers the 'scheduled' property, extracting and including it if available.

[rufuspollock]

@mohamedsalem401 can you put the summary of dataview in the body of the description (and then just put a note in the comment that you've added material).

@mohamedsalem401 in terms of the summary i thought the dataview approach were that tasks were just a subtype of ListItem - if so i would definitely included the interface definition of ListItem or whatever it is called.

[mohamedsalem401]

@rufuspollock
I have added the interface for dataview's listItem, and also some analysis for properties that we might benefit from.

[rufuspollock]

@mohamedsalem401 how much work is it to extract the extra fields e.g.

created: If available, the 'created' property is extracted and incorporated into the DataView result.
due: If present, the 'due' property is extracted and included in the DataView result.
start: If the 'start' property exists, DataView extracts and integrates it into the result.
scheduled: DataView also considers the 'scheduled' property, extracting and including it if available.

Can we find the code for this in dataview and reuse?

[rufuspollock]

FIXED. Follow up in #82