Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+1 vote
in Q2A Core by

I implemented the code here for checking if a user is blocked. However, if I block an IP address, the user can still do things if their specific account isn't blocked. What do I  need to add to check their IP isn't also banned? Anything else I should add?

1 Answer

+1 vote

The easiest way to check for any type of block on the current IP/user is to call qa_user_permit_error() from qa-app-users.php with no parameters. If it returns false, the user is OK, otherwise it will return a string denoting why the user is blocked (see function's documentation).

If you just want to check if the IP is blocked, call qa_is_ip_blocked() from qa-app-limits.php.

How would I check if it was a user that isn't blocked but has their email confirmed? I tried passing in "confirm" but it returns "level" for all users except me (admin).

EDIT: oh I guess you pass in something representing "able to ask questions" etc? Is there any way to define custom permissions for actions in a plugin?
The short answer is check if (qa_get_logged_in_flags()&QA_USER_FLAGS_EMAIL_CONFIRMED).

The long answer is you can define a new option which takes one of the constant values QA_PERMIT_* defined at the top of qa-app-options.php. If you pass the name of that option in as the first parameter to qa_user_permit_error(...), you'll get back the appropriate response.

If you want to offer the permissions option in your interface, see how qa-page-admin.php does it, for the 'permissions' switch value.
Man this is getting confusing now: as the super admin, it appears that my email is technically unconfirmed! I have "8" in the flags column. I can just edit that to 9, but I think that may be a problem if I decide to release my plugin to the public.

Does the current Q2A ensure admins have the email flag set? Or would I need to also check if the user's level >=QA_USER_LEVEL_EXPERT ?
Yes, the full set of things you could check for is below, adapted from qa_permit_error(...):

if (
    QA_FINAL_EXTERNAL_USERS || // email confirm not currently supported by single sign-on integration
    (qa_get_logged_in_level()>=QA_USER_LEVEL_EXPERT) || // if user assigned to a higher level, no need
    (qa_get_logged_in_flags() & QA_USER_FLAGS_EMAIL_CONFIRMED) || // actual confirmation
    (!qa_opt('confirm_user_emails')) // if the email confirm option is off, we can't ask it of the user
) {
    // we behave as if the user has confirmed their email address

Sorry about that - much simpler to use:

qa_set_option('my_temp_permit_option', QA_PERMIT_CONFIRMED, false);
    // false here means option not stored in database

if (!qa_user_permit_error('my_temp_permit_option')) {
    // we behave as if the user has confirmed their email address
edited by
Hmm, not sure if this is maybe a bug in Q2A - when I look at some user pages, on the email field it doesn't say either "Confirmed" nor "Not yet confirmed". This happens for users with flags of "8" or "9" and maybe others too. Dunno if this is a remnant from upgrading or anything?

EDIT: sorry ignore that, I was looking at Experts so I guess it ignores if their email is confirmed or not...