Home › Toolset Professional Support › [Resolved] Access: Administrator not viewing all posts
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
- | 9:00 – 12:00 | 9:00 – 12:00 | 9:00 – 12:00 | 9:00 – 12:00 | 9:00 – 12:00 | - |
- | 13:00 – 18:00 | 13:00 – 18:00 | 13:00 – 18:00 | 14:00 – 18:00 | 13:00 – 18:00 | - |
Supporter timezone: America/Jamaica (GMT-05:00)
Tagged: Access plugin
This topic contains 12 replies, has 3 voices.
Last updated by pedro.S 4 years, 4 months ago.
Assisted by: Shane.
Im trying to restrict a view from displaying posts according to user-group.
I followed your tutorial here https://toolset.com/documentation/user-guides/views/using-access-to-hide-certain-posts-from-view-results/ and inserted the conditional.
It's having pretty strange issues in the frontend because not even admin is beeing allowed to see the posts (?!).
I have created a custom post type called "Programs and Materials"
I have defined "Program 1" as group called "Participants" which is included that the Participant user role is allowed to READ.
Apparently i believe it's working for the frontend users included in the groups.... what i dont know why is why the administrator doesn't have to access to all the listed posts in the view considering that the admin has option to view everything.
For example i have a post inside "Programs and Materials" defined for group "Guests" which has Guest and Admin included... but i can't see it on the frontend.
I will gladly provide links and access if you set next answer as private.
If i remove the conditional, administrator can view all posts.
Here's the conditional:
[wpv-conditional if="( $(_wpcf_access_group) eq 'wpcf-custom-group-5958a604ed3dce988ff600b265cd08c3' ) OR ( $(_wpcf_access_group) eq 'wpcf-custom-group-1cd17454e740d7f32cc3dd4b524312fc' ) OR ( $(_wpcf_access_group) eq 'wpcf-custom-group-a8d45f379f5f02cc11c3d1561719d399' )"] <div class="col-md-4">[wpv-post-body view_template="loop-item-in-programs-and-materials"]</div> [/wpv-conditional]
thank you
Hi, I will be glad to take a closer look. Please provide login credentials in the private reply fields here.
It seems that you need to include the Guest Access group wpcf-custom-group-9366a2751ef2a1c1d4d98cc377d61e8c in your conditional as well:
[wpv-conditional if="(( $(_wpcf_access_group) eq 'wpcf-custom-group-5958a604ed3dce988ff600b265cd08c3' ) OR ( $(_wpcf_access_group) eq 'wpcf-custom-group-1cd17454e740d7f32cc3dd4b524312fc' ) OR ( $(_wpcf_access_group) eq 'wpcf-custom-group-a8d45f379f5f02cc11c3d1561719d399' ) OR ( $(_wpcf_access_group) eq 'wpcf-custom-group-9366a2751ef2a1c1d4d98cc377d61e8c' ))"]
I've added that item to the conditional, and now I can see Podcast 2 in the results. Can you confirm?
Chris,
There's something here that it's not making sense... that's my point here and probably i did not explain myself the better way. Will try to explain below.
I have created a user and he is from the USER ROLE -> PARTICIPANTS (you can create one if you want to test).
I created a post group called the MEMBERS OR PARTNERS OF THE PROJECT and assigned PODCAST 1 post to it.
This post group has defined that ONLY users with the role MEMBERS can READ.
I logged in as participant and can see the PODCAST 1 post.. which i should not see because i'm not a member user role.
That's what this post all about, access is aparently not working for custom roles or something.
I tested inserting the conditionals separetly like this, but it's flawed as well:
[wpv-conditional if="(( $(_wpcf_access_group) eq 'wpcf-custom-group-1cd17454e740d7f32cc3dd4b524312fc' ))"] <div class="col-md-4">[wpv-post-body view_template="loop-item-in-programs-and-materials"]</div> [/wpv-conditional] [wpv-conditional if="(( $(_wpcf_access_group) eq 'wpcf-custom-group-5958a604ed3dce988ff600b265cd08c3' ))"] <div class="col-md-4">[wpv-post-body view_template="loop-item-in-programs-and-materials"]</div> [/wpv-conditional]
As PARTICIPANT, i'm seeing PODCAST 1 post in the view which is assigned to MEMBERS post group. I shouldn't be seeing that post inside the view.
Hope it was clear enough.
Thanks
Well apparently i know where the problem is... the conditionals are working... it's just checking if it's assigned to that group... which is correct.
But the usergroup has set that only members can read, not participants. That's where it's flawed aparently, or i'm missing something somewhere.
It's ignoring the permissions that are set inside the usergroups.
Chris,
Can't edit the previous post so here it goes.
I've checked this thread where a solution is presented... but this is from 2015, so i guess this is already built-in into access and views?
https://toolset.com/forums/topic/will-views-respect-read-access/#post-329040
This user had the same issue in 2017, still i see lots of functions that i really dont know which to use:
https://toolset.com/forums/topic/views-query-filter-based-on-access-post-group/
I'm running on a deadline here, so i await patiently for feedback.
thank you once again for your time.
Best Regards
This is a VIEWS -> ACCESS issue. The goal here is to use POSTGROUPS permissions to hide/show post in the view according to it's permissions.
So i inserted into functions.php and inserted the shortcode into Toolset custom shortcodes in the settings tab:
function access_check_permission_func($atts){ global $current_user; $a = shortcode_atts( array( 'post_id' => '', ), $atts); get_currentuserinfo(); $access_group = get_post_meta($a['post_id'], '_wpcf_access_group', true); $access_option = get_option("wpcf-access-types"); $roles = array("subscriber" => 0, "contributor" => 1, "author" => 2, "editor" => 7, "administrator" => 10); if($access_group){ if($current_user->user_level >= $roles[$access_option['wpcf-custom-group-5958a604ed3dce988ff600b265cd08c3 ']['permissions']['read']['role']]){ return 1; }else{ return 0; } }else{ return 1; } } add_shortcode('access_check_permission', 'access_check_permission_func');
the custom group above is the Participants post group.
And in the view output:
[wpv-conditional if="( '[access_check_permission post_id = "[wpv-post-id]"]' eq '1' )"] [wpv-post-title] [/wpv-conditional]
I designated in the participants group that the subscriber has READ access.
I went to the user and set him as subscriber.
I should see only the program1 post because it's the only one that it's in the participants group, instead i'm seeing all the post titles.
Hi, sorry for the delay. Our queue is busy at the moment, and I'm just now back to your ticket. I'll update you shortly.
This conditional is flawed because it tests permissions for the same post group for all posts in the loop, not the post group of the current post in the loop:
if($current_user->user_level >= $roles[$access_option['wpcf-custom-group-5958a604ed3dce988ff600b265cd08c3 ']['permissions']['read']['role']]){
I can share the fix, but it's pointless - user_level simply is not a reliable way to determine which Users have permission. You can manipulate individual capabilities in Access independent of the User level, so testing the user level isn't helpful when you really need to test capabilities.
For now, let's disregard the access_check_permission_func function and shortcode. Let's return to the original post group conditionals, and I can explain in a bit more detail how these conditionals can be used in conjunction with Access Control shortcodes to show and hide specific content in a View. I was focused on the wrong part of the problem earlier so I didn't share enough details for you.
The main problem is that Access Groups do not show or hide content in Views, as you have noticed. If a disallowed User clicks the post link from the View and tries to visit the post, the Access Group permissions are applied and only Users in the allowed groups can see those posts. To restrict visibility of content in the View, however, there is another step involved. You have noticed that the conditionals really just test to see if a post is in a specific post group. If applied alone, however, these conditionals do not consider the current logged-in User and whether or not s/he belongs to the specific group tested in the conditional. Access Control shortcodes ( https://toolset.com/course-lesson/access-control-texts-inside-page-content/ ) can test whether or not a specific User has a specific role, but not whether or not the current post belongs to a specific Post Group. Combining the conditional and the Access Control shortcode will give you full control over who sees which posts, though it's a bit tedious.
First, set up a post group conditional in your View to test if the current post in the loop belongs to a specific post group, for example, Members or Partners i.e. wpcf-custom-group-1cd17454e740d7f32cc3dd4b524312fc:
[wpv-conditional if="(( $(_wpcf_access_group) eq 'wpcf-custom-group-1cd17454e740d7f32cc3dd4b524312fc' ))"] The post [wpv-post-link] belongs to the Members or Partners group. [/wpv-conditional]
All Users will see the text in this conditional if the current post is in the Members/Partners post group. But you want to go one step further, and restrict this to only those users in the Members/Partners group (and admins). That's where Access Control shortcodes can come into play. In the shortcode configurations, you would choose the roles that have read access in the Members/Partners Post Group. The system will generate the proper shortcode syntax and insert it for you:
[toolset_access role="Administrator,Members or Partners of the Project" operator="allow"] This text is visible to Admins and Users in the Members/Partners User role [/toolset_access]
Nest the conditional and the Access Control shortcode for full visibility control in the View Loop (it doesn't really matter which order you nest the components):
[wpv-conditional if="( $(_wpcf_access_group) eq 'wpcf-custom-group-1cd17454e740d7f32cc3dd4b524312fc' )"] [toolset_access role="Administrator,Members or Partners of the Project" operator="allow"] This text is visible to Admins and Members/Partners Users when the current post is in the Members/Partners group. [/toolset_access] [/wpv-conditional]
I hope this helps clarify the complete solution. This approach is tedious because depending on the case, you may need to create quite a few conditional and Access Control shortcode combinations to support the different post groups and user roles. In a pinch it could work as a proof-of-concept. During our team meeting yesterday, our team leader mentioned that our developers have recently provided a more efficient way to handle this specific problem, and he was in the process of putting together an example for us to share. I will reach out to him and try to get that expedited up for you, so I can give you the best solution. I'll let you know what I find out, but I wanted to make sure you had this information since you mentioned the timeline, and get your feedback.
Hi Christian,
First of all, thank you for your time.
The 2-conditional-way worked perfectly.
I understood what you said, i understand also that the settings for access in the Access control is designated for it's pages and not views.
But what i believe Toolset should do is provide more integration between Views and Access, and the reason i'm saying this is that they are inheritable interlinked.
You cannot give access to a post without without showing the user that you have it, and if it's blocked by membership or user role you (Toolset) should provide options to not show it or show it perhaps in different way compared to the free posts.
Sure, you can say that is already possible by the solution you presented and it's partially true, but what i mean is giving this possibilities using a GUI. Most members of Toolset i believe are those who build websites for clients (like ourselfs) and many times they wish to control things by themselfs.
Imagining that the client wishes to add a postgroup on the future, he will be stuck without our help. While this is isn't exactly a problem for us, it may be in a future project a requirement.
In this case the client will not be implementing future user roles or postgroups, so the problem is fixed. Loved working on this project because it was the first that allowed me to fully work with toolset access, that, dispite not giving all the possible implementations with the remaining toolset modules, it works very well.
If you have the time then yes, i would like to know what more efficient way to handle this specific problem exists, for my knowledge (and yours of course) in future projects. But as already mentioned for this project we have it fixed, so no rush, only when you have time.
Best regards
Hi Pedro,
Unfortunately Christian is currently on Vacation so I will be handling this ticket here.
From what I've read so far this issue was resolved with Christian's help. Can you confirm if there are any other issues related to this ?
Thanks,
Shane
My issue is resolved now. Thank you!