Is there a possible conflict between Random Avatar and Badges plugin?

Question

It seems that there is a conflict between these two plugins. It happens that when a random avatar is created, an "avatarblobid" is assigned. If, for some reason, the user decides to change his avatar to "NULL", the following function of the badges plugin checks if there is an "avatarblobid" and the user receives the badge without having actually uploaded the avatar

if (qa_opt('avatar_allow_upload') && isset($useraccount['avatarblobid'])) {
                $badges = array('avatar');
                qa_badge_award_check($badges, false, $userid);                
            }

}

Is there a simple way to avoid this conflict? Off course, one could add a new column to the users table for instance in the users table indicating whether it is a random avatar or not. However, I think that this a big change. Is it possible to change the test in order to avoid this?

Answer 1

Thinking this in terms of requirements, what you want is to consider the avatars assigned by the RA plugin as non-avatars. So the request is, by definition, a bit contradictory.

Anyway, extending the requirement, what you could do is to create a list all avatars that you don't want to consider as avatars (all the ones you've configured to be randomly assigned) and then check that the avatar saved is not in the list in order to fire the award.

In terms of code you could do something like this (this is just a draft, so don't fully trust it!):

$raBlobIds = array('8118418755431727484', '6798918775132737485', '1593687456258951475');

if (qa_opt('avatar_allow_upload') && isset($useraccount['avatarblobid']) &&
    !in_array($useraccount['avatarblobid'], $raBlobIds)
) {
    $badges = array('avatar'); 
    qa_badge_award_check($badges, false, $userid);                 
}

You can get the blob ids from the ^blobs table.

Alternatively, you can follow a different approach by turning the requirement into something like this: in order to get the badge you need to CHANGE or SET your avatar. This means, the situations that should fire the award would be, firstly, having a null avatar turned into an avatar (making sure this does not happen during registration) and secondly, having a non-null avatar turned into a different non-null avatar. The latter one, means you need to keep track of the previous avatar and, in order to do so, I think you will need to use the filter_profile function of a filter module. So at that time you will have both values to compare. This approach is more complex but you are not tied to knowing which avatars you want to consider non-avatars.