My mistake, was not applying due to another patch being applied.
This patch wasn't applying cleanly for me so I updated it for latest 3.6.
This has been resolved with the modules' latest releases.
Updated some of the older verbiage/commands and removed references to a deprecated module that's now just refereed to as Migrate Tools.
The permissions for this role in question are set to: "Use the Moderation Dashboard" but not "View any Moderation Dashboard".
I think the issue is the canonical user route has a user object parameter, while the moderation dashboard view page only has the user id.
In the access method of src/Access/ModerationDashboardAccess.php, $current_user_id = $this->routeMatch->getParameter('user'); can either be the user object or the user id depending on the route, from what I found. As you can see in the module's Access class below, if a user object is pulled from the route, the access conditionals are not met, which ends up forbidding the local task link on the user page. See a side by side of the two different params returned from the route in Screenshot 2023-02-16 at 12.12.02 PM.png
public function access(AccountInterface $account) {
$dashboard_owner = $account;
$current_user_id = $this->routeMatch->getParameter('user');
// If the current user is on their own dashboard, they can view it.
if ($current_user_id === $dashboard_owner->id() && $dashboard_owner->hasPermission('use moderation dashboard')) {
return AccessResult::allowed();
}
// If the given user doesn't have a dashboard, nobody can view it.
if (!$dashboard_owner->hasPermission('use moderation dashboard') && !$dashboard_owner->hasPermission('view any moderation dashboard')) {
return AccessResult::forbidden('User does not have access to view this dashboard.');
}
// But they can only view the dashboard of others with another permission.
if ($dashboard_owner->hasPermission('view any moderation dashboard')) {
return AccessResult::allowed();
}
else {
return AccessResult::forbidden();
}
}
A I think a better alternative would be to use getRawParameter('user') to always pull the user id.
Sorry, there’s no error. My user cannot access the Moderation Dashboard from the local task menu on their profile page.
My user's profile page (/user/ID) returns an object as the route parameter where as the moderation page returns and id. In src/Access/ModerationDashboardAccess.php, a check against an id is done. Since I have a user object, that conditional fails for me. Drupal 10.1 as well.
Adding a conditional that checks for subfolder paths in `getSitePath()` in order to fix a redirect issue when nodes are created for registered or published sites.
Fixes validation and alias generation issue
I've refactored this based on your suggestion to use path aliases. The code still needs constraint validation among other improvements and tests, but it seems like a good [re]start and would appreciate any additional feedback. Thanks!