19f9d99870
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 |
||
|---|---|---|
| .. | ||
| assets | ||
| controllers | ||
| finders | ||
| graphql | ||
| helpers | ||
| mailers | ||
| models | ||
| policies | ||
| presenters | ||
| serializers | ||
| services | ||
| uploaders | ||
| validators | ||
| views | ||
| workers | ||