User's "away" status always "None"

[rdswift]

I'm trying to test the away status of the users in a channel, but the away attribute of the user class is always returning 'None', even when the user shows up in my IRC client as being away (and they have a current away message). My test script is:

@sopel.module.require_admin()
@sopel.module.require_privmsg()
@sopel.module.commands('userlist')
def userlist(bot, trigger):
    channel = sopel.tools.Identifier('#MyTestChannel')
    try:
        privs = bot.channels[channel].users
        for username in privs:
            user = privs[username]
            text = "User: %s status is " % (user.nick)
            if (user.away):
                text += "Away (%s)" % (user.away)
            else:
                text += "Active"
            bot.notice(text)
    except Exception as ex:
        bot.notice("Exception: %s" % (ex))

Sopel v. 6.6.9 running on openSUSE 42.1 (x86_64). Sopel installed using pip.

Am I doing something wrong, or perhaps misunderstanding the meaning of the away attribute?

[dgw]

This is a good catch. On networks that do not support the away-notify CAP, User objects are never getting their away property set. Even on networks that do support away-notify, the property is onlyl set after the first AWAY message received for that user.

We've a start on fixing the initial population of values via WHO replies in #1663 (thank you, @rdswift!), and we'll keep working on further enhancements—e.g. #1664, which intends to add WHO polling for the minority of networks that still do not support away-notify.

Another possible enhancement would be to assign the away message (if known) to away, rather than only a Boolean value. I haven't thought through all of the implications yet, though it should work in theory (non-empty strings are truthy, and AFAIK an empty away message isn't possible). We might also keep the Boolean in away and add User.awaymsg or similar to contain the message itself (None if the user is not away).

[Exirel]

Another possible enhancement would be to assign the away message (if known) to away, rather than only a Boolean value.

Not a huge fan, since you never now what weird stuff people are doing with boolean (like int(True) to get 1 or 0).

In favor of away_message (accurate yet short enough).

[dgw]

I believe this is fully resolved by #1663 and #1664, both of which are now merged.