@MtMNC The block status can be retrieved using either the userinfo API module or users API module, so it should be relatively easy data to check for.

I like your idea, although I think a new function for changing avatars for specific groups shouldn't be scoped to just the Refreshed skin since this'd be useful for multiple skins, so this logic should be contained inside the SocialProfile extension.

As for where the configuration should be, administrators on a wiki should be able to have access changing this type of setting instead of restricting it to system administrators, so it should be placed in a system message.

EDIT:
Heh, ninja'd. I'll reply in a bit :)

How dependent on one another are the individual SocialProfile extensions, and would it be possible to enable this feature without the other SocialProfile features? I ask because my original thinking behind group avatars was that it would allow for a degree of customization without having to resort to SocialProfile.

ORIGINAL TEXT:
There are useful methods for testing membership in certain groups: User::isBlocked(), User::isBot(), User::isLoggedIn(), etc. (documentation).

Also, per Stack Overflow, in_array( 'GROUPNAME', $this->getUser()->getEffectiveGroups() could be used to test for group membership.

So it seems like the key/value idea up above could work with a setup like so:

$this->getUser()->isBlocked() -> banned.png
in_array( 'sysop', $this->getUser()->getEffectiveGroups() -> staff.png
User::isLoggedIn() -> loggedin.png
!User::isLoggedIn() -> anon.png

However, it seems like pretty bad form/security to be performing these sort of checks outside the main PHP file, which would be necessary if we want the checks to be customizable. How do we best proceed? One possibility is that we could tie certain user groups to specific avatars, with the condition that if the user is blocked, the blocked avatar takes precedence over all other avatars. Which is to say, something like this:

Refreshed.skin.php:
if (a banned avatar is provided in LocalSettings.php && the user is banned) {
  use banned avatar
} else {
  use the highest applicable avatar from the list in LocalSettings.php
}

LocalSettings.php:

define banned avatar
define list of other avatars based on user groups:
  sysop -> staff.png
  user -> loggedin.png
  * -> anon.png

Any thoughts appreciated!

@SamanthaNguyen If nothing else, I think Refreshed itself should provide a way to override the two icons that are baked into the skin. It'd be pretty straightforward if we made two system messages, one for the URL of the anon image and one for the logged-in image. The height of those images would default to the height of the sidebar but could be customized with on-site CSS. Thoughts?

How dependent on one another are the individual SocialProfile extensions

@MtMNC Out of the entire social tools group, most of them depend on SocialProfile; you can check out the full list on https://www.mediawiki.org/wiki/Template:Social_tools.

and would it be possible to enable this feature without the other SocialProfile features? I ask because my original thinking behind group avatars was that it would allow for a degree of customization without having to resort to SocialProfile.

Sure it'd be possible to recreate the avatar function in Refreshed without relying on SocialProfile, but I don't see a reason why. (Ideally I think either this ticket should be closed as declined, or have it rewritten so the title says "SocialProfile should allow custom group avatar defaults", my reasons are provided below)

Special:UploadAvatar would have to be recreated which includes writing new i18n messages, introducing new user rights, designing the interface, and doing the same thing for another special page called Special:RemoveAvatar, + introduce schema changes (new tables) to have a place for the avatars to be stored. Even then, the avatar is only still visible to only to yourself which means we'd also have to provide logic for a user interface that displays the avatar to other people. In the end, all of these things are already available in SocialProfile, so reinventing the wheel inside Refreshed means code duplication, which also means double the maintenance that's just unnecessary.

However, it seems like pretty bad form/security to be performing these sort of checks outside the main PHP file, which would be necessary if we want the checks to be customizable. How do we best proceed? One possibility is that we could tie certain user groups to specific avatars, with the condition that if the user is blocked, the blocked avatar takes precedence over all other avatars.

I don't think I can really comment too much on this since security isn't my main area, but you could ask @ashley since she's much more familiar with security than I am. However, can you explain why you think it's necessary to perform them outside instead of in SocialProfile core? That doesn't make sense to me. Refreshed can just detect if the wAvatar class exists (SocialProfile provides this PHP class), and if it does, show the avatar. SocialProfile could have these checks written inside to decide what kind of avatar it wants to show.

@SamanthaNguyen The avatars would not be configurable by the user, only by sysops who could edit the system messages where each group's avatar is listed. As such new special pages and new user rights wouldn't be necessary. It's basically replacing the current WikiFont icons for logged in and anon users with something slightly more customizable by the staff, not by normal users.

I was thinking a group avatar system may be useful for BS01, where users would be given certain icons (I was thinking gray Hau for anon, red Hau for user, gold Hau for staff, infected Hau for banned). You're right, that probably falls outside the scope of the Refreshed skin. That said I wouldn't want to implement other SocialProfile features such as profiles, individual avatars, etc., and I feel this use case is limited enough that installing all of SocialProfile just to disable most of its features wouldn't be worth it. If this were implemented in SocialProfile in a lightweight way, that would be fine. In that case maybe the broader request is that SocialProfile be made more modular so users can install features as they want them instead of disabling all the features that they don't want.

Even if a more complex group avatar system falls outside the scope of Refreshed (which you're right, it probably does), I think Refreshed should at least provide a way to customize its existing logged-in and anon icons.

@MtMNC Ah I misunderstood, that was my bad. However, I'd like to say that my point still stands. I'm not sure what this is supposed to provide besides it being nice to have, if there's no intention to create a user interface for publicly showing the avatar to others, since the avatar will be only be able to see by the logged-in user.

• My 1st point: If the intention is to provide a way for the user themselves to easily discern their own status, then sure, although pretty much all sensible wikis will send a message to banned users on their talk page of how long they're banned and why they're getting banned (and while BS01 doesn't have Echo notifications, MediaWiki core will be the one that can still provide a basic notification for when a user gets a new message to help them notice it). Creating more distinction for specifically banned/blocked users (to me at least) feels like intentionally socially splitting them off from the rest and creating this sense of shame that's not necessary. Staff will already know they're staff since they'd be experienced enough to know they have more user permissions/rights than others too, and Refreshed's header interface should be easy enough for a regular user to learn that they've logged in and they're a regular user.
  • If there's still a want to create some sort of distinction, it can be created by coloring people's username links, which is easily possible with CSS (and that's already done on BS01 via http://biosector01.com/wiki/index.php/MediaWiki:Common.css ). But let's say in this possible situation of the future that this was actually implemented - then there's a long explanation on why they're banned, their username is (possibly) colored, their own avatar is different - to me it feels just way more shame than necessary. If the message is trying to say "you're banned", the message actually more sounds like "you've done something wrong and you're banned and you shouldn't do it again", which can be interpreted as intimidating.
• My second point: Going back to the part about one-skin, my comment is basically @ashley's comment on https://gerrit.wikimedia.org/r/#/c/225060/:

Skins are, well, skins. They're not extensions, so they really shouldn't be providing additional functionality, which would then be tied to a specific skin. Alas, some major third parties do this, but that's even more of a reason for us not to do that.
Features (avatars, user profiles, whatever you can think of) should be as skin-independent and cross-skin-compatible as possible. Skins should only determine what the features visually look like (i.e. does something have a gray background, white background, transparent background, red background, ...).
The SocialProfile extension in its entirety is licensed under the GNU General Public License, version 2.0 or any later version, so I cannot prevent you from copying and/or adapting code from it. But I can strongly recommend against that, because I feel it would be counterproductive, out of scope for a skin and it would lead into unnecessary code duplication, thus increasing the collective technical debt.

• What also happens when another user wants to build this group avatar support is that most likely, code will be duplicated from Refreshed (if in the future this was implemented), and it'd spread to other skin, which can definitely cause a chain reaction to the other skins that exist - this would mean x * the maintenance.

If you're still interested in customizing the log-in + logged-out icons, you can manually do this with HTML, CSS, + JS. The class for the logged-in icon is .avatar-no-socialprofile.wikiglyph-user-smile while the logged-out icon is .avatar-no-socialprofile.wikiglyph-user-sleep, and then you can use the [[http://api.jquery.com/replacewith/|.replaceWith()]] jQuery function to replace it with what you want, and then some CSS for positioning, size, etc.

@ SocialProfile: Feel free to write a ticket about it! Realistically speaking that an Epic like that though will take quite a while, since the size of SocialProfile is quite a beast, and the modules inside are dependent on each other.

However, it seems like pretty bad form/security to be performing these sort of checks outside the main PHP file, which would be necessary if we want the checks to be customizable.

I don't really see the security implications of that (Provided you're doing it somewhere on the server side). Doing this sort of check in javascript where the user could mess with it would probably not be best (However, its informational and not an actual access control, so it probably wouldn't matter that much).

In MediaWiki, the normal way to make a a check customizable, is have the default implementation in the main extension, but add a custom Hook to allow extensions to override if they want to.

I don't think there are really security implications here. Is it ok if I remove the security tag?

Sure, that's fine. I'll just remove it right now then :) thanks for the insight!

@SamanthaNguyen In brief--all good points. You've turned me. :P

That's a good point about inclusion. Currently the BS01 splash page has a special icon for banned users (the infected Hau--it was intended more as a goofy reference than anything else), but I could see its divisive effects being a concern. I'll drum up a discussion soon about removing it.

I do still think it'd be good to provide two system messages (Refreshed-anon-icon and Refreshed-user-icon or some such) so sites could replace the WikiFont logged-in and anon icons with a default image. A jQuery solution just seems unnecessarily impractical in my opinion. That said, you've convinced me that any more fine-tuned customization shouldn't be done on the skin side, and that's what this ticket is about, so if there are no objections I'll close this ticket and open a different one.

As for SocialProfile--you know, maybe that's not a can of worms that's best not opened. :P

Sounds good, I'm fine if you want to open up a new ticket :-)