Views only display nodes in the default language when a node access module is used

This would apply, in theory, to any node access module. However, it may be a special case with Domain because we found the original 'fallback language" security issue and worked around it. (See https://www.drupal.org/sa-core-2018-001).

That said, adding this metadata is also appropriate.

I've similar problem with dev version of view_unpublished module

the dev version is needed otherwise the views_unpublished module has this bug

I need to split the condition used by @Skymen in comment #5 otherwise the check gives a false result, so attached a new patch

With this patch, I've a behat test broken for a project with this message:

Drupal\Core\Database\InvalidQueryException: Query condition 'na.langcode = ()' cannot be empty. in Drupal\Core\Database\Query\Condition->condition() (line 103 of core/lib/Drupal/Core/Database/Query/Condition.php).

attached an improved check

I tried patch from comment #9 and it works as described unless you have 2 languages selected in your views language filter (e.g. " Interface text language selected for page" and "Not specified"). Then the query breaks and you get a wsod.

Attached a patch that address also the problem described on #11

All previous patches do not work correctly because they "hardcode" the filter name and do not check that the filter is applied to the nodes.

For example I need to filter the language of a related taxonomic term present in the node, but previous patches use this filter for add a 'na.langcode' filter.

Patch #14 works for me!

Patch 14 works, but the solution should be taken into account the filter option "in", "not in".

Check operator before applying the language to the access query.
https://git.drupalcode.org/project/drupal/-/merge_requests/1934/diffs

         if ($filter instanceof LanguageFilter &&
            $filter->table == $base_table &&
            in_array($filter->operator, ['in', 'not in'])
          ) {
            $operator = $filter->operator;
            $langcode = !empty($filter->value) ? $filter->value : FALSE;
          }

Ploblem still present on D10.1.1 with views_unpublish module.
I create a patch for D10.1.1

Patch #26 fixed the issue for me.

We encountered this same issue in the context of the module we are developing https://www.drupal.org/project/access_by_taxonomy

Our module adds grants that are based on the taxonomy terms added to a node (can be role or specific user). We add these grants also based on translation.

The case where we see a problem in views (Compared to the actual access of the node when trying to visit it directly is this):

1. we add a node with some restrictions, saying that it should be visible for a given user role, set the node as unpublished
2. we add a translation to the node, publish the translation

Now, all users of the role that is specified for access should see the node in views: in this case they should not see the original version, but they should see the translation.

When doing an entity query or a view, the translation is not returned, because the table is checked with fallback = 1

This is an example of the query:

SELECT "node_field_data"."created" AS "node_field_data_created", "node_field_data"."nid" AS "nid", "node_field_data"."langcode" AS "node_field_data_langcode"
FROM
{node_field_data} "node_field_data"
WHERE (("node_field_data"."type" IN ('article')) AND ("node_field_data"."langcode" IN ('it'))) AND (EXISTS (SELECT "na"."nid" AS "nid"
FROM
{node_access} "na"
WHERE ((("gid" IN ('0')) AND ("realm" = 'all')) OR (("gid" IN ('2', '3')) AND ("realm" = 'access_by_taxonomy_role')) OR (("gid" IN ('4')) AND ("realm" = 'access_by_taxonomy_user')) OR (("gid" IN ('4')) AND ("realm" = 'access_by_taxonomy_own_unpublished')) OR (("gid" IN ('4')) AND ("realm" = 'access_by_taxonomy_owner'))) AND ("na"."grant_view" >= '1') AND ("na"."fallback" = '1') AND (([node_field_data].[nid] = [na].[nid]))))
ORDER BY "node_field_data_created" DESC
LIMIT 11 OFFSET 0

The node_access table looks like this:

10,en,1,1,access_by_taxonomy_view_any_article,1,0,0
10,it,0,1,access_by_taxonomy_view_any_article,1,0,0
10,en,1,3,access_by_taxonomy_owner,1,0,0
10,it,0,3,access_by_taxonomy_owner,1,0,0
10,en,1,3,access_by_taxonomy_own_unpublished,1,0,0
10,it,0,3,access_by_taxonomy_role,1,0,0

