🇧🇪Belgium @jyraya

Hello,

The module is designed for working with the "Views" module.

When you create a page "View" with this module enabled, you can restrict the access to this view to the user referred in the path (URL) you set in the "Path"" option in the page settings" block of the "View" configuration.

The path option value must contain a dynamic parameter defining this user reference. Usually, the parameter inserted in the path is "%user" as for the edit form of the user profile (I.E.: "user/%user/edit").
However, it happens people wants to use another parameter format as "%uid", %employee" or even "%".

The "User parameter name used in the path" field allows you telling to the system where it can find the parameter referencing the user in the path.

If I reuse the above examples, the value to insert in this field would be:

• For "%uid" (e.g. "page/%uid/personal_content"), the value to set is "uid".
• For "%employee" (e.g. "page/%employee/personal_content"), the value to set is "employee".
• For "%", it is special case as the usual 2nd part of the parameter "name" is absent. In that case, you must play with such value "arg_0".
  • If you have a simple View path as "page/%/personal_content", the value is then "arg_0".
  • If you have a complex View path as "page/%/blabla/%" where the second "%" represent the user-related parameter, the value is then "arg_1".

The module does not work for restricting a page "View" on a specific user, by defining a View path like "user/jyraya/personal_content".... at least yet. :-)

Does this feedback help you?

Regards.

Hello toprak,

Sorry for the silence.

I was trying to find stable solution for the problem but I did not succeed yet.

I've just pushed in the issue's fork a fix for your specific case that should work. With it, you are now able to give access to your "views" to the concerned user and the users that have the "admin" roles you set in the configuration.

This patch works on the type of path (URL) that you use.

In order to close this issue, I still need to:

1. Ensuring that the access control works when the access control must be applied on an link different from a tab one e.g., menu item in the site main menu.
   I did not find yet a good solution for this.
2. Writing the automatic tests covering the access controls implied on menu & tab links.

Kind regards.

Hi,

I am finally able to reproduce the issue.

I am working on it.

Thanks for your help. I keep you posted when I found the fix.

Regards.

Thanks for your feedback.

I did the same configuration for a Views locally, without reproducing the issue.

Among the modules you have installed on your site, are there other modules (contrib or custom) altering or enriching the Views features or could change the route definitions?

Or maybe a module like Display suite or context that could also affect the behaviour of the module.

Hello Toprak,

Thanks for your feedback.

I will nevertheless keep the ticket open because if the patch removes the error you have encountered, it does not solve the root cause of the issue.

I've tested a view with the information you provided.

I never reproduced the issue until I simulated it by modifying the module's code to nullify the value of "$alternativeRoles" targeted by the patch submitted by keshavv.

At that step of the module's process, we know that the Views is not accessed by the concerned user but by another user, for which we hope that at least one of the roles set in the Views configuration matches one of the user's roles.
As we do not get the list of roles set in the Views configuration, this other user, as well as other similar users, will always get access denied instead of the expected Views content.

Therefore, I can only consider the issue fixed if we find what nullifies the "_current_user_roles_access_check" requirement the module adds to the route of the created Views.

I think that another module could possibly interfere with the module process and generate the issue.

Could you kindly give me more information about the other modules (Core and contrib) enabled on your site? Maybe I can find the one that could be the cause of the issue?

Could you also tell me if you have a similar problem when you change the "Access" settings of your Views, to "Role" instead of "Current user or role(s)" with the same role(s) you set previously?

Your help will be really appreciated.

Kind regards.

Hello,

Sorry for the late answer. I was offline these 2 last weeks.

Could you tell me more about the rest of the site configuration, @Toprak?

Especially, this kind of information:

• Which version of Drupal do you use in case I did not see an API change, since I released the module.
• The module works on the basis of its configuration but also on the path of the page (e.g., "/user/10") wherein the Views is displayed. Therefore, could you give me its structure?
  The module could have a problem because your path does not allow retrieving the user id AND the configuration of the roles (see later in my comment).

This information will allow me trying to reproduce the bug and bring you a solution ASAP.

Concerning the provided patch, thank you for your contribution. I took a look on it. My concern about it is that it hides any potential issues the module could generate instead of raise them and helping to improve it.

For instance, from what I see, the method checking the access does not receive the 2 roles that Toprak configured in his view.
I will check this part while waiting for your feedback, @Toprak.

Kind regards.

I finally reviewed the patch and merge it.

Thanks for the contribution!

Hi @urvashi_vora,

Thanks for reporting the issue!
I will review the patch this week, as soon as I have access to my dev environment.

Regards.

Hello,

It took more time than expected but I release the module.
I drop the link here, in case that interests someone: https://www.drupal.org/project/personal_views_access_control → .

I close the issue as you answered to my question.

Kind regards

Hello,

I would like also to know because I was about releasing a similar module when I found this one.
I developed it because I am working on another module that need such a feature.

The one I implemented proposes to restrict the access based on Views access plugins.
Actually 2 plugins:

1. One offering to restrict the views access to the current user matching the user parameter in the path or to users having a given permission.
2. One offering to restrict the views access to the current user matching the user parameter in the path or to users having given roles.

If the module here is still maintained and planned to be released soon, therefore I would not release my module in favour of this one. I can also help, if needed.

Regards.

Hi wombatbuddy,

Thanks for your prompt answer.

I will proceed so. It will be online for tomorrow EOD.

Kind regards.

jyraya → created an issue.