Deprecated function: explode(): Passing null to parameter

It looks like this is null:

$alternativeRoles = $route->getRequirement('_current_user_roles_access_check');

I'm not familiar enough with the module, but maybe it's a setup issue.

I had gone through the issue and added the fix please review.

#3 patch works.

The patch looks like it would work, but perhaps someone would look into *why* there's the issue. If it's because the user hasn't correctly set up the module, then perhaps that should be pointed out to the user.

I used the default settings allowed by the module, I didn't change anything else.
I don't know what else could cause it.

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.

hi y'all,

I use this module in a scenario to show spesific node type to only author (current user) or editor/admin roles.
Author or editors willl see xnodes on user profile .
Thanks to Jyraya & Keshavv , the module solved my problem. The patch is working. There doesn't seem to be a problem at the moment.
I use it with "Current user or role(s) configuration" on Drupal 10.1.2 & PHP 8.1
view path like this : /user/%user/xnotes
Relationship: User (Require this relationship:YES)
Contextual filters:User ID (relationship:User) with settings: Provide default value >>(User ID from logged in user)

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.

Hi jyraya ,
Sorry for the late answer.
There are lots of modules. It would be hard to give the whole list here.
Anyway, maybe it's because of this.
I am using Global: View area. In this area at views header. I am pulling some basic information of the logged-in user, which cannot be an access problem, where the information of the logged-in user is. Or not restricted fields for editor or admin. Simple fields like image,about information of logged-in user.
The purpose here is to allow the editor or admin to see a little more information about the profile related while they are looking at this view.But I don't think it's related to this part.

As you requested, I tested other view permissions( role, etc). There's no problem such as mention above.
If I find any other issues or relevant evidence, I'll post.
Thanks.

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.

OK, I found the problem.
I removed patch. I tested by removing all relations,c-filters or arguments on the view one by one.
It's funny :)) I finally found the source of the problem.The problem is not caused by another module.

The source of the problem:
If you are using a menu on view and configuring it as a menu tab, the above problem occurs.
I didn't test other menu options. Maybe only menu tab option or maybe whole view menu part causes this problem.

When you remove the menu, the problem disappears, but the menu is needed to get real efficiency with the module.If someone is using the module, it should be considered whether the patch actually fixes the problem or hides the warning.

Thanks, Have a good night

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.

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.