Problem/Motivation
In the Moderated Content view on the Group content items aren't shown except when the user has the `bypass node access` permission.
The issue appears to be due to the "Respect group content unpublished permission" filter. The filter adds a "where" expression to the views query that is supposed to restrict the nodes listed to those of the types available to the group:
$snippet .= "
(($table.uid = ***CURRENT_USER*** AND ***CURRENT_USER*** <> 0 AND group_relationship_field_data_node_field_data.type='group-group_node-$nodeType' AND :own_unpublished_$nodeType)
OR
(group_relationship_field_data_node_field_data.type='group-group_node-$nodeType' AND :all_unpublished_$nodeType))";
However, in the table `group_relationship_field_data`, the `type` column's value begins with the group's Group Type id, and that is not always going to be "group". If the Group Type is "Department", then the value may be `department-group_node-page`, rather than `group-group_node-page`.
Steps to reproduce
- Set up a default moderation flow
- Create a new role, assign the permissions to moderate content
- Create a draft content item
- As any user without `bypass node access` permission, view the Moderated Content view
- You should see the draft content item, but in fact you don't
Proposed resolution
Fix the `GroupContentRespectUnpublished` views filter plugin to use the group's Group Type id in the query:
$groupTypeId = $group->getGroupType()->id();
$snippet .= "
(($table.uid = ***CURRENT_USER*** AND ***CURRENT_USER*** <> 0 AND group_relationship_field_data_node_field_data.type='$groupTypeId-group_node-$nodeType' AND :own_unpublished_$nodeType)
OR
(group_relationship_field_data_node_field_data.type='$groupTypeId-group_node-$nodeType' AND :all_unpublished_$nodeType))";Issue fork gcontent_moderation-3471105
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
xrobp commentedComment #3
xrobp commentedComment #4
xrobp commentedComment #5
xrobp commentedComment #7
xrobp commentedComment #8
slydevil commentedComment #9
slydevil commentedWorks! Thanks @xrobp.
Comment #12
msnassar commentedFor now we should ignore the failing tests in D11 builds. This is going to be fixed in another issue.
The tests using D10 are passing, this demonstrate that our tests are not good. So in order to demonstrate this issue, lets write a test that fails .
BTW, from group 2, I think we might not need this views plugin anymore! But lets demonstrate this later in another ticket.
Comment #13
msnassar commentedNow we have a failing tests... Lets have them passing by fixing the reported issue.
Comment #14
msnassar commentedI have cherry picked the fix from MR21. Now the tests are green again...
I think the exiting code in this test can be improved... Anyway, the next step is to demonstrate that we might not need this views plugin anymore!
Comment #15
andras_szilagyi commentedLooks good
Comment #17
keszthelyi commentedTested the fix in MR!28 and it solved the issue +1
Comment #23
hernani commentedMerged !
Thank you !