* Add email_header_and_footer_enabled flag to appearances table
* Set email_header_and_footer_enabled default value to false
* Add checkbox to appearance to toggle show header and footer in emails
* Add email_header_and_footer_enabled to allowed params in controller
* Add header and footer messages to the html and text email layouts
* Remove the color styling for emails header and footer
* Add empty_mailer layout for emails without layout,
to have the header and footer applied
remove EE specific code
remove EE licence checks
move migration from EE to CE folder structure
move specs from EE to CE folder structure
remove EE specific flag specs
Prior to GitLab 9.0, attachments were not tracked the `uploads` table,
so it was possible that the appearance logos were just stored in the
database as a string and mounted via CarrierWave.
https://gitlab.com/gitlab-org/gitlab-ce/issues/29240 implemented in
GitLab 10.3 was supposed to cover populating the `uploads` table for all
attachments, including all the logos from appearances. However, it's
possible that didn't work for logos or the `uploads` entry was orphaned.
GitLab instances that had a customized logo with no associated `uploads`
entry would see Error 500s. The only way to fix this is to delete the
`logo` column from the `appearances` table and re-upload the attachment.
This change makes things more robust by falling back to the original
behavior if the upload is not available.
This is a CE backport of
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9277.
Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/9357
When object storage is enabled, the logos used to customize a GitLab
appearance causes the time-limited URLs to be used. We fix this
by forcing all of these URLs to use the /uploads/-/system prefix
so that they will always be proxied through GitLab.
Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/6778
It gathers list of file paths to delete before destroying
the parent object. Then after the parent_object is destroyed
these paths are scheduled for deletion asynchronously.
Carrierwave needed associated model for deleting upload file.
To avoid this requirement, simple Fog/File layer is used directly
for file deletion, this allows us to use just a simple list of paths.
ObjectStore uploader requires presence of associated `uploads` record
when deleting the upload file (through the carrierwave's after_commit
hook) because we keep info whether file is LOCAL or REMOTE in `upload`
object.
For this reason we can not destroy uploads as "dependent: :destroy" hook
because these would be deleted too soon. Instead we rely on
carrierwave's hook to destroy `uploads` in after_commit hook.
But in before_destroy hook we still have to delete not-mounted uploads
(which don't use carrierwave's destroy hook). This has to be done in
before_Destroy instead of after_commit because `FileUpload` requires
existence of model's object on destroy action.
This is not ideal state of things, in a next step we should investigate
how to unify model dependencies so we can use same workflow for all
uploads.
Related to #45425
This caches the result of Appearance.first in a similar fashion to how
ApplicationSetting instances are cached. We also add some NOT NULL
constraints to the table and correct the timestamp types.
Fixesgitlab-org/gitlab-ce#36066, fixesgitlab-org/gitlab-ce#31698
The only major difference with the EE version is the change from a light and dark logo to only a header logo
The dark logo wasn't used anyway, so it seemed to make sense to me to rename the field to the actual function of it
