Task management system incorporating tasks, completed tasks, and notifications

The idea of tasks and completed tasks will subsume the idea of logs and shifts in the Q3 2021 release. Logs will become tasks and shifts will become completed Tasks. Notifications will tie together the assignment of tasks and the transition from tasks to completed tasks to create a holistic “task management system”.

What is a task?

Tasks are a generic piece of work that needs to be completed. This “container” allows the creator to document attributes common to all tasks (such as the individual doing the task and whether it’s completed) as well as attributes required for the specific task type (such as harvest use for a harvest task). This is the core functionality farmers are looking for in their farm management system.

What type of tasks are there?

Please see Task types for a complete and current list of tasks.

What actions can be taken with tasks?

Users can perform 4 actions with tasks:

1. Create a task

2. (may be completed in creation) Assign a task

3. Edit a task

4. Mark a task as completed

5. Abandon a task

By starting from a generic flow and asking only the specific information needed for the type of task (see image below) and whether the user is seeking certification (see Certifications, certifiers, and LiteFarm), we can re-create all of the functionality currently captured in logs and shifts in a single object.

Open

How does a user create a task?

Choosing your task type is the first step in creating a task. The flow goes something like this:

1. What type of task needs to be done (e.g. seeding, scouting, etc.)?

2. When does the task need to happen?

3. Where will the task take place?

4. Does the task impact a crop?

5. What task-type specific instructions would you like to provide (e.g. which fertilizer to use for a fertilizing task, or seed spacing and depth for a planting task, etc.)?

6. (Optional) Who is going to do the task?

With the exception of step 5, this flow will be the same for all types of tasks. For a visual explanation of this you can view this flow.

Open

Additionally, in some cases the system will automatically create a task. Below is an example of the “manual” and “automatic” routes to task creation.

How does a user edit a task?

Tasks use the same edit pattern as other objects such as varietals and crop management plans.

How does a user assign a task?

Tasks can be assigned as part of the task creation flow. For tasks where the user chooses not to assign during creation or for tasks that are automatically generated there is a short-hand modal that the creator or a farm owner, farm manager, or extension officers can use to assign a user at the farm (see LF-1665 for details).

How does a user mark a task as completed or abandoned?

As the assignee or creator (or a farm owner, farm manager, or extension officer), users can “Mark completed” or “Abandon” a task. In marking a task complete, they’ll be prompted to provide the following attributes:

• Duration of task

• Satisfaction with the task

• Completion notes

• Potentially other task specific inputs

When abandoning a task, the user will be prompted to provide the following:

• Reason for abandoning the task

• Details

What is a completed task?

Completed tasks are tasks that have been marked as “Completed” or “Abandoned” (more on abandoned below). Completed tasks are roughly equivalent to present day “Shifts” in that they capture a task that took place and details about how it happened (e.g. who did it, how long it took, etc.). Completed tasks come into existence in two ways:

1. Under none or basic labour tracking (see for Labour Tracking details), the assignee of a task marks it as done. Under advanced labour tracking, a Farm Owner or Manager marks a task as done after a Farm Worker has marked it as “For review”

2. After completing some work that wasn’t documented in advanced. For example, a user can create a completed task in order to document work they weren’t assigned in advance (e.g. “Fixed fence because I saw a hole - took 20 minutes”)

Completed tasks tie together activities that have happened, who did them, what they used to do them, and what the outcome was. This concept is essential many of the core concepts and value-adds that LiteFarm presents to farmers. These include:

• Being able to understand all the revenues and expenses at your farm to understand profit overall

• Being able to understand profit on a per crop basis

• “Seed-to-sale” traceability of would-be organic produce

Abandoned Tasks

New in Q3 2021 is the ability to mark a task as abandoned. There was no equivalent to this in prior releases. An abandoned task is one that was either cancelled before it was going to begin, or couldn’t be carried out as expected. When abandoning a task, the creator, assignee, or a farm owner, farm manager, or extension officer at the farm must supply a reason and may optionally add details to support that reason.

For most purposes, “Abandoned” and “Completed” tasks are treated the same.

Task attributes

This table is starter list of generic attributes every task will have. It is NOT a complete list. In fact, each Task types will likely have their own type-specific attributes.

Notifications

Notifications will not be part of the Q3 2021 release.

Notifications serve as the communication layer for ensuring things get done on a farm. Notifications are system generated messages that are sent to users to bring something to a users' attention and to request updates that can be shared with the rest of the farm staff. Regarding Tasks and completed tasks, notifications serve a few important functions:

You can read more about notifications in general here: Notifications Centre

Migration process. From logs and shifts to tasks

The migration needs to encompass both the shift tasks and the logs that were created by farmers pre release (AUG 2021 Release).

For logs:

Since the logs table hierarchy meets most of what’s needed both for the individual tasks (fertilizer, irrigation, etc) and for the relationship between locations and management plans it makes a lot of sense to just build on top of what’s there for logs already. renaming the activityLogs table to “task” and all of the child tables of activityLog to it’s “_task” counterparts. After doing that and creating relationships for the missing tasks (transport, wash and pack, maintenance, sale, social) we end up with this diagram for the task table and all of it’s childs

There are some leftover properties that might be dropped after this which were significant for logs only, as :

• action_needed

• photo

• activity_kind

Also, the shift and shiftTask relationships become irrelevant after this and should be dropped. Their relationships to finances and insights need to be moved to tasks now.

For shifts:

Shifts are a collection of tasks that were (or are going to be) performed in a given day by a given person (assignee). The shifts have a 1→n relationship with the shiftTask table, for every shiftTask row associated with a shift, there is a task with an associated location or management plan. The attributes which are to be migrated from shift and shiftTasks are :

For each shiftTask we will also create a row in the task child table that matches the task type, as well as a row for the location OR management plans. Example :

If I had a bed preparation shiftTask in location X (not management plan) the migration will create :

• 1 row in the task table, with the migrated attributes

• 1 row in the task_location table with the location X id as well as the recently created task id

• 1 row in the field_work_task table (as bed preparation is a field work task)

It’s important to note, that shiftTasks where being created on a per location or management plan basis, this means if I had a shift that was doing a 60 minutes bed preparation on 3 separate locations, that created 3 separate shiftTasks of 20 minutes each for each location.