Delete associated files when file attachments get completely deleted.
Review Request #13142 — Created July 13, 2023 and submitted
Currently, when file attachments get completely deleted from the database we
keep their associated files lying around. There's no good reason to do this,
when the file attachment gets deleted we have no way of accessing these files
anymore.This change deletes associated files from the filesystem when file
attachments get deleted. Any files created by theMimetypeHandler
will be
deleted, and then the main file of the file attachment will be deleted.
- Tested deleting draft
.png
file attachments that have thumbnail files,
saw that they were deleted. - Tested deleting draft
.txt
files. - Tested deleting published files, saw that their files weren't deleted.
- Tested deleting a draft revision of a file attachment that has
been published before (has a history), saw that only the files for
the draft revision were deleted.
Summary | ID |
---|---|
9807aee29beba5ed20f5297ddf9336733c665959 |
Description | From | Last Updated |
---|---|---|
no newline at end of file Column: 46 Error code: W292 |
reviewbot | |
Can you add -> None so this will opt into type hints? You'll also need an annotations future import here … |
chipx86 | |
Since we don't use this outside of typing, you should import typing.TYPE_CHECKING and then do this import in an if … |
chipx86 | |
I think we should override FileAttachment.delete to call delete_associated_files before performing the main deletion functionality. We wouldn't need to worry … |
chipx86 |
- Description:
-
~ Delete associated files when draft file attachments get deleted.
~ Currently, when draft file attachments get deleted we keep their associated
+ files lying around. There's no good reason to do this, and when the file + attachment gets deleted we have no way of accessing these files anymore. And + since the file attachments are drafts that are being deleted before ever + being published, we don't need to keep their files for any reason. + + This change deletes associated files from the filesystem when draft file
+ attachments get deleted. Any files created by the MimetypeHandler
will be+ deleted, and then the main file of the file attachment will be deleted. - Commits:
-
Summary ID 55196f32e2f80261f7814f137bbc8d172d32be63 bb8fb6af50b092cbf354c021dd292c84a13f644a
Checks run (2 succeeded)
- Change Summary:
-
- Moved to RB6.
- Testing Done:
-
~ - Tested deleting
.png
file attachments that have thumbnail files.
~ - Tested deleting
.txt
files.
~ - Tested deleting published files.
~ - Tested deleting a draft revision of a file attachment that has
been published before (has a history).
~ - Tested deleting draft
.png
file attachments that have thumbnail files,
saw that they were deleted.
~ - Tested deleting draft
.txt
files.
~ - Tested deleting published files, saw that their files weren't deleted.
~ - Tested deleting a draft revision of a file attachment that has
been published before (has a history), saw that only the files for
the draft revision were deleted.
- Tested deleting
- Commits:
-
Summary ID bb8fb6af50b092cbf354c021dd292c84a13f644a fd1283387df474f5af9bd90bf3c7197bd0983242 - Branch:
-
release-5.0.xrelease-6.x
Checks run (2 succeeded)
-
-
Can you add
-> None
so this will opt into type hints?You'll also need an
annotations
future import here and in other new files. -
Since we don't use this outside of typing, you should import
typing.TYPE_CHECKING
and then do this import in anif TYPE_CHECKING:
block (which is basically treated as a 4th import group). -
I think we should override
FileAttachment.delete
to calldelete_associated_files
before performing the main deletion functionality.We wouldn't need to worry about the order of signal handling or anything in that case, and can keep all deletion logic in one place.
- Summary:
-
Delete associated files when draft file attachments get deleted.Delete associated files when file attachments get completely deleted.
- Description:
-
~ Currently, when draft file attachments get deleted we keep their associated
~ files lying around. There's no good reason to do this, and when the file ~ attachment gets deleted we have no way of accessing these files anymore. And ~ since the file attachments are drafts that are being deleted before ever ~ Currently, when file attachments get completely deleted from the database we
~ keep their associated files lying around. There's no good reason to do this, ~ when the file attachment gets deleted we have no way of accessing these files ~ anymore. - being published, we don't need to keep their files for any reason. ~ This change deletes associated files from the filesystem when draft file
~ This change deletes associated files from the filesystem when file
attachments get deleted. Any files created by the MimetypeHandler
will bedeleted, and then the main file of the file attachment will be deleted. - Commits:
-
Summary ID fd1283387df474f5af9bd90bf3c7197bd0983242 9807aee29beba5ed20f5297ddf9336733c665959