Solutions/steps you can take now if you want, things we'll fix in the next release, & quick thoughts:
Sidetrack: Hm, if you clicked on a skin called google what would you expect it to look like? I don't know, but you might visit the current //depot/zcs/FRANKLIN/ZimbraWebClient/WebRoot/skins/
I suppose to make that 'accurate' you'd have to disable all the nice AJAX features like drag-n-drop of mail items - lol.
Anyways back to options:
A) Disable the Yahoo skin in your COS or remove it from zimbraInstalledSkins all together.
There's even corresponding ZimbraInside / ZimbraPowered logos depending upon how you modify the software.
Customizing Themes and Adding Zimbra Powered Logo - Open Source Edition - Zimbra :: Wiki & ZWC 5.0 Themes (gives directions for ZimbraInside logos which are included in the _base/logos/ZimbraInside folder)
C) If using NE you can replace them with your own logos to your liking course.
Has been replaced with AppBanner.png#2:
D) It's in the public perforce cache so you could replace your current with that as well.
However LoginBanner.png for this skin is still just one big YAHOO! so I've filed the following RFE Bug 30183 - Yahoo Skin LoginBanner.png to have the default changed to:
Actually I don't think the yahoo skin ever pointed at _base/logos in the properties file when it was first rolled out, and people could have certainly checked it out it before enabling it for users.
Examining /FRANKLIN/ZimbraWebClient/WebRoot/skins/yahoo/skin.properties#1 through #12 it always has some variation of:
LogoImgDir = @SkinImgDir@/logos
LogoImgDir = /zimbra/skins/yahoo/logos
Here's some recent corrections to it: Bug 26931 - Need to convert yahoo skin to use base2
Infact a lot of people would be hard pressed to tell which Y! services are powered by Zimbra front-end, Zimbra back-end, or both. There is or will soon be some of all 3 in the wild if you look closely.
I will allow that we may have gone about it the wrong way and could create a separate yahoo2 skin internally for our rollouts but we want you guys to have the ability to check out the cool skins as well.
OR file a reverse RFE & drum up support to have it moved back to /opt/zimbra/zimlets-extras. That's the beauty of this community. Open Source Product Management: How do features get into Zimbra?
For instance an example confliction: Bug 13183 - view mail for domain admins is a contradiction to people wanting to keep the current "can't view mail" for domain admins so in response to that there's Bug 11374 - View Mail: should be possible to disable this which will be handled by this RFE: Bug 11515 - role based delegate administration
So yes, we could have done the above 'less-invasivly' by using a internal only skin that defaults to a Y! logo and keep the skin.properties pointing at _base for NE & FOSS ZCS (or used one's with the Zimbra name like waves, lemongrass, etc). What's funny about it is that if we put all our 'play' skins in the source (like we occasionally do with _sample), then someone would have just complained about having several variants of yahoo skins showing up in their skins folder. Meanwhile someone else would have filed an RFE to get them turned on by default because they like them.
I understand that not everyone has the time to read every bug action like I try to do, so for most it's upgrade then discover new features - but we're open source to the core, and you can grab out main branch of code daily for everything but NE related features. Plus it's always a good practice to use a test dev or demo environment before production rollout.
Guide Zimbra to contain what you want it to be by using Bugzilla & tagged support ticket requests to add weight if you're NE.
Everyone in this thread is an excellent contributor or valued frequent forum member - I'm really not trying to be condescending in any of the above wording - but everyone here knows that all roads to getting something fixed, corrected, changed, or developed by Zimbraineers lead to Bugzilla, so make me proud and check PM occasionally so we're not worrying about tiny things like logos and can instead fuss over & shape the truly great RFE ideas out there.