Projekt

Allgemein

Profil

Aktionen

GX-Feature #69663

geschlossen

Refactoring email attachment storage

Von Daniel Wu vor etwa 2 Jahren hinzugefügt. Vor etwa 2 Jahren aktualisiert.

Status:
Erledigt
Priorität:
Dringend
Zugewiesen an:
Mirko Janssen
Kategorie:
Core
Zielversion:
% erledigt:

0%

Geschätzter Aufwand:
Steps to reproduce:
Betroffene Versionen:
Unbestimmt
Release Notes Langtext:

Jetzt wird der E-Mail-Anhang nur dann als neue Datei gespeichert, wenn sein Inhalt seit der letzten Erstellung geändert wurde.


Beschreibung

Currently email attachments for every email are stored separately, even if they're completely the same. That leads to some massive storage problems especially when it comes to backups. Email attachments are mainly the PDFs attached to the order confirmation (privacy, terms and conditions and withdrawal). In most cases these files very rarely changed. So the storage of those attachments should be refactored to avoid that identical files pile up.

Solution:

  • Email attachments from contents should only be stored as a new file, whenever the content changed since the last creation of the attachment:
    • To achieve that attachments will be stored with a hash in its file name which is checked and updated whenever it is read.
  • If the API or the Admin GUI is used to send an email, the attachment file is saved to the email attachment directory with the file hash in its name. That way it is replaced and not stored multiple times, when the same file is sent.

Actual:

  • An email attachment is created everytime an email is sent, even if its contents are the same for all the attachments. You can check it by placing two or more orders. Every order placed will create a new file -> "/uploads/attachments" folder.

Expected:

  • Everytime an email is sent with an order, a new attachment file is created ONLY if its contents are different from the already exising attachment file.

Technical information:

  • To know whether a new attachment needs to be created or not, we are comparing the contents of the file using the functions:
  • When reading the attachments to be sent, we update the hashes if its contents or the file hash is different from the existing file attachment.
  • For the content files, we are using the "gx_lang_configurations" table to save the content file hash:
    • email_attachment/withdrawal_information_content_hash
    • email_attachment/withdrawal_form_content_hash
    • email_attachment/terms_and_conditions_content_hash
    • email_attachment/privacy_notice_content_hash
  • When the Withdrawal doesn't have a form file "gx_configurations -> gm_configurations/WITHDRAWAL_FORM_FILE", we are using the latest installed version's timestamp to use as the hash.

Notes:

  • For each file added or content changed, a new file should be created in the "uploads/attachments" folder.
  • First of all check your "uploads/attachments" folder. Empty the folder or keep note of the already exisintg files.
  • Do not forget to add the files to all the available languages How to test:
  • Place an order and check the "uploads/attachments" folder.
  • Go to Admin > Content > Content Manger and edit:
    • General Terms & Conditions
      • Add a "download_file", place an order and check the "uploads/attachments" folder.
      • Replace the original download_file, located in the "media/content" folder, with a different file but it must have the same name as the original file.
    • Right of Withdrawal / Model Withdrawal Form
      • Add a "download_file", place an order and check the "uploads/attachments" folder.
      • Add a "Model withdrawal form", place an order and check the "uploads/attachments" folder.
    • Remove all the files previously added, place an order and check the "uploads/attachments" folder. All the changed files should be created again.
  • Attention: The folowing tests always create a new file, the objective is just to check if the functionality is still working.
  • Call the APIv2:
  • Go to Admin > Customers > Emails
    • Click on the "+ New Email" button and send an email with an attachment.

Aktionen #2

Von Daniel Wu vor etwa 2 Jahren aktualisiert

Aktionen #4

Von Alexandre Ataides vor etwa 2 Jahren aktualisiert

Aktionen #5

Von Alexandre Ataides vor etwa 2 Jahren aktualisiert

  • Status wurde von In Bearbeitung zu Testing geändert
  • Zugewiesen an Alexandre Ataides wurde gelöscht
  • Zielversion wurde auf 4.5.3.0 beta1 gesetzt
  • Release Notes Langtext aktualisiert (Vergleich)
Aktionen #6

Von Tobias Schindler vor etwa 2 Jahren aktualisiert

  • Zugewiesen an wurde auf Tobias Schindler gesetzt
Aktionen #7

Von Tobias Schindler vor etwa 2 Jahren aktualisiert

  • Zugewiesen an Tobias Schindler wurde gelöscht
Aktionen #8

Von Mirko Janssen vor etwa 2 Jahren aktualisiert

  • Zugewiesen an wurde auf Mirko Janssen gesetzt
Aktionen #9

Von Mirko Janssen vor etwa 2 Jahren aktualisiert

  • Status wurde von Testing zu Erledigt geändert
Aktionen #10

Von Daniel Wu vor etwa 2 Jahren aktualisiert

  • Tags 4.5.3_beta 1 wurde gelöscht
Aktionen

Auch abrufbar als: Atom PDF