Add attachment_data_id to file attachments #2994
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, the properties in the file attachment properties are
insufficient to make a request to asset manager from the server to fetch
the asset.
The API client wants to be called like this:
GdsApi.asset_manager.media(attachment_data_id, filename)
... but we don't have an attachment_data_id, we only have url /
preview_url (which include the id we want), and a bunch of other fields
which don't. We shouldn't have to parse URLs to find IDs.
We get away with this because in most cases where we're using file
assets, we redirect the user to the full asset URL (so we don't need to
fetch it on the server side).
The one example I'm aware of where we do need to request assets on the
server side is CSV previews, and we've ended up with a pretty wild
workaround in that case. Specifically, we route some requests to the
assets domains (e.g. assets.publishing.service.gov.uk) to frontend.
This way, the preview_url ends up being served by frontend itself. This
means the URL gets parsed by Rails' routing logic, and we end up with
the ID in a param which we can use to call asset manager: see
https://github.com/alphagov/frontend/blob/8b075a3e26d775ad97b6b473ddaa22386e07cad2/app/controllers/csv_preview_controller.rb#L27
I think if we had access to the asset manager id (attachment_data_id)
earlier on, we could probably avoid the need to put preview_url in the
content item at all, and just let frontend load the asset and preview
it.
My primary motivation here isn't CSV previews though, it's landing pages
for the programme for government project. We want to be able to load CSV
data and render it into a line chart. We have basically the exact same
issue there - we can't request the asset using the API client without
parsing the asset's URL.
We'll need a corresponding commit in Whitehall (and maybe other
publishing apps, if they have attachments?) to start sending this new
field through to the API. It's optional, so this shouldn't break
anything in the meantime.
richardTowers
added a commit
to alphagov/whitehall
that referenced
this pull request
Nov 21, 2024
This needs to follow on from alphagov/publishing-api#2994 As described there, the lack of attachment_data_id in the data for file asset attachments in content store makes it hard to request the attachments on the server side. Instead, we have to redirect users to the assets, which has led to ugly workarounds like CSV previews being rendered by frontend but served on assets.publishing.service.gov.uk. Adding attachment_data_id should allow the frontends to request attachments directly, using the API client: GdsApi.asset_manager.media(attachment_data_id, filename) This should make it much more convenient to preview assets, or use them for other rendering purposes (e.g. showing a CSV as a line graph).
richardTowers
added a commit
to alphagov/whitehall
that referenced
this pull request
Nov 27, 2024
This needs to follow on from alphagov/publishing-api#2994 As described there, the lack of attachment_data_id in the data for file asset attachments in content store makes it hard to request the attachments on the server side. Instead, we have to redirect users to the assets, which has led to ugly workarounds like CSV previews being rendered by frontend but served on assets.publishing.service.gov.uk. Adding attachment_data_id should allow the frontends to request attachments directly, using the API client: GdsApi.asset_manager.media(attachment_data_id, filename) This should make it much more convenient to preview assets, or use them for other rendering purposes (e.g. showing a CSV as a line graph).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the properties in the file attachment properties are insufficient to make a request to asset manager from the server to fetch the asset.
The API client wants to be called like this:
... but we don't have an attachment_data_id, we only have url / preview_url (which include the id we want), and a bunch of other fields which don't. We shouldn't have to parse URLs to find IDs.
We get away with this because in most cases where we're using file assets, we redirect the user to the full asset URL (so we don't need to fetch it on the server side).
The one example I'm aware of where we do need to request assets on the server side is CSV previews, and we've ended up with a pretty wild workaround in that case. Specifically, we route some requests to the assets domains (e.g. assets.publishing.service.gov.uk) to frontend. This way, the preview_url ends up being served by frontend itself. This means the URL gets parsed by Rails' routing logic, and we end up with the ID in a param which we can use to call asset manager: see https://github.com/alphagov/frontend/blob/8b075a3e26d775ad97b6b473ddaa22386e07cad2/app/controllers/csv_preview_controller.rb#L27
I think if we had access to the asset manager id (attachment_data_id) earlier on, we could probably avoid the need to put preview_url in the content item at all, and just let frontend load the asset and preview it.
My primary motivation here isn't CSV previews though, it's landing pages for the programme for government project. We want to be able to load CSV data and render it into a line chart. We have basically the exact same issue there - we can't request the asset using the API client without parsing the asset's URL.
We'll need a corresponding commit in Whitehall (and maybe other publishing apps, if they have attachments?) to start sending this new field through to the API. It's optional, so this shouldn't break anything in the meantime.