OpenConceptLab/ocl_issues#2477 | repo external exports

[snyaggarwal]

Linked Issue

Refs OpenConceptLab/ocl_issues#2477

OCL Web2 PR: OpenConceptLab/oclweb2#36

[filiperochalopes]

Was the download audit intentionally left out?

Do we currently have any way to audit which users downloaded files through AWS? This audit trail is needed for some decisions @askanter needs to make regarding which versions should be kept and which users are still using those versions.

Also, locally I’ve had some issues where the 302 redirect did not always happen. I’m currently using a local patch to cover redirect validation to the signed bucket path.

It would be useful to add an integration test ensuring that the download GET works correctly and results in a 302 redirect.

[snyaggarwal]

@filiperochalopes
ocl-analytics tracks all requests.
GET /api-transactions/?operation_type=external_export&request_method=GET&ocl_resource=/orgs/CIEL/sources/CIEL/

Raised PR in analytics for external_export operation -- https://github.com/OpenConceptLab/ocl-analytics-api/pull/75

[snyaggarwal]

@filiperochalopes already added integration test for redirect behaviour

[filiperochalopes]

@filiperochalopes ocl-analytics tracks all requests. GET /api-transactions/?operation_type=external_export&request_method=GET&ocl_resource=/orgs/CIEL/sources/CIEL/

Raised PR in analytics for external_export operation -- https://github.com/OpenConceptLab/ocl-analytics-api/pull/75

I might not have access to this repo

[paynejd]

Reviewed for code quality + intent against #2477. The core design is clean — RepoExternalExport as a generic, repo-shared model attached via GenericRelation on ConceptContainerModel mirrors the existing ConceptContainerExportMixin conventions well, path-traversal is handled with a test, and coverage is solid across sources + collections. A few inline suggestions below; two non-blocking notes:

Auditable downloads (AC): confirmed the intended mechanism is the analytics request-logging pipeline — every download is an authenticated GET that lands in api_transactions — which is what we discussed and is acceptable. @snyaggarwal please verify a download is actually queryable from the analytics service with sufficient metadata (who / which repo+version / which export key). The GET returns a 302 to a signed URL and there's no test asserting the event is captured, so a quick confirmation that the transaction log carries enough to audit a download would close this out.

Non-blocking:

• N+1: get_external_exports runs one query per version; on the version list endpoint with includeExternalExports=true (which the UI sends) that's a query per row. A prefetch_related('external_exports') on that path removes it.
• Atomicity: upload/delete touch S3 then the DB with no rollback, so a partial failure can orphan an S3 object or leave a dangling row. Fine for a low-frequency admin action — worth a follow-up only if it ever runs unattended.