User should be able to download submission filtered by either taskID or username

[manjitapandey]

Is your feature request related to a problem? Please describe.
As a part of requirement of Tokha data monitoring, they want to download submissions filtered by either TaskId or user's name. I think download submission filtered by taskId will be comparatively easier.

Describe the solution you'd like
User should be able to download submission filtered by either taskID or username.

Describe alternatives you've considered
project managers can download submission filtered by username is easier technically, then that would also be perfect.

Additional context
User should be able to download filtered data in geojson or csv format.

[spwoodcock]

We already added the filters for the submission table, so we could simply parse the table data as CSV and download?

Its a small bit of code to add a download button and the table parsing logic.

I think we should do this instead of modifying the backend to download filtered geojson etc (would require a UI rework plus backend logic)

[spwoodcock]

Backend is now compatible with geojson data filtering, with the same odata filters as with JSON and CSV downloads (linked PR).

This is now a frontend integration task, for the submission data table 👍

[NSUWAL123]

As described in the issue is it possible to download submissions filtered by username & task id? If yes then we shall add those too.
CC: @spwoodcock @Anuj-Gupta4

[manjitapandey]

The downloaded geojson doesn't contain any geopoint except the entity we are mapping.

[spwoodcock]

The downloaded geojson doesn't contain any geopoint except the entity we are mapping.

• New features
• Additional features

Both are not included, or just newly added features aren't? They should be under key new_feature 🤔

[manjitapandey]

I need to confirm on new and additional features but any geopoint questions on form like user's current geolocation is not there. I will confirm and update you shortly.

Update: The new feature is also not visible.
Additional feature field is there in geojson but its not visualised on geojson.io map. the format of coordinate is as below:
additional_geometry": "27.738043 85.325049 0.0 0.0;27.738239 85.324807 0.0 0.0;27.738372 85.324665 0.0 0.0;27.738492 85.324546 0.0 0.0;27.738642 85.324412 0.0 0.0;27.738767 85.324254 0.0 0.0;27.738825 85.324189 0.0 0.0;

[spwoodcock]

Thanks for the info! I checked it out.

1. There seems to be an issue loading the new_feature by intent in ODK Collect (it's not prefilling the form). Thanks for picking this up!
2. It looks like the additional_geometry collection is working as intended. The problem is the field is not converted from JavaRosa (ODK) geometry --> GeoJSON format, which makes sense. I'm not sure we can easily solve this, as the additional geometry fields can be named multiple things and could be numerous. We can possibly consider pulling out these fields in future, then adding them as additional geoms on the root FeatureCollection, but let's not focus on that for now (it's a data cleaning issue and we are focusing on the data collection for now)

This issue is solved & ready - the other issues above are separate 👍

[spwoodcock]

1. Injecting new_feature field by URL intent

This can't be solved with the current setup, as far as I can tell. The problem is loading the new entity via intent URL, which requires spaces in the URL, e.g. 27.710959067 85.300115063 0.0 0.0;

Instead we will have to solve via: #2146

2. Additional geometry conversion JavaRosa --> GeoJSON

• We should look for these fields then convert JavaRosa --> GeoJSON.
  • This is solvable by ensuring all additional entity geometry fields have _geom at the end (not perfect, but works for now).
  • Added in osm-fieldwork v0.20.1
• We already have the code for the conversion.
• No need to change the structure of the submission JSON or CSV.
• Simply do the conversion in place (it will be a nested field that can be extracted).
• Edit did this in the reference PR 👍

[spwoodcock]

This should be done & working on stage 👍

[manjitapandey]

I just tested it on dev server and here are my observations

1. downloading submission in Geojson format by filtering by Date range - functional
2. filtering by TaskId is functional
3. Downloadning submission in Geojson format by filtering by taskID - not functional

[spwoodcock]

You will notice that filtering by task_id doesn't work for any of the downloads, as it's not possible in ODK.

It's not possible to filter by custom properties, only system properties such as __system/submissionDate.

This is why I suggested from the start to separate out the submission table downloads from the geojson submission download.

• On the frontend we can parse the content of a table and easily download as csv or json.
• On the backend we have limited filtering options.

Closing this for now 👍

[manjitapandey]

This makes me clear. Thanks.