"Submitted by" filter only showing tickets assigned to the requested user

1) http://drupal.org/project/issues/search/xmlsitemap
2) Select the "Submitted by" field
3) Type "Kiam"
4) Arrow down in the autocomplete choices to "Kaim@avpnet.org"
5) Click "Search"
6) See results:

http://drupal.org/project/issues/search/xmlsitemap?text=&assigned=&submi...

That's not the bug you reported, so I didn't see that was the problem. ;) To quote:

when I fill the Submitted by field the search doesn't return any report

Given that and a generic title of "Advanced project issue search doesn't work" I saw that you could enter something, it did give you a report, and therefore, it was working.

However, looking closely, there is a bug here. The underlying query is identical if either the "Submitted by" or "Assigned to" filters are used. Trying to search for "Project" issues submitted by or assigned to me, the query is always this:

SELECT node.nid AS nid,
node.title AS node_title,
history_user.timestamp AS history_user_timestamp,
history_user.nid AS history_user_nid,
node.created AS node_created,
node.changed AS node_changed,
project_issues.sid AS project_issues_sid,
project_issues.priority AS project_issues_priority,
project_issues.category AS project_issues_category,
node_project_issues__project_release_nodes.version AS node_project_issues__project_release_nodes_version, node_project_issues__project_release_nodes.nid AS node_project_issues__project_release_nodes_nid,
project_issues.component AS project_issues_component,
project_issues.nid AS project_issues_nid,
node_comment_statistics.comment_count AS node_comment_statistics_comment_count,
node.type AS node_type,
node_comment_statistics.last_comment_timestamp AS node_comment_statistics_last_comment_timestamp,
users_project_issues.name AS users_project_issues_name,
users_project_issues.uid AS users_project_issues_uid
FROM node node
INNER JOIN project_issues project_issues ON node.nid = project_issues.nid
INNER JOIN users users_project_issues ON project_issues.assigned = users_project_issues.uid
LEFT JOIN node node_project_issues ON project_issues.rid = node_project_issues.nid
INNER JOIN node node_project_issues_1 ON project_issues.pid = node_project_issues_1.nid
LEFT JOIN history history_user ON node.nid = history_user.nid AND history_user.uid = ***CURRENT_USER***
LEFT JOIN project_release_nodes node_project_issues__project_release_nodes ON node_project_issues.nid = node_project_issues__project_release_nodes.nid
INNER JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
WHERE (node.status <> 0 OR node.uid = ***CURRENT_USER*** or ***ADMINISTER_NODES*** = 1) AND (users_project_issues.uid in ('46549')) AND (project_issues.pid = 3281)
ORDER BY node_comment_statistics_last_comment_timestamp DESC

In both cases, the additional WHERE clause is this:

users_project_issues.uid in ('46549')

However, the submitted by filter is *not* using a relationship, so it should be restricting to {node}.uid or at the very least users_node.uid:

 'uid_1' => array(
    'operator' => 'in',
    'value' => '',
    'group' => '0',
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => 0,
      'operator' => 'uid_1_op',
      'identifier' => 'submitted',
      'label' => 'Submitted by',
      'optional' => 1,
      'remember' => 0,
      'reduce' => 0,
    ),
    'id' => 'uid_1',
    'table' => 'users',
    'field' => 'uid',
    'relationship' => 'none',
  ),

I think this is a bug in views, but I'm going to ask merlinofchaos to take a look and let me know if I'm doing something wrong in project_issue.

dww: Try this patch. http://drupal.org/node/386986#comment-1303234

Please check *every* view, particularly with relationships, and make sure that the results do not change. I'm not 100% sure that this will be without ramifications, but I believe it should be.

@merlinofchaos: #386986-2: 2 or more relationships can block a normal table from adding

This is blocked on #386986: 2 or more relationships can block a normal table from adding getting fixed in views itself.

#386986: 2 or more relationships can block a normal table from adding is now committed, yay. We just need to deploy a new version of views on d.o and this should be fixed.

Has a new version of views been deployed yet? If not, this issue probably should go into the d.o infrastructure queue, since there's no problem with the project_issue module itself.

Not yet, but it's high on my list. However, I find that things marked "needs work" with the "needs drupal.org deployment" tag are easier to deal with if they stay in their "own" issue queues... Sorry for the noise, part of the cost of being a module we run on d.o. ;)

Just upgraded d.o to views 6.x-2.5, so this is totally resolved... yay.