Joachim Jensen

Thank you for reporting this.

Would it be possible to provide the names of all other active plugins on your site? I suspect there may be something that’s interfering with the database queries used to fetch members.

The has_level() method is a misnomer when it comes to Trait automators, because it only looks at levels that have specifically been given to the user.

So in your use case, the get_level_ids() is the way to go.

In the future I will probably combine these 2 methods into something that’s simpler to use as I acknowledge that is a bit confusing.

Currently this is not supported, but similar functionality has been requested before. The WooCommerce automator included in the plugin makes it possible to grant access based on a product purchase, not variations of a product.

I will see if this is something that can be added in the future

Thank you for reporting this.

Are you by any chance using automators in your levels?

Can you see if this snippet works for you:

if(in_array(398, rua_get_user()->get_level_ids())) { ?>
   <p>authorized</p> 
<?php } else { ?>
    <p>not authorized</p>
<?php } ?>

Yes it is correct that since version 2.6, parts of the REST API will automatically be restricted to users with lower permissions. To disable this, go to User Access -> Settings in the Admin Area, find the setting “REST API Content Protection” and toggle it off.

Would it be possible to share more about your use case, ie. what parts of the REST API are you expecting to be available to all users by default? I want to see if it’s possible to tweak the functionality such that you can keep the setting on without it causing conflicts.

Hi,

The automator should handle membership extensions out of the box, i.e. if it’s triggered for a user that is already a member (whether active or expired), their membership will be extended/renewed by the set level duration.

Would it be possible to share some more details about how you test purchases in WooCommerce? Then I will see if I can reproduce the problem.

Apologies for the delayed response here. I was able to reproduce the problem you are experiencing, and I will include a fix for it in the next version.

In the meantime, adding this to your theme’s functions.php should stop redirecting users to the admin area if they don’t have access to it:

add_filter( 'login_redirect', function($redirect_to, $requested_redirect_to, $user ) {
    $intercept = empty($redirect_to) || mb_strpos($redirect_to, 'wp-admin') !== false;
    if(!$intercept) {
        return $redirect_to;
    }
    
    if(!function_exists('rua_get_user')) {
        return $redirect_to;
    }

    $rua_user = rua_get_user($user);
    if ($rua_user->has_global_access()) {
        return $redirect_to;
    }

    $user_levels = $rua_user->get_level_ids();
    if (empty($user_levels)) {
        return $redirect_to;
    }

    $metadata = RUA_App::instance()->level_manager->metadata()->get('admin_access');
    foreach ($user_levels as $level_id) {
        if ($metadata->get_data($level_id, true)) {
            return $redirect_to;
        }
    }

    return home_url();
}, 10, 3);