[Resolved] Toolset view does not display translated content (WPML) according Toolset Access

[Author]

Posts

[markW-21]

Hi, Beda, I feel like I should explain you how we control what is displaying in this view.
The access limitations works on Series level, (if user has access to the Series than he has access to all modules belong to the Series).

I have custom capability for each Post group (each post group contains one Series(Parent) and multiple Modules(children)). In the View i use custom short-code [current_user_can ], where I check if current user has a role with custom capability needed to read current Series. If it does I display Series title and its modules, if not I skip it.
I hope this will help you find a solution quicker, Thanks.

[Beda]

Oh... yes, well, this explains why Access does not work as it is intended to work on this site, likely.
This is why we cannot replicate this on a fresh site, and why it persists replacing the FTP Files on your duplicate, as it is stored in the database as user caps

But Access is not really designed to control post types like this.
Now, I still wonder how this is replicable, as we might need some adjustments in Access, but also, on the duplicate, I can replicate this issue without any specific checks with shortcodes in the view.
So that means the caps are altered for every user role in the database, because I even was able to reproduce the issue with a subscriber role, on your site

A question that also was not yet asked, and I think is a valid one at this point, is "since when this happens"
Did an update introduce this issue? Or was it there since begin?
I think it was there since begin, which again would indicate some issue with a particular role and caps setups.

Precise steps on how you set this up would also help us because it is not possible with access to manipulate the caps of all user roles like said unless some customization is applied.

[markW-21]

<q>Did an update introduce this issue? Or was it there since begin?</q>
It happens from the beginning.

Why you think the issue is related to caps? My previous solution was without using custom caps nor existing caps and it had same result (content in Spanish was not displayed), plus your test-view does not use my short-code and still has an issue.

<q>Precise steps on how you set this up would also help us</q>
1. Create post group X
2. Add content to the post group (one Series and related modules)
3. Create a custom role. XRole
4. In the posts group X set read access allowed for XRole role only.

STEPS 1-4 is to setup access and has noting to do with displaying the content on Table of Contents page

5. Change permissions of XRole, add custom capability where Cap Name is post group X id.

STEP 5 will hide Series from the user in the View.

My custom short-code code is available in functions.php of our custom theme.

[Beda]

I suspected so - that this never worked.

As mentioned you cannot control View Loops with Access and you can't use access to add caps to use in Custom ShortCodes to users, this will affect the entire user, not just your shortcode output.

If you set up fresh site with WPML and Access you will not be able to see this issue, or feature, depending on how we see it.
The Views loop will always obey only the to the View, never to the Access rules.

I know my test View doesn't use your shortcode but of course, if the user has custom caps to allow or disallow things, then that applies to the user, as a whole, and then that affects Views because it is set for the user in the database, not as a post type permission saved on user roles by Toolset access. Toolset Access does not literally add caps, it filters them.

I want now to replicate the steps, but I need to ask what do you mean by "5. Change permissions of XRole, add custom capability where Cap Name is post group X id."?
What custom capability are you adding? How is it defined?

Note that we can't debug custom code or custom themes.
We do also not support any third party added caps in access, it's stated in the compatibility doc, this because those caps shall have "precedence" over access rules.

However the theme does not feature a single code about adding custom caps, it only checks on the current user can.
So, how did you add custom capabilities, and how do those control what the View outputs.

Access cannot do this.
It is simply shown by setting up a very simple testing site without the usage of code or manipulating capabilities.
To make users have read access you do not need (or should not use) custom capabilities either, instead of in Toolset Access you can simply check "read", but that will not, and should never affect a View loop.

Could you elaborate on this?
I am also asking the Dev to look into this if possibly soon.

[Beda]

To resolve this, you should reset the Toolset Access rules, actually.
Then, the only way to control any Views loop will be to use HTML conditionals or Views Queries but not Toolset Access settings.

That will be visible as soon access settings are reset, AND any custom cap is removed, but that might be not a feasible solution on your site if you already advanced into development too far to reset this.
So I am asking our Developers if we can provide some solution without resetting this all, however it might include removing the user caps, as Access is not supposed to control a View Loop and will not "interfere" or use caps added by third parties.

I will let you know related to this what the developers can find.

[markW-21]

<q>To make users have read access you do not need (or should not use) custom capabilities either, instead of in Toolset Access you can simply check "read", but that will not, and should never affect a View loop.</q>
I understand that, that is why I use custom short-code to control loop output.

