Tasks Extension

[kronosapiens]

Closes #733
Closes #79 (by setting the ExpenditureClaimDelay)

Tasks

Transparently re-implement Tasks in terms of Expenditures. Test suite is duplicated and runs parallel to the in-Colony task tests, as we are supporting both currently.

Note that only non-redundant events (i.e. those which lack parallels in the underlying Expenditure) are preserved. Redundant events (such as finalization, setting payouts, etc) should be inferred by listening for events on the underlying Expenditure.

Design

• "Secure" vs. "Managed" is represented via a secure boolean on the Task struct (and another argument to makeTask). When secure == true, tasks follow the current multisig logic for changing properties. When secure == false, the task manager can edit task properties directly. Managed tasks cannot set an evaluator.

• "Managed" tasks have no evaluator, and by extension no work submission nor rate-and-reveal flow. The dueDate can be set but has no effects: the manager can "finalize" the task at any time (through finalizeManagedTask), which simply finalizes the underlying expenditure (allowing payments to be claimed with an implicit rating of 2). The expectation is that the submission and evaluation of work occurs off-chain in a lightweight, trusted manner.

• The manager can convert a task from "Managed" to "Secure" at any time. To convert from "Secure" to "Managed", a two-way multisig with the manager and worker is required. Converting from "Secure" to "Managed" automatically unassigns the evaluator.

Notes

• In order to keep the Tasks.sol contract under the ethereum bytecode limit, numerous bytecode optimizations were made. Most significantly, most (if not all) require messages were reduced to 32 bytes (i.e. 32 characters). Secondly, most modifier logic was extracted into internal boolean-valued helper functions. This article provides more information how how these practices reduce a contract's bytecode.

• Multisig task changes have been restricted to only "active" tasks, as this seems more in line with the semantics of the task (previously, tasks which were "complete" but not yet "finalized" could have multisig task changes. Now, tasks must not yet be completed.

• Modifier usage has been made slightly more consistent (with the taskExists modifier being used more regularly).

[collinvine]

@kronosapiens is this still being worked on, and is it still planned for LWSS? I'm thinking that this no longer a relevant feature. Thoughts?

[kronosapiens]

@collinvine Alex and I discussed this today during sprint planning -- we can pick it up, but wanted to make sure it was still relevant. You're saying it's not? What's the reasoning?

[collinvine]

TBD, but plan is to simplify the task feature. Meaning, natively supporting expenditures & also support the 1tx payment via the extension manager. In the UI, the "task" feature would be drastically reduced. cc @jakzilla

[kronosapiens]

@collinvine Ok, works for us. The nice thing is we can toss this in really whenever we want. The only consideration is when/how we deprecate the built-in task functionality, since the longer we leave it lying around the harder it will be to remove it later (that said, I doubt it's getting a lot of use currently).