Fix primary color usage in emails and federation

[nickvergessen]

• Resolves: N/A

Summary

• Federation box to be implemented on own website also used the background image color instead of the instance theme
• Emails used the color of the triggering user, so if you invite 5 users with different custom background image to an event, you will get 5 differently colored emails instead.
  2 sample emails from the same day, same instance, no settings changed on my side:

From person 1	From person 2

• server/apps/encryption/templates/mail.php

  Line 9 in 304c1b9

  <td colspan="2" bgcolor="<?phpp($theme->getColorPrimary());?>">

  is also affected, but I will instead of patching that migrate it to the proper templating mechanism => Move encrypt-all password email to EmailTemplate #36351

Screenshots

• Theming color: #DF2254
• User custom picked theming color: #ffffff

Before	After

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are adjusted where applicable
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[skjnldsv]

getDefaultColorPrimary should always be available no?

[nickvergessen]

OC_Defaults only has getColorPrimary and I'm unwilling to debug which version of the defaults object is used where and why.

server/lib/private/legacy/OC_Defaults.php

Lines 301 to 309 in 3860dad

	publicfunctiongetColorPrimary() {
	if ($this->themeExist('getColorPrimary')) {
	return$this->theme->getColorPrimary();
	}
	if ($this->themeExist('getMailHeaderColor')) {
	return$this->theme->getMailHeaderColor();
	}
	return$this->defaultColorPrimary;
	}

That's a cleanup task for another day.

[skjnldsv]

ok then

[szaimen]

🐘

[nickvergessen]

Of course there are tests which checks which method is invoked, when getting color in the email... will have a look tomorrow.