Migrate /exports to nested assets endpoint

[joshuaberetta]

List of export tasks endpoints

Lists the export tasks accessible to requesting user, for anonymous access
nothing is returned.

Required permissions: view_submissions (View submissions)

GET /api/v2/assets/{asset_uid}/exports/

Examples

curl -X GET https://[kpi]/api/v2/assets/aSAvYreNzVEkrWg5Gdcvg/exports/

List can be filtered with the query parser
Query searches within uid by default if no field is provided in q.

curl -X GET https://[kpi]/api/v2/assets/aSAvYreNzVEkrWg5Gdcvg/exports/?q=zVEkrWg5Gd

Examples:

Exports matching uids

curl -X GET https://[kpi]/api/v2/assets/aSAvYreNzVEkrWg5Gdcvg/exports/?q=uid__in:ehZUwRctkhp9QfJgvEWGg OR uid__in:ehZUwRctkhp9QfJgvDnjud

CRUD

uid - is the unique identifier of a specific export task

Creates an export task

POST /api/v2/assets/{asset_uid}/exports/

Example

curl -X POST https://[kpi]/api/v2/assets/aSAvYreNzVEkrWg5Gdcvg/exports/

Payload

{
    "fields_from_all_versions": "true",
    "group_sep": "/",
    "hierarchy_in_labels": "true",
    "lang": "English (en)",
    "multiple_select": "both",
    "type": "geojson",
    "fields": ["field_1", "field_2"],
    "flatten": "true"
}

where:

• "fields_from_all_versions" (required) is a boolean to specify whether fields from all form versions will be included in the export.
• "group_sep" (required) is a value used to separate the names in a hierarchy of groups. Valid inputs include:
  • Non-empty value
• "hierarchy_in_labels" (required) is a boolean to specify whether the group hierarchy will be displayed in labels
• "multiple_select" (required) is a value to specify the display of multiple_select-type responses. Valid inputs include:
  • "both",
  • "summary", or
  • "details"
• "type" (required) specifies the export format. Valid export formats include:
  • "csv",
  • "geojson",
  • "spss_labels", or
  • "xls"
• "fields" (optional) is an array of column names to be included in the export (including their group hierarchy). Valid inputs include:
  • An array containing any string value that matches the XML column name
  • An empty array which will result in all columns being included
  • If "fields" is not included in the "export_settings", all columns will be included in the export
• "flatten" (optional) is a boolean value and only relevant when exporting to "geojson" format.

Retrieves current export task

GET /api/v2/assets/{asset_uid}/exports/{uid}/

Example

curl -X GET https://[kpi]/api/v2/assets/aSAvYreNzVEkrWg5Gdcvg/exports/ehZUwRctkop9QfJgvDmkdh/

Deletes current export task

DELETE /api/v2/assets/{asset_uid}/exports/{uid}/

Example

curl -X DELETE https://[kpi]/api/v2/assets/aSAvYreNzVEkrWg5Gdcvg/exports/ehZUwRctkop9QfJgvDmkdh/

Description

Support the new SearchFilter and object ordering in the exports API by migrating and updating the old /exports endpoint to /api/v2/assets/{asset_uid}/exports.

Related issues

closes #3010

[noliveleger]

🤔

I an wondering why only view_submissions is needed to delete objects.
Do we want users to be able to delete exports created by others.
Let's say Olivier is owner of Project A, gives view_submissions permission to Joshua.
Olivier creates some exports. Should Joshua be allowed to delete them? Not sure. Maybe we need more granularity at this point (e.g.: view_exports, add_exports, change_exports, delete_exports).
Until then, what about requiring change_asset and view_submissions to create / delete exports?

@tinok , @jnm . What do you think? I was wrong, please read below

[joshuaberetta]

That's a good point 👍 I'd be in favour of my granular permissions, however I guess the more granular permissions we end up adding the greater chance we have of getting it wrong (I can speak for myself here at least).

@noliveleger, I assume you mean: DELETE requires change_asset and POST requires view_submissions?

[noliveleger]

@joshuaberetta, I said something wrong.
I looked at the v1 code and exports are filtered by user. The user can see only their exports. So it's perfectly fine to still use view_submissions for POST, DELETE.

Having that said, I do not see this condition in the queryset of the v2 viewset.
Does it mean, every user can see every other user's exports in v2? We should keep the same behaviour.

[joshuaberetta]

Ah yes... thanks for picking that up. In my mind it made sense that the export objects themselves were also shared, but I've changed it to have the same behaviour as v1 👍