icon ${title}

### Tasks In a group setting, people are constantly asked to provide or review information. In addition to tracking the data and changes, tasks are supported to track progress for collaboration. Examples could be asking for review/input for a budget, or adding travel to a shared travel calendar. Instead of tracking tasks and progress separately from the data or performing the tracking in email, this effectively combines doing the work and tracking the work, so it actually occurs. Tasks are connected to discussions, hence a task is simply another discussion item, with additional characteristics. Completing tasks are similarly another discussion item. Hence tasks and changes to tasks also have the same key - a dataset id and the change tag when the change is posted. #### Client-side Requirements - Get the list of open tasks for a dataset - Show for each task, who has completed the task and for whom it is pending - Ability to see when each user completed a task, and the associated changes made - Mark a task as completed - Add additional users to the task ##### Task Model This is how the task is stored on the client-side as a cache. It can be generated from the various changes that are posted. { taskId: "{dataset id}/{change tag}", requestor: "jane@abc.com", title: "", dueDate: "", datasetId: "", initialChangeTag: "", assignees: [{email: "joe@abc.com", status: {0|100}, lastChangeTag: ""}, ...] } #### Interaction Model This is a sample interaction involving 2 people, Jane who is asking for data input, and Joe who has to perform the work. 1. **Jane assigns work** >POST /api/v1/datasets/{dataset id}/{b-{branch tag}} Call with `assignTask` node: { comments: "", recs: [ {f1: "", f2: 123, ...}, {} ], assignTask: { dueDate: "", addOwners: [{email: "joe@abc.com"}, ...]} } 2. **Joe receives the task request** >GET /api/v1/datasets/{dataset id}/{b-{branch tag}} Call should receive a message with the `assignTask` node. On receipt, the task should be added to the tasks table with the key {dataset id}/{change tag}. { fields: [{fnum: 1, name: "Field1", title: "Field 1", type: "string"}, ...], recs: [ {f1: "", f2: 123, ...}, {} ], msgs: [ {tag: "", date: "", comments: "", by: "user1@acme.com", dataChange: { addedRecs: [], updatedRecs: [], deletedRecs: []}, assignTask: {dueDate: "", addOwners: [{email: "joe@abc.com"}, ..]} }, .. ] } 3. **Joe completes task and posts changes** >POST /api/v1/datasets/{dataset id}/{b-{branch tag}} Call should include a `taskChange` node along with the records that are being changed. After successfully sending, the task should be marked as complete on the client side for this user. { comments: "", taskChange: { taskId: "{dataset id}/{change tag}", status: 100 } recs: [ {f1: "", f2: 123, ...}, {} ] } 4. **Jane gets updates on the task** >GET /api/v1/datasets/{dataset id}/{b-{branch tag}} The normal dataset update should include the messages that contain task updates. By reading the messages and applying them to the tasks, the tasks can be brought up to their current state. The task model as referenced above is constructed by processing the taskChange nodes in each message. { fields: [{fnum: 1, name: "Field1", title: "Field 1", type: "string"}, ...], recs: [ {f1: "", f2: 123, ...}, {} ], msgs: [ {tag: "", date: "", comments: "", by: "joe@abc.com", dataChange: { addedRecs: [], updatedRecs: [], deletedRecs: []}, taskChange: { taskId: "", status: 100} // the by for the msg is used to establish who made the task change }, .. ] } 5. **Jane adds Mark to the task** >POST /api/v1/datasets/{dataset id}/{b-{branch tag}} Call with `assignTask` node, referencing an existing task with its task id and a list of owners to add/remove: { comments: "", recs: [ {f1: "", f2: 123, ...}, {} ], assignTask: { taskId: "", addOwners: [{email: "mark@abc.com"}, ...], removeOwners: []} }