Last active
August 11, 2023 00:09
-
-
Save busla/1789058d564704d5cabde8178094da26 to your computer and use it in GitHub Desktop.
reproduce that completed_at is not writable through Asana task API
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| #!/bin/bash | |
| : <<'SHOWSTOPPER_DOC' | |
| --------------------------------------------------------- | |
| Issue: Inability to Write to the 'completed_at' Field in Asana | |
| --------------------------------------------------------- | |
| Migrating to a new project management system like Asana is a significant undertaking, which we undertake with the goal of | |
| improving our workflows and increasing productivity. One of the pivotal aspects of such a migration is ensuring the | |
| continuity and integrity of our historical data. | |
| Our current project management system tracks the lifecycle of tasks diligently, and this data is crucial. | |
| It doesn't just represent a record of what has been done, but it's an analytical tool. We utilize this historical | |
| data to generate dashboards which provide insights into project timelines, employee productivity, | |
| task turnaround times, and more. | |
| The 'completed_at' field is instrumental in these analyses. By knowing precisely when a task was marked complete, | |
| we can determine how long it took, juxtapose it with other tasks, or even analyze the productivity trends over time. | |
| However, with the present limitation in Asana where the 'completed_at' field is not writable, we hit a roadblock. | |
| This means that, post-migration, our dashboards will lose the granularity and accuracy they currently possess. | |
| In essence, we won't be able to represent the true lifecycle of a task before and after the migration, | |
| leading to distorted views and incorrect insights. | |
| Given this constraint, we're compelled to question the viability of the migration itself. If the migration disrupts our | |
| analytical capabilities and impedes our insights into our projects, is the migration worth the associated costs and efforts? | |
| It's crucial for Asana to understand that this isn't just about transferring data, but about ensuring that the | |
| new environment can provide the same (if not better) value than the old. | |
| For us to consider this migration seriously, it's imperative that we can carry our historical data with complete fidelity, | |
| including being able to write to fields like 'completed_at'. | |
| --------------------------------------------------------- | |
| How to run | |
| --------------------------------------------------------- | |
| export ASANA_TOKEN=foobar | |
| export ASANA_PROJECT_ID=foo | |
| export ASANA_WORKSPACE_ID=bar | |
| SCRIPT_NAME=asana-completed-at.sh | |
| curl -Ls "https://gist.githubusercontent.com/busla/1789058d564704d5cabde8178094da26/raw/e406b2f8ad788e68712dd5fe4be21ddad175833b/$SCRIPT_NAME" -o $SCRIPT_NAME | |
| chmod +x $SCRIPT_NAME | |
| ./$SCRIPT_NAME | |
| --------------------------------------------------------- | |
| Response | |
| --------------------------------------------------------- | |
| { | |
| "errors": [ | |
| { | |
| "message": "completed_at: Cannot write this property", | |
| "help": "For more information on API status codes and how to handle them, read the docs on errors: https://developers.asana.com/docs/errors" | |
| } | |
| ] | |
| } | |
| --------------------------------------------------------- | |
| SHOWSTOPPER_DOC | |
| set -eoux pipefail | |
| function generate_random_string() { | |
| tr -dc 'a-zA-Z0-9' < /dev/urandom | fold -w 8 | head -n 1 | |
| } | |
| # Common task data with random title | |
| TASK_DATA=$(cat << EOF | |
| { | |
| "data": { | |
| "name": "$(generate_random_string)", | |
| "resource_subtype": "default_task", | |
| "completed": false, | |
| "html_notes": "<body>Mittens <em>really</em> likes the stuff from Humboldt.</body>", | |
| "notes": "Mittens really likes the stuff from Humboldt." | |
| } | |
| } | |
| EOF | |
| ) | |
| function http() { | |
| local endpoint=$1 | |
| local data=$2 | |
| local method=${3:-POST} | |
| curl -s -X "$method" \ | |
| -H 'accept: application/json' \ | |
| -H "authorization: Bearer ${ASANA_TOKEN}" \ | |
| -H 'content-type: application/json' \ | |
| -d "$data" \ | |
| "https://app.asana.com/api/1.0/${endpoint}" | |
| } | |
| function update_task() { | |
| local task_id=$1 | |
| data=$(echo "$TASK_DATA" | jq --arg tid "$task_id" ' | |
| .data.completed_at = "2023-08-10T02:06:58.147Z" | | |
| .data.completed = true | |
| ') | |
| response=$(http "tasks/$task_id" "$data" "PUT") | |
| echo "$response" 1>&2 # print response error | |
| echo "$response" | |
| } | |
| function create_task() { | |
| local workspace_id=$1 project_id=$2 data | |
| data=$(echo "$TASK_DATA" | jq --arg wid "$workspace_id" --arg pid "$project_id" ' | |
| .data.workspace = $wid | | |
| .data.projects = [$pid] | |
| ') | |
| response=$(http "tasks" "$data") | |
| echo "$response" 1>&2 # print response error | |
| echo "$response" | |
| } | |
| task_id=$(create_task "$ASANA_WORKSPACE_ID" "$ASANA_PROJECT_ID" | jq -r '.data.gid') | |
| update_task "$task_id" | jq |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment