imag/lib/domain/libimagtodo
Matthias Beyer cb4d5367e4 Rewrite all usages of ModuleEntryPath
Because the code was so complex before, we had to create an object and
then cast that object into a `StoreId` rather than just creating a
`StoreId` object right away.

With this patch, we're using the code-generation approach to generate a
function that creates a `StoreId` object based on the name of the
current module. That's way easier and error handling was also improved
by the switch to the new implementation.

The patch also includes a rewrite of all usages of ModuleEntryPath and
changes them to `module_path::new_id()` calls.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
2019-04-13 22:39:39 +02:00
..
src Rewrite all usages of ModuleEntryPath 2019-04-13 22:39:39 +02:00
Cargo.toml Update version strings 2018-11-10 11:56:37 +01:00
README.md Fix broken README symlinks 2017-08-27 15:13:25 +02:00

README.md

libimagtodo

The library for the todo module which provides functionality to implement/implements a todomanager in imag.

Implementation details

One todo entry is stored as one imag entry. The ID of the imag entry is generated by appending a unique ID (UUID) to "todo/".

The unique ID identifies the todo entry.

Stored data

A todo entry stores the following information:

  • The (UU)ID of the todo entry
  • A status of the todo entry. Valid values are: "deleted", "done", "pending"
  • A "scheduled" date/datetime, can also yield an iterator
  • An optional "hidden" value, which specifies a date in the future where this todo entry should show up. Relative (eg. "-5days"), to the "scheduled" date/datetime
  • An optional "due" date/datetime, relative to the "scheduled" time
  • A list of dependencies of the entry
  • A "importance"-level, config file defined (strings in an array, index used for ranking them)
  • User defined value (a map of key-value string pairs)

The description of the todo entry is stored as plain text.

Data not stored

Some data is explicitely not stored by the library because there are other libraries fullfilling that purpose. These are:

  • Tags, which can be done with libimagentrytag
  • Category, which can be done with libimagentrycategory
  • Project belonging, which can be done with libimagentrylink (by linking to a project file - note that "project" is a domain not yet implemented by imag)
  • Annotations, which can be stored with libimagentryannotation

Header format

The header partial for libimagtodo is as follows:

[todo]
uuid = "string"
status = "string"
scheduled = "<kairos time spec>"
hidden = "<kairos time func (optional)>"
due = "<kairos time func (optional)>"
depends = [ "list of uuids" ]
importance = "string"
uda = {}

Functionality

The provided functionality of this library includes, but is not limited to:

  • Creating new todo entries in the store
  • Deleting todo entries from the store
  • get/retrieving todo entries from the store
  • Turning an entry into a todo entry
  • Getting todo details from an entry
    • scheduled, due, waiting date/datetime
    • priority
    • UUID
    • status
    • An iterator over all dependend todo entries (as StoreIdIterator)
  • Calculating a "urgency" of a todo entry from a formula weighted by configurable factors

Dependencies between tasks

Dependencies between todo entries are created by putting the UUID of a dependent todo entry into the todo.depends header. This way, a unidirectional link is created. A link (as in libimagentrylink) is also created, but this can be turned off explicitely.

As libimagentrylink links are bidirectional, they do not suffice for todo entry dependency creation.

As todo entries are stored with the Store IDs "todo/", creating a StoreId from a UUID is trivial.