Authors and only authors see duplicate items after upgrading Drupal to 6.14

possible views cache issue? adminsiter -> views -> tools

I ask because I am not seeing this on my upgrade to 6.14.

Previous to Drupal 6.14, db_rewrite_sql was causing issues with DISTINCT:

http://drupal.org/node/284392

These issues are now fixed.

http://drupal.org/node/579476

Modules that were affected by this bugfix may need to be updated, for example, some node_access modules.

In the meantime, you should be able to modify your views to display only distinct items.

I am also having the same problem with my Views blocks. I am having the same row more than twice. Will it be fixed in the next version of Views or an update of core to 6.15 is required? Right now, I am using the distinct property of the Views to hide extra rows but since I have almost 30 of such blocks, it is a great pain.

I have a similiar problem! I also get those strange results after the 6.14 update!

For sure as admin you see everything correct, but when you see the pages as authenticated user this issue comes.

Same problem here. ALSO, adding DISTINCT: Yes does not affect my display at all. It doesn't even get added to the query.

Please read the submission guidelines and provide the information it requests.

I experienced this issue as well after upgrading to drupal 6.14. Changing "DISTINCT" to yes in each view's defaults fixed the issue for me. As always, after you make the change, clear your views cache before determining it doesn't work.

For a node type view only showing titles and node links for the last 6 nodes of a certain content type I get duplicate results for each result. The problem started right after updating D6.14 version. The query is:

SELECT node.nid AS nid,
node.title AS node_title,
node.type AS node_type,
node.comment AS node_comment,
DATE_FORMAT((FROM_UNIXTIME(node.created) + INTERVAL 10800 SECOND), '%Y%m%d%H%i') AS node_created_minute
FROM node node
LEFT JOIN comments comments ON node.nid = comments.nid
WHERE node.type in ('tartisma_konusu')
ORDER BY node_created_minute DESC


To be more exact, each title is displayed once for any comment. For example the first title is displayed 4 times because it has 4 comments. I think it is a problem that appears only on the views that has a relationship.

Duplicate rows are seen for all the users, and can only be corrected with "distinct: Yes" setting. I am also attaching the preview of the view.

#14: Well, the query would create dups. IT's joining in the comment table, but there's nothing there actually using the comment table, so that does not make any sense at all. Can you export the view that's generating that query?

I am attaching the export of the view as a txt file.

I don't even use relationship on this module. Strange...

Thanks for helping.

we also experiencing this issue after upgrade to 6.14
using Views 6.x-2.6

it seems to somehow relate to how many roles the authenticated user has.
for every role the user has, any view displayed on the page displays one copy of the view result row.

for example, the view result should be:
1
2
3
authenticated users that have only one role see exactly that. authenticated users that have 3 roles applied to them see:
1
1
1
2
2
2
3
3
3

