Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Timeliness: Notifications will be generated for events where timeliness is the key attribute. For example, creating a notification when the details of a task have changed when someone will do that task later that day is incredibly valuable as long as it’s received prior to doing the work. If it’s received after the task has been completed, it’s basically worthless. As such, we strive for near real-time notifications and acknowledge that notifications quickly become stale. Another consequence of this attribute is that notifications are mostly immutable. The only attributes that will be modified after creation are around the status of the notification, rather than the content.

  • Audience: Notifications need to target the right audience. For example, modifications to an existing task (from the timeliness example) are only relevant to the person doing the work. Other individuals would quickly learn to tune out notifications if they are not consistently relevant for the notified audience.

  • Brevity: Notifications are a “sneak peek” into events on the farm. The Notifications Centre should give the user a “window” into the relevant happenings on the farm with the option to drill-down into the events that catch that user’s attention. As such, we need to be efficient with how we describe a notification. Brevity is more important than completeness.

Notification Attributes

This is not a complete list.

Attribute

Data type

Entered / modified at…

Required?

Example data

Notes

Title

String

Entered at creation, immutable

Yes

Planting

See above. Also needs to support custom task types

Body

String

Entered at creation, immutable

Yes

Planned, Late, For review, Completed, Abandoned

Assigned via actions rather than being editable via the UI

Reference to notifying object

Ref: Record_id

Entered at creation, immutable

No

  • See “Take me there” in detail view above for an example

  • This reference will also serve as the foundation for “related notifications” and threading on the notification detail page described below

Notification scope

Enum

Entered at creation, immutable

Yes

  • Defaults to “farm-wide” unless provided

  • To start with, notifications can either be for a specific user or for all users at a farm

  • Implementation should leave the door open for role based, access-based (e.g. extension worker), and all users at all farms

Base model attributes

Implements https://lite-farm.atlassian.net/browse/LF-294

  • CreateByUserId = null

  • OwnerUserId = null

  • AssigneeUserId = null

Alert

Bool

Entered at creation

Modified when viewing the notification centre

True or false

A notification is Alert = TRUE when it is created and become FALSE when the user views the notification centre (but not necessarily the notification detail). The alert, describes where the “bell” on the status bar should have a red dot or not.

Status

Enum

Entered at creation

Modified when viewing the notification detail or a user applies a new status

  • Defaults to “Unread”

  • Other valid values: {“Read”, “Archived”}

Notification threading

There are some cases where a notification has been posted, and before being viewed becomes irrelevant or less relevant. For example, a user may be assigned a task and then that task is deleted or re-assigned. To this point, some sort of “notification stack” for each referenced object, would be helpful. With acknowledgement of our key attributes of timeliness and brevity, this stack should be:

...