* 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
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
This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).
This commit adds a number of _html columns and, with the exception of Note,
starts updating them whenever the content of their partner fields changes.
Note has a collision with the note_html attr_accessor; that will be fixed later
A background worker for clearing these cache columns is also introduced - use
`rake cache:clear` to set it off. You can clear the database or Redis caches
separately by running `rake cache:clear:db` or `rake cache:clear:redis`,
respectively.
In 8278b763d9 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.
Fixes: #17382
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
Nick Thomas