Skip to content

Pick up replacement file's content_type before regenerating filename - #9261

Open
c-tonneslan wants to merge 1 commit into
mysociety:developfrom
c-tonneslan:fix/replaced-filename-double-extension
Open

Pick up replacement file's content_type before regenerating filename#9261
c-tonneslan wants to merge 1 commit into
mysociety:developfrom
c-tonneslan:fix/replaced-filename-double-extension

Conversation

@c-tonneslan

Copy link
Copy Markdown

Closes #9016.

@garethrees flagged that replacing a .docx attachment with a .tsv was ending up as .tsv.docx. FoiAttachment#filename= reads the current content_type to decide whether to append an extension, but at the point handle_replacements calls it, content_type is still the original .docx mime, so the new .tsv filename gets .docx tacked on.

Sync content_type from the replacement UploadedFile before the self.filename = ... line runs, so filename= sees the new mime and doesn't try to append the old extension.

The existing #replace! 'replacing with file' spec already tracked this as a FIXME pointing at #9016 (expecting redacted.png.txt); flipped that to assert the correct redacted.png and added a small assertion that the new content_type is the replacement's.

Replacing a .docx with a .tsv was producing filename .tsv.docx because
FoiAttachment#filename= reads the current content_type to figure out
which extension to append, and the content_type was still the
original. Sync the field from the uploaded replacement file before
running filename= so the new extension wins.

Updated the existing #replace! 'replaces with file' spec (which was
tracking this as a FIXME against mysociety#9016).

Closes mysociety#9016

Signed-off-by: Charlie Tonneslan <cst0520@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FoiAttachment#replaced_filename inherits original attachment extension

1 participant