Habitica: mana bar should not show in profile when user has opted out of the class system

[Alys]

As reported by citrusella, when a user opts out of the class system and you view their profile by clicking on their name in chat, you see a mana bar in their profile. You should not see the mana bar (because from a user point of view, an opted-out player does not have mana).

For example, with my account set as below, I see a mana bar in my account's profile when viewed from another account.

{
    "_id": "d904bd62-da08-416b-a816-ba797c9ee265",
    "profile": {
        "name": "Alys"
    },
    "preferences": {
        "allocationMode": "flat",
        "disableClasses": true,
        "automaticAllocation": true
    },
    "flags": {
        "classSelected": true
    },
    "stats": {
        "class": "warrior",
        "lvl": 15
    }
}

The relevant setting is "preferences.disableClasses": true - that means the user has opted out and so no mana bar should be shown.

It's possible (I haven't checked this though) that we do have code to check for that case but we might no longer be passing the user's preferences.disableClasses setting to the profile screen.

[thefifthisa]

I'd like to take this!

[paglias]

Go ahead!

[thefifthisa]

@Alys how were you able to get those preferences from another account? When I try this.member.preferences, I'm only able to see disableClasses for the account I'm logged into but not anyone else's 😕

I think that's why this hasClass check for the mana bar doesn't work:
https://github.com/HabitRPG/habitica/blob/9205ec10b3b2a18e5e09522f9e33d6dffca9c240/website/client/store/getters/members.js#L10

member.preferences.disableClasses is undefined for everyone other than the current user and !undefined evaluates to true.

[Alys]

The data I showed comes directly from the database so it's not available in that format to anyone but an admin.

I think you're right about why the check for the mana bar doesn't work, so passing the user's preferences.disableClasses setting to the profile screen might be enough to fix this bug. You might need to adjust the list of user data fields that are public. As a guess, try git grep -i .... through the code base for publicfields to see if that shows you any relevant code.

[thefifthisa]

Thanks, seems to be fixed now!