no errors are ever displayed and non-logged in users see the views results correctly (i'm thinking because they only have one role applied to them.)

we tried adding the distinct: yes, and clearing views cache, but that had no effect.

experiencing the same problem, after upgrade to 6.14 all posts that were in group began to show twice, after disabling the module things have become normal

I've been experiencing the same issue: authors see their post in view twice, user #1 not affected by this issue.
Drupal 6.14 Views 6.x-3.x-dev
I've tried to modify the query but Distinct option in module admin panel seems not to work because query remains this one

SELECT node.nid AS nid,
node.sticky AS node_sticky,
node.created AS node_created
FROM node node
WHERE (node.promote <> 0) AND (node.status <> 0)
ORDER BY node_sticky DESC, node_created DESC

while exported view is

$view = new view; $view->name = 'frontpage'; $view->description = 'Emulates the default Drupal front page; you may set the default home page path to this view to make it your front page.'; $view->tag = 'default'; $view->view_php = ''; $view->base_table = 'node'; $view->is_cacheable = FALSE; $view->api_version = 2; $view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */ $handler = $view->new_display('default', 'Defaults', 'default'); $handler->override_option('sorts', array( 'sticky' => array( 'id' => 'sticky', 'table' => 'node', 'field' => 'sticky', 'order' => 'DESC', ), 'created' => array( 'id' => 'created', 'table' => 'node', 'field' => 'created', 'order' => 'DESC', 'relationship' => 'none', 'granularity' => 'second', ), )); $handler->override_option('filters', array( 'promote' => array( 'id' => 'promote', 'table' => 'node', 'field' => 'promote', 'operator' => '=', 'value' => '1', 'group' => 0, 'exposed' => FALSE, 'expose' => array( 'operator' => FALSE, 'label' => '', ), ), 'status' => array( 'id' => 'status', 'table' => 'node', 'field' => 'status', 'operator' => '=', 'value' => '1', 'group' => 0, 'exposed' => FALSE, 'expose' => array( 'operator' => FALSE, 'label' => '', ), ), )); $handler->override_option('access', array( 'type' => 'none', 'role' => array(), 'perm' => '', )); $handler->override_option('cache', array( 'type' => 'none', )); $handler->override_option('header_format', '1'); $handler->override_option('footer_format', '1'); $handler->override_option('empty_format', '1'); $handler->override_option('items_per_page', 6); $handler->override_option('use_pager', '1'); $handler->override_option('distinct', 1); $handler->override_option('row_plugin', 'node'); $handler->override_option('row_options', array( 'teaser' => 1, 'links' => 1, )); $handler = $view->new_display('page', 'Page', 'page'); $handler->override_option('path', 'frontpage'); $handler->override_option('menu', array( 'type' => 'none', 'title' => '', 'description' => '', 'weight' => 0, 'name' => 'navigation', )); $handler->override_option('tab_options', array( 'type' => 'none', 'title' => '', 'description' => '', 'weight' => 0, )); $handler = $view->new_display('feed', 'Feed', 'feed'); $handler->override_option('title', 'Front page feed'); $handler->override_option('style_plugin', 'rss'); $handler->override_option('style_options', array( 'mission_description' => 1, 'description' => '', )); $handler->override_option('row_plugin', 'node_rss'); $handler->override_option('row_options', array( 'item_length' => 'default', )); $handler->override_option('path', 'rss.xml'); $handler->override_option('menu', array( 'type' => 'none', 'title' => '', 'description' => '', 'weight' => 0, 'name' => 'navigation', )); $handler->override_option('tab_options', array( 'type' => 'none', 'title' => '', 'description' => '', 'weight' => 0, )); $handler->override_option('displays', array( 'default' => 'default', 'page' => 'page', )); $handler->override_option('sitename_title', '1');

I've tried to add or remove author's roles but the view display always the same issue : author post are displayed twice, except for user #1.
I'll try downgrading to drupal 6.13 to see if it's a core issue.

Update
switching to Drupal 6.13 the issue is not present.

Update 2
Back to Drupal 6.14, I solved it at the moment changing node_access module : I've left node author read permission unchecked, leaving the anonymous and registered user read permission checked

Does the workaround committed for Views 6.x-2.x-dev and 6.x-3.x-dev

http://drupal.org/node/501552

now cause problems for Drupal 6.14?

In the workaround, it's explicitly stated:

      // Hack in a check to see if node_access is going to add its own DISTINCT
      // and break this query.
      // See http://drupal.org/node/284392 for the core bug.
      //
      // We want to bypass views distinct code if this bug will be triggered so
      // if the base table is node and there is a node access module, bypass
      // views distinct code.

What happens if you reverse that workaround (patch -R)?

For Views 6.x-2.x-dev:

http://drupal.org/files/issues/views_node_access_distinct_bypass_2.patch

For Views 6.x-3.x-dev:

http://drupal.org/files/issues/views_node_access_distinct_bypass_3.patch

Changing status

I have the issue before and after applying that patch for the Views 2 version.

There's more discussion of this at http://drupal.org/node/284392 -- clearly this is widespread and probably a bug in that core patch.

My understanding is that the workaround in #501552 totally circumvents the user's selection/unselection of distinct results in dev versions of Views, including selections made through the Views UI.

It uses its own logic to determine if results need to be distinct or not.

Hence the discrepancy in the user's selection of disctinct results and the query that actually gets executed in #14.

So if you are using a version of Drupal with the #284392 patch, i.e. Drupal 6.14, you need to make sure that the version of Views you are using does not have the #501552 workaround. You can reverse the patch for dev versions, or if you are using Views 6.x-2.6, you should be okay.

Still, for certain situations, like the one in #8, wouldn't you then still have to manually set "Distinct: Yes"?

To recap, if you are using Drupal 6.14, make sure to do the following:

1. Use Views 6.x-2.6, or be sure to remove the #501552 workaround if you are using Views 6.x-2.x-dev or 6.x-3.x-dev.
2. Select "Distinct: Yes" where applicable.

That is correct. If node_access is being used, the query is forced to DISTINCT and you can't change this, because the node_access query will create dups without it.

If the desired behavior is

the query is forced to DISTINCT and you can't change this, because the node_access query will create dups without it

then don't you have to explicitly check for and force this?

As far as I can tell, there is no check to see if node_access is being used.

Even in the dev versions of Views with the patches listed above, distinct doesn't ever get set to TRUE unless distinct is explicitly set somewhere. The node_access check can't be in set_distinct if you want to force it to be set.

Does this patch produce the desired behavior, as you describe?

It is db_rewrite_sql() that does this forcing, not Views. It's outside the scope (and control) of Views.

subscribe

subscribe

I am having the exact same problem described in #11, using the Content Access module, but apparently it is a more general issue — I reactivated all contrib modules one by one and only when Content Access was activated did I get the display detailed in #11. BTW, for me it's not author-related, but rather permissions related, i.e. if a user has three roles and all of them are allowed to view a node, that user will see that node thrice. I solved it temporarily by adding "Distinct" all over the place, which works, but this does seem odd. Trying to understand what's going on here is totally beyond my skills.

Subscribe. (And confirming that the number of instances of a node in a view is related to the number of roles a user has).
I am using Views 2.6 and Drupal 6.14
Switching to distinct in all views solves it.

Subscribing.

I am having the same problem and can confirm as #4 and #25 suggest there is a permission factor here but I cannot identify exactly where it is. Authenticated users will see double or triple entries possibly related to revisions of the node. But if the user belongs to a role with all permissions such as User#1 or a developer role they will not see duplicates. I have not been able to identify which permission is solving the problem.

I do not think it is isolated to views. I am seeing it with nodequeues and on front pages where items have been promoted to the front page.

Izzy

Sorry for the duplicate, http://drupal.org/node/284392#comment-2064636

I have found that anyone with permission to administer nodes does not see duplicates or triplicates. Hope that helps those more knowledgeable squash this bug.

Izzy

confirming #29

Just confirming #29 too, forgot to mention that in my #25 :)

I think problem in #11 is the same I've described in http://drupal.org/node/410990#comment-2065102

I'm using Drupal 6.14 and views 6.x-2.6 and I'm seeing the problem with the duplicate entries. After applying the patch for -2.x from http://drupal.org/node/501552, the problem is gone.

#33 - yes, it works!

Subscribing

Yes, the patch in #33 solves all the problems I was seeing in node queues and other content.

Thanks,

Izzy

Subscribing

I am just curious if I apply the patch, and after that upgrading to D6.15 or any future version of core, will cause any more problems? Surely something has changed in the core with 6.14. What if they revert??

patch in #33 is not a solution. It is a workaround in the sense that it forces your view to enforce distinct option. You can achieve the same (without code changes) by selecting distinct option in the relevant view. But as the help with that option correctly say, there are performance implication using that option. So by using the patch in #33 you are enforcing distinct across all views, which may or may not be what you want.

Reposting the patch in #21 as requested. This is a patch for vanilla Views 6.x-2.6 and Drupal 6.14.

To recap, I had previously assumed that the db_rewrite_sql causing issues with DISTINCT was fixed, but there appear to be other problems.

As merlinofchaos stated in #18,

clearly this is widespread and probably a bug in that core patch.

The workaround code for this patch is actually taken straight from node/node.module for node_db_rewrite_sql:

/**
 * Implementation of hook_db_rewrite_sql
 */
function node_db_rewrite_sql($query, $primary_table, $primary_field) {
  if ($primary_field == 'nid' && !node_access_view_all_nodes()) {
    $return['join'] = _node_access_join_sql($primary_table);
    $return['where'] = _node_access_where_sql();
    $return['distinct'] = 1;
    return $return;
  }
}

so I don't think it will cause any unnecessary DISTICT queries, i.e. you still need DISTINCT queries for node_access queries.

However, since "it is db_rewrite_sql() that does this forcing, not Views. It's outside the scope (and control) of Views," this is still a workaround.

For those tracking the db_rewrite_sql causing issues with DISTINCT issue, please have a look at this patch.

Subscribing.

The core patch tested fine before the Views "workaround" was introduced. I still think we are stepping on each other's code. The core bug only affects Views queries, AFAIK.

Why does Views need a workaround at all? Why not just let Node Access do its job?

(Obviously, I think this issue is trying to solve the wrong problem.)

@agentrickard
Views need workaround because if you just let node access do the job, it still shows multiple listings in the view. Does this mean all node access modules should change?

Prior to 6.14, node_access would garble the query making it invalid SQL without the workaround. In 6.14, with the workaround, node_access fails to make the query DISTINCT the way it is supposed to. Whee. The patch in #40 then forces the query back to DISTINCT if node_access is in use, but this will cause 6.13 to produce a mangled query. We need to do version checking. No, this is not optional, I will not commit a patch that simply reverses the problem (i.e, right now we work on 6.13 and earlier and fail on 6.14; working on 6.14 and failing on 6.13 and earlier is unacceptable to me).

The db_rewrite_sql patch ostensibly fixed the long-standing issues with distinct, but a number of new problem cases arose when users upgraded to Drupal 6.14, as the existence of this thread would indicate.

I think the question now is what is causing those problem cases?

It was posited in comment #154 of the db_rewrite_sql thread:

Apparently the DISTINCT()-modifier is not added by db_distinct_field when the field has an alias.
I solved the problem by changing the regexp-replace slightly.

I think this is on the right track, as it would explain why users are not experiencing duplicates with /?q=node after upgrading to Drupal 6.14, while some users are experiencing new Views-related problems with all versions of Views.

If this is indeed the problem, then this should be resolved in core (or perhaps enforced through coding standards for node_access modules) and not in Views.

When I first created the patch in #21 (reposted in #40), I was working under the assumption that the db_rewrite_sql patch should have fixed any and all issues with distinct and node_access. Yet I could not figure out why distinct was still not getting set in some of the cases that others were reporting in this thread.

As it became more clear that these new problem cases were somehow linked to the db_rewrite_sql patch, I shifted my attention back there. For those tracking the db_rewrite_sql causing issues with DISTINCT issue, please have a look at this patch.

So to summarize, we need to figure out what is causing the new problems, and the answer is likely beyond the scope of Views. In the meantime, if you are experiencing new problems with duplicates and views after upgrading Drupal 6.14, then you can use the patch in #40, or set distinct for the problem views.

@ajayg - Then that is a core bug that needs fixing, not bypassing. The problem now is we have two incompatible fixes. You are misreading the issue.

@bl444137 - I agree. This needs to be fixed in core and the workaround removed from Views.

I'll try to carve out some time this afternoon to dig in to the patch, http://drupal.org/node/284392#comment-2068766, which is probably the correct solution.

Subscribing.

My tests indicate that reverting the Views workaround #501552: Provide workaround for core DISTINCT bug in db_rewrite_sql and committing http://drupal.org/node/284392#comment-2068766 will solve this issue for 6.14.

See notes here -> http://drupal.org/node/284392#comment-2075752

I don't think we need to worry about 6.13 since 6.14 was a security release.

I also think this issue should be closed, because this should not be fixed in the Views module, but in core. Marking as duplicate.

Subscribing. (#33 worked for me as well.)

subscribing.

Subscribing

You can't expect drupal to be upgraded all the time. see http://drupal.org/project/usage/461882

Use this to detect which version of core your running and execute the corresponding code

if (floatval(VERSION) <= 6.13) {
}
else {
}

Patch for Views 6.x-2.6 with version checking requested in #44.

This combines previous patches in #3 from 501552: Provide workaround for core DISTINCT bug in db_rewrite_sql
and #40 in this thread.

It assumes that the core bug 284392: db_rewrite_sql causing issues with DISTINCT will be fixed in future versions of Drupal.

The patch is empty :)

Weird. All I did was preview my post after I uploaded the patch...

Repost of the patch in #53 for Views 6.x-2.6 with version checking requested in #44.

+++ includes/query.inc	2009-09-25 01:52:06.000000000 -0400
@@ -877,6 +893,19 @@ class views_query {
+    if ((floatval(VERSION) == 6.14) && $this->base_field == 'nid' && !node_access_view_all_nodes()) {

Need to think about 6.14+

Beer-o-mania starts in -24 days! Don't drink and patch.

Right now, there are three different groupings of versions of Drupal that are affected by the bugs in 284392: db_rewrite_sql causing issues with DISTINCT. Those are:

1. Drupal versions up to 6.13;
2. Drupal 6.14 specifically; and
3. Drupal versions after 6.14 (where the problem will hopefully be fixed and this workaround won't be necessary).

We can only put checks in for versions where the bugs and behavior are known. If the core bug doesn't get fixed for Drupal 6.15, then the proper thing to do would be to re-roll this patch at that time.

For now, I think the check for Drupal 6.14 is correct:

+++ includes/query.inc 2009-09-25 01:52:06.000000000 -0400
@@ -877,6 +893,19 @@ class views_query {
+    if ((floatval(VERSION) == 6.14) && $this->base_field == 'nid' && !node_access_view_all_nodes()) {

#56: Actually, I think you are correct. We need to allow for the fact that we don't know which in version of Drupal the core bug will be fixed. We do know how Drupal 6.14 behaves.

So until then, we have to check for Drupal 6.14 and beyond, and then when the core bug is indeed fixed, re-roll this patch to adjust the checking for versions of Drupal where the behavior is known.

+++ includes/query.inc 2009-09-25 01:52:06.000000000 -0400
@@ -877,6 +893,19 @@ class views_query {
+    if (floatval(VERSION) >= 6.14 && $this->base_field == 'nid' && !node_access_view_all_nodes()) {

Patch in #53 for Views 6.x-2.6 with version checking requested in #44.

This patch works for me for Drupal 6.14 and latest dev views release, thanks a lot.
Igor

subscribing

Argh. Subscribing.

There appears to be a follow up patch in the original issue against Drupal that solves this problem. The workaround in Views only helps Views but not always, and it doesn't help other places that the problem occurs.

I'm leaning more and more toward not working around this at all, pointing people at this patch, and trying to convince Goba to release 6.15 as soon as that patch lands.

subscribing

Subscribe

subscribe

subscribe

subscribe

subscribing

subscribe

subscribing too....

subscribing

I'm using Drupal 6.14 and Views 6.x-2.6 and OG 6.x-2.0. Setting DISTINCT to true in the view did not work for me, but the patch in #55 did work. FWIW. Thanks for the patch, bl444137!

Subscribing

Let's use version_compare() and not floatval and let's check for 6.14 or greater

Nice, didn't even know about that function
http://php.net/version-compare

subscribe

Rerolled the patch for views-6.x-2.7, following mikeytown2's advice in #77.

Today, we upgrade to the 6.x-2.7 release. Authenticated users, but not admins see now all entries duplicated. All our views are set to be distinct, but still no change. We also cleared the site cache and we don't have views cache enabled for the different views. Any help is greatly appreciated!

Update: It seems to be interrelated with OG. In case the authenticated user is a member of a group, the user will see duplicates of all group posts. Otherwise, the post is only shown ones.

Thanks for this patch, it works for me.

I am on D6.14 and Views 2.6 was giving me distinct rows, after upgrading to Views 2.7(10 minutes ago) my duplicate rows came back(even tho distinct was set to yes). After applying this patch, I now have distinct rows again.

Thanks.

I second #81 TechnoBuddhist's comment.

Same problem. Subscribing.

Subscribe.

I third #81's comment. What Views 2.7 broke, patch #79 fixed.

Same problem. Subscribing.

Subscribe. Patch #79 seems to have solved my problem as well.

subscribe

views 2.7 conflicts if core patched with http://drupal.org/node/284392 db_rewrite_sql causing issues with DISTINCT
effect: dublicated posts and for some views, missing pagers, no patch here restored missing pagers on 2.7, back to 2.6

This is a duplicate of both #501552: Provide workaround for core DISTINCT bug in db_rewrite_sql and the core bug #284392: db_rewrite_sql causing issues with DISTINCT.

Confirming #28 & 29 - this is exactly what I'm seeing as well.

Subscribe.

Problem: anonymus users see view twice, logged in users see it normal.

My solution ' till now: going back to 2.6

Subscribing - just in case someone opens this up again. I had to apply the patch from #79 after upgrading from 2.6 to 2.7 to get a working system ...

Edit: Just applying that patch brought up other problems (new-posts-count not working anymore in og_my). I am back to plain 2.7 and experimenting with #284392: db_rewrite_sql causing issues with DISTINCT

I was seeing this with 6.14 and views 6.x-2.dev from some time in October, but with both anonymous users and user id 1. switched to 6.x-2.7 and applied patch in #79 and I now see distinct views. I had also turned on "reduce duplicates" in the taxonomy filter and that did nothing before as well.

Patch #79 works for me after upgrade to 2.7. Thanks @Boobaa

#79 Patch worked for me too.

subscribing.
I also confirm #29. When I gave a test role "Administer Node" and gave this to a user that had the problem, I no longer saw dupliates.
I only started to see duplicates after I updated a node (I'm also using Storm and Workflow).
I have no revisions for this content type and my view only contains basic node information (not workflow).
User1 sees no duplicates.

+1
Patch in #79 worked fine.

#79 Patch worked for me as well. I upgraded manually with no issues.

I initially noticed the problem in Views 6.x-2.6. I corrected the problem by setting Node:Distinct. Problem resurfaced upon upgrade to Views 6.x-2.7 with Node:Distinct still set.

A note for those who, like myself, are not too quick on the uptake. The patch should be placed in /sites/all/modules/views/includes/query.inc since this is a patch to the Views module, not core. I know this should be obvious, but I spent about 15 minutes wondering where /includes/query.inc was before it dawned on me.

Another confirmation that patch #79 works.

Thanks your very much boobaa Patch #79 works, i hope this error will be fixed in the next release

Confirming patch #79 is working!
Thanx a million (yes that's a lot but i really thank you :) )

Cheers

I'm really confused now. I got the same problem on my page, but this issue is closed because it's a duplicate of #501552: Provide workaround for core DISTINCT bug in db_rewrite_sql, but there merlinofchaos points here. Circular dependency I'd say. What should people facing this problem do?

Subscribing.

+++ includes/query.inc	2009-11-03 14:59:47.000000000 +0100
@@ -900,6 +904,19 @@
+    // Since this bug has different implications for Drupal pre-6.14
+    // and 6.14, we need to include a check for Drupal's version.
+    if (version_compare(VERSION, '6.14', '>=') && $this->base_field == 'nid' && !node_access_view_all_nodes()) {
+      $this->distinct = TRUE;
+    }

This should probably be '== 6.14'. This subtle bug introduced in 6.14 is a release blocker for 6.15.

This review is powered by Dreditor.

Oh, and that need a reroll because the original workaround committed in #501552: Provide workaround for core DISTINCT bug in db_rewrite_sql has been rolled back.

I am also confused.

The patch in http://drupal.org/node/284392 appears to solve the problems and works with Views 2.7
I do not see duplicates even to author. Distinct is set to "no".

I tried the patch from http://drupal.org/node/284392 and it didn't do the trick for me.

The patch in #79 did, thanks Boobaa, you saved my sanity for another day.

Better still, I don't even need to set Distinct to Yes as applying this patch straightened out the duplicating issue without it.

With core 6.14 and Views 2.7, even when I checked "distinct" there was no "DISTINCT" being added to the SQL that gets generated. The patch in #284392-257: db_rewrite_sql causing issues with DISTINCT did not help.

The patch in #79 in this issue fixed it, and the DISTINCT was added to the SQL properly.

I have no node-access modules installed.

*sigh*

Crell, the patch preventing Views from adding DISTINCT was rolled back after 2.7

Ah, so this issue itself is fixed in dev?

@crell,
NO. the issues was rolled back because the fix needs in core. #284392: db_rewrite_sql causing issues with DISTINCT is where it will be fixed. There is already a patch in that issues which seems to be working for people who have tested and reported.

if that patch hasn't fixed your issue, then perhaps you should report your use case and what you observered which may help it make better.

This is another confirmation that the patch in #79 worked for me (after I had updated to views-6.x-2.7). Thanks.

I first thought this patch would have solved my issues, but I found out (days later) that the "new post" counters on my groups-block had disappeared together with the duplicates. Uhm ... I am now running the core-patch from #284392: db_rewrite_sql causing issues with DISTINCT and everything seems to be fine. I therefore would advise you guys not to patch the views-module and patch core instead, as this is also where the final fix will be. I also set this back to duplicate to give others a more obvious hint to the "real" patch ...

Similar issues with User1 and people with admin nodes having no problems and people with multiple roles seeing about as many items as roles they're assigned to, and distinct failing to be distinctive. Patch in #79 fixed duplicates issues, thank you :)

Now to work out why better select suddenly stopped taking over Views generated multi-select boxes...

The problem is with core, not Views.

You need two things:

1) the patch to core
2) The reversion of the patch that broke DISTINCT handling in Views. 2.x-dev currently contains this and should be okay to use.

The patch from this issue will not be committed to Views; at this point, there is no need. I would rather just tell people to patch core and wait for 6.15 to come out.

confirming Patch in #79 works on Drupal 6.14 with Views 6.x-2.7

Having the same problem but for Anonymous users. I have Domain access and Node Access modules

Patch from #79 solved my 6.x-2.7 problem. Thanks!

Could you please stop posting here ? THIS IS CORE ISSUE. Unless Drupal.org has "unsubscribe" feature, this is very annoying.

unsubscribe from the queue = http://drupal.org/project/issues/subscribe-mail/views

the subscribe/unsubscribe link is on the main issue entrance of every project. ie at the top of http://drupal.org/project/issues/views

I didn't mean "mail subscription". I mean when someone posts here, it bumps it to the top of "my issues".

I agree with crea. I am locking this issue.