The user has the grant `access_by_taxonomy_role` with the correct rid, so it should be able to see the node. However. there is no row with fallback = 1 that grants access, so the italian translation of the node is not shown in the view, even though the user would have access to it.

The patch allows us to see the translated version of the node if the view has a language filter set.

(for the admin/content view, that does not have any filters initially (unless you use an exposed filter) this is still an issue.. I wonder if this a corner case that the whole system just does not support)

This patch causes issues on 10.3.*, due to the changes done in issue https://www.drupal.org/project/drupal/issues/1349080.
Is this patch still necessary?

I'm pretty sure it is still needed as I had to reroll it and use it - altough I'm using my own slightly expanded version of this https://git.drupalcode.org/project/drupal/-/merge_requests/1934/diffs which also covers relationships (I think, it was long time ago)... maybe the basic issue is resolved, I may test it some day.

Meanwhile, here is the patch I'm using with 10.3 (no guarantees, it simply works for me) if anyone wants to try it.

Updating tags, we'll need some steps to reproduce what sounds like a bug (should this be recategorised from Task?) and test coverage.

Just ran into this "bug".
Both in Drupal 10.4.7 and 11.1.7.

I have a view that list the most recent node, filter by published flag and filtered by the content language.
The most recent node is translated, the original language is Dutch, the translation is French. The Dutch language has been unpublished.

I have create a page that shows the view, that page is translated.

When viewing the page with the view in French:
as administrator I get the correct French node as most recent.
as anonymous user I do not get the same node, but 1 older. (in French)

As both admin an ano user I can directly access the published French translation of that most recent node, so no problem there.

Applying the patch from #30 fixes the issue for us.

We are running several node access related modules, but the only one that actually generates entries in the node_access table is view_unpublished. After removing that module the behaviour did not change.
I also tried removing all modules that do something access related, the behaviour did not change.

So for us, this is still a bug and the patch does fix it.

This does sound like a bug.

That said, the current patch, which couples the node grant storage to the views API, is a non-starter. I think this would be more properly fixed in the node views handlers somewhere.

Setting active and hiding the previous patches since we can't really build on that approach. Thanks!

The patch from #30 causes issues with relationships / contextual filters in combination with a language filter: so not a good solution.

I went a bit deeper here to try and find a working solution.

So, if there is a grant system active "NodeGrantDatabaseStorage::alterQuery()" adds an EXISTS ( ... ) part to the query (or joined query for relations) that checks if the current user has access to this node via the node_access table's grants.
It can also filter this based on the langcode if the query has the metadata "langcode" set to the corresponding language to filter on.
This part is not correct, since each individual row in the result of the query can have it's own langcode and should be matched to the node_access table. (if it defines the langcode)

The correct solution is to bind the langcode in the node_acces table to the main query so each row is correctly checked.
The langcode in node_access table seems to be optional, so we also need to bind it together if there is no langcode set.

I have made a patch that does this, see attached. (made against Drupal 11.2.4)
Only thing I am not sure about is the "fallback", this can be defined in the grants table and I am not sure how to correctly implement it.

Updated the patch.
Seems that other entities that uses nodes can have their own base_table and do not have to include a langcode. This is possibly a whole other issue, but might as well try and catch that here. So, for now, I only handle node_field_data as base table differently.

I noticed this issue in the forum module, which uses nodes as storage, but a forum_index as base_table and that one does not have a langcode field.
Probably it should have that because access checking will not work correctly for forum nodes bases on my patch... But without the patch it is also not working correctly...
Wondering if nodes using their own base_table should be required to have a langcode?

Correct patch, had the path core/modules/node wrong, sorry.

@weseze the patch https://www.drupal.org/files/issues/2025-10-15/3061782-39.patch only works when the base table is node_field_data, o our case, "node", the langcode filter does not apply.

The new patch is a mix of comments #30 and #40

Update the patch to respect the multilingual condition

Create a new MR against main.