<q>What custom capability are you adding? How is it defined?</q>
Toolset-> Access Control -> Custom Roles -> Change permissions on "Big Picture" (this role gives you access to Bin Picture Series) -> Custom capabilities. There you can see all custom capabilities and only one is selected (cap with name "wpcf-custom-group-e06f2c69abc0ab87a5bf891566ef140e"). wpcf-custom-group-e06f2c69abc0ab87a5bf891566ef140e - is the ID of posts group from Toolset->Access Control -> Posts groups -> Big Picture group (this id is available in database).

In my view I iterate all Series. In my short code I pass a parameter (current Posts Group id where this Series belongs to (capability='[wpv-post-field name='_wpcf_access_group']')). In php I check if (current_user_can('administrator') || current_user_can($capability));

Access knows that current user can "wpcf-custom-group-e06f2c69abc0ab87a5bf891566ef140e" because his role has that custom cap with the similar name (wpcf-custom-group-e06f2c69abc0ab87a5bf891566ef140e).

[markW-21]

Plus I noticed that wpml does not display original content (if there is no translation available) if you try to access original_content_link/lang=es which it should do according to WPML settings and it does on our other site which does not have Toolset Access installed. I suspect something is very wrong between WPML and toolset access.

[Beda]

I am sorry for the delay.

I've replicated the bug, it is unrelated to any customization and I apologise having suspected it, while all it took was a precise replication of the situation on your site.

1. Have a CPT (Custom Post Type) translated (or not) with WPML
2. Add a View of that post type to a page
3. Make sure CPT and page are translated
4. Make any role in access not able to see the post (no read permits)
5. Confirm that you can still see that view as that user even you have no read permissions on the CPT the view displays, both in the native and secondary language
6. Insert the Same View to a page that is made the "home" page (archive) and see you will not see any more content on the translated homepage.

Toolset Access is assuming the View is an archive, because it is on the homepage, designated as an archive.
I've updated our Developer and asked to fix this.

[markW-21]

Hi, Do you have any ETA? or how we can track progress?

[Beda]

It's planned for a future Access release, but I can't state an ETA.
I've asked the DEV if we can prioritize a patch, at least, for an erratum.

I will update you if I receive something.

[markW-21]

Hi, is the update 2.8.4 suppose to fix the problem?

Thanks.

[Nigel]

No, 2.8.4 is the version it was reported for, the fix is in Access 2.8.6.

That is ready for release, we are just waiting on confirmation from our systems team that everything is okay.

We don't deploy on Thursday/Friday ordinarily, and I expect the update to be published at the start of next week.

Sorry it has taken so long to be made available.

[markW-21]

OK. After the update, I created an archive view for Series (custom type). I expected the archive view respects Toolset Access rules but it doesn't.
The post is a part of posts group X, the role Y has access to X posts group X and user Z has role Y.
But in archive view as a user Z I don't see any content.

[Nigel]

OK, let me look into this, I'm returning it to my queue and I'll report back when I've done some testing myself.

[Nigel]

I looked back over this thread, and it appears to me that the issue that was escalated and fixed wasn't in fact the issue that you were reporting in the first place, it was rather something that Beda stumbled upon while working on your site. That's the impression I have, at least, in which case I wouldn't expect the "fix" to have fixed your problem.

Beda isn't with us any more and I don't have access to the duplicates taken and used to report the issue (we don't keep copies of client sites any longer than is necessary).

Rather than taking another copy of your site and trying to join the dots with the extensive existing discussions in this thread, I'd like to go back to the beginning and clarify what it is you want to achieve.

Let me first clarify somethings about Access, which I don't think are clear from the preceding updates.

1. Access has no effect on the output of Views. All results will be displayed, even to users with no rights to read the posts (they cannot read the posts themselves).
2. The output of archives are affected by the Access settings for the post type. If a user with some role does not have rights to read posts of some type, they will not see those posts listed in the archive results.
3. Post Groups only affect the display of single posts. They have no effect on the output of Views or archives.

I think misunderstanding of this last point has probably led to some confusion.

Given this, let's get back to what you want to achieve.

You want to set up a role such that these users don't have general read access to a post type, but you would like these users to be able to see some posts which you specify by adding them to a Post Group. They should be able to see the individual posts, but also when the posts are output by a View (or archive?). This also needs to work in conjunction with WPML, so that if there are translations of the posts included in the group, these should also be visible in the same way to the same users.

Is that an accurate summary of the objective?

If you can confirm that then I can look into a solution.