Inconsistency in user facing taskID and taskid of downloaded geojson task file

[manjitapandey]

Describe the bug
Reported by KU field activity, When I downloaded the task boundary from the FMTM website, I got a geojson file.
The downloaded geojson file has one column in the attribute table named tasks_id. But the task id that is provided here doesn’t seem to match the actual task id seen on the user end.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'project details page'
2. Click on 'download tasks'
3. upload the geojson file in QGIS and view its taskID
4. See error

Expected behavior
The taskID should be consistent everywhere.

Screenshots

Additional context
They needed the task id during analyzing the result, but we couldn’t find the way to get that.

[Sujanadh]

So those task_ids are the actual task ids, which are the primary keys of tasks. We use task index project-wise, starting from 1 in our management frontend of fmtm. It is a small fix, using project task_index instead of the actual id of the task.

[spwoodcock]

A thought

Perhaps at some point we refactor and write migrations to update the task id to actually be the task index everywhere.

Then project id and task id can be a composite key together to ensure uniqueness.

We even have rest endpoints in structure
/project/projectid/task/taskid
so this would make more sense.

A task is only ever referenced in relation to a project.

A second thought 😂

• Just after writing this I considered electric SQL.
• Before attempting this we should make certain that a composite primary key would definitely work with electric / PGLite, as I'm not 100% certain.
• Probably fine, but needs to be checked when we get to this.

[spwoodcock]

Saying all that, for now we should just use the task index in this endpoint response, as Sujan says 👍