add task reassignment functionality

[colinfruit]

No description provided.

[elimisteve]

Glad you caught this. We should be able to replace the GET to /postgrest/tasks (see getTasksReq) with a POST to /postgrest/rpc/ , to call subtasks_recursive_flat (see

pursuance/db/sql/migration0003.sql

Line 3 in 820af87

CREATE FUNCTION subtasks_recursive_flat(parent_gid text, subtask_pursuance_id integer) RETURNS TABLE(gid text, pursuance_id integer, id integer, title text, title_enc text, deliverables text, deliverables_enc text, assigned_to text, assigned_to_pursuance_id integer, due_date timestamp WITH time zone, created timestamp WITH time zone, parent_task_gid text) AS $$

), which orders the tasks such that we'd only need to iterate over the resulting task array once rather than twice.

...but it might actually be faster to just do what you've done here -- iterate twice -- rather than do a more complex DB query to get things in the right order; I'm not sure.

[elimisteve]

Looking pretty great, but please make a couple tweaks as suggested 👍

[elimisteve]

For complicated security reasons we are trying to avoid inline styling. Could you replace this with something like className={"task-row-ctn " + (canDrop && isOver ? 'highlight-task') : ''} ?

[colinfruit]

np

[elimisteve]

This is the most readable way I've seen to do this; sweet 👍 .

[elimisteve]

So that what redux shows right after the drag-and-drop occurs is the same as what the user will see after a refresh, technically the subtask_gids should be ordered by created and then by id. Think it'd be too slow to do that sorting here?

[colinfruit]

Sure :-)

[elimisteve]

Hell yeah! 🎉

[elimisteve]

@colinfruit Adding console.log("canDrop called at", new Date()) here shows that canDrop is called hundreds of times even if the div that the user's mouse is hovering over doesn't change.

Think there's some way to make this more efficient? It works great but it's very slow and I'm trying to figure out why.

[elimisteve]

@colinfruit Is this the right comparison? We just want to return 0 immediately if they're the same, yes?

[colinfruit]

I thought we were sorting by created then by id per the earlier comment. Did I misunderstand?

[elimisteve]

@colinfruit Ooh I see, no you're right. Can you rename t1 and t2 to gid1 and gid2 please?

[elimisteve]

I lost track of what was a task v. a date v. a gid, which is why I was confused.

[colinfruit]

👍 will rename

[elimisteve]

@colinfruit Efficiency idea:

const t1 = newMap[gid1];
const t2 = newMap[gid2];
t1.created_parsed = t1.created_parsed || new Date(t1.created);
t2.created_parsed = t2.created_parsed || new Date(t2.created);

so that there's no need to parse any task's created timestamp twice.

[colinfruit]

nice, created_parsed a field? Or is it on the todo list?

[elimisteve]

It's a field that we'd be creating just to make this more efficient.

[elimisteve]

The point is that, the second time that one of these tasks's created timestamp goes to be parsed, it'll reuse created_parsed rather than parsing the created field again and creating a Date object out of it.