Okay, I'm having a bit of trouble with this view. I've got a menu tab on the user's My Account page, with a view of the content they've created. My difficulty is in making the title of that page "Username" instead of a static "My content".

I figure that besides the User:Uid argument I also need a User:Name argument. The page title would thus be "%2". Since the argument won't actually be present, I need to provide a default argument. This may not be the best way of returning the user's name (the user whose My Account page is being viewed), but it's what I've got as the PHP to return a default argument:

$myuser = arg(1);
$result = db_query('SELECT * FROM {users} WHERE (uid = "' .$myuser. '")');
$usr = db_fetch_object($result);
return $usr->name;

However, the query that Views shows being executed is

SELECT node.nid AS nid,
   node.title AS node_title,
   node.created AS node_created
 FROM 7dp_node node 
 INNER JOIN 7dp_users users ON node.uid = users.uid
 WHERE (node.type in ('product')) AND (users.uid = 1) AND (users.name = 'n')
   ORDER BY node_title ASC

where n in "(users.name = 'n')" is a UID -- not the user's name.

Now, I could have done something wrong. But I'm marking this as a bug, since if my PHP is simply

return "administrator";

the query being executed includes "(users.name = '1')". I get no records returned, although %2 returns "administrator" for the title. I'm no expert, but it seems to me that the search for users.name should be for "administrator", not "1".

I'm using a User validator and accepting either "Only allow string usernames" or "Allow both numeric UIDs and string usernames".

If this isn't a bug, though, please tell me where I've gone wrong.

CommentFileSizeAuthor
#6 744468.patch1.77 KBeporama
#2 744468.patch2.17 KBeporama
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mrtoner’s picture

This appears to be a duplicate of another issue that's nearly a year old, #406666: 'User: Name' argument generating a wrong query?. I'm going to mark that one as the duplicate, since it was never resolved and mine is more recent -- and perhaps it will get more attention.

(Merlin, you missed the real problem in that issue, the fact that the query appears to have been built incorrectly. The patch there was a just a workaround; the issue needs a fix.)

Based on the OP's finding of a problem in the validator, I was actually able to work around my issue by changing the validator for User:Name to PHP:

return TRUE;

Not sure why this works, but now my user/%/content pages both list the appropriate nodes and are titled with the user's name.

Would appreciate feedback on the bug, though.

eporama’s picture

Version: 6.x-2.8 » 6.x-2.x-dev
FileSize
2.17 KB

The validator seems to be assuming that you're using User: UID as the argument. Even when you do set User: UID as the argument, you can still set it to accept numeric (uid) or string (username) for the parameter passed in. If you're using User: Name as the argument and validating as a valid User, you can achieve the same functionality by switching to User: UID.

However, if you wanted to have the argument of User: E-mail (or any other User argument field) you can't validate as a valid User since currently validate_argument() in views_plugin_argument_validate_user.inc is hard coded to "name" and "uid" fields and always returns uid.

Here's a patch that validates against the field of $this->argument->options['field'] which is the argument field (e.g., User: E-mail => mail) and returns $this->argument->argument = $account->{$arg_fld} (where $arg_field => $this->argument->options['field']).

I agree with merlin's comment that if possible, you should use User: UID as this is the most performant, but it does seem odd that it would only work for User: UID. This patch shouldn't change the performance of using User: UID as the field in this case would be uid which is what the original functionality worked with anyway.

eporama’s picture

By the way, setting the validator to simply return TRUE; means that you're not actually validating the argument. You're just passing everything that comes in. The validator returns false when it fails, but sets some variables and then returns TRUE if it passes.

dawehner’s picture

Status: Active » Needs review

Update status. Please mark issues and needs review, then people will look at it :)

dawehner’s picture

Status: Needs review » Needs work
+++ views_plugin_argument_validate_user.inc	2010-05-22 09:09:23.000000000 -0400
@@ -59,6 +59,8 @@ class views_plugin_argument_validate_use
+    $arg_fld = $this->argument->options['field'];

Don't use such shortcut names

+++ views_plugin_argument_validate_user.inc	2010-05-22 09:09:23.000000000 -0400
@@ -74,7 +76,7 @@ class views_plugin_argument_validate_use
+        $where = $arg_fld.	" = '%s'";

Why do we need a tab here? This code looks broken.

Powered by Dreditor.

eporama’s picture

Status: Needs work » Needs review
FileSize
1.77 KB

Thanks dereine! Still fairly new to providing patches, so appreciate the help. I rerolled not using the shortcut variable and fixed the formatting.

I also redid the patch from the top of the views directory, is that better or not necessary?

Powered by Dreditor.

dawehner’s picture

Just in general this issue would be worth to be simpletested :)

eporama’s picture

And since I'm also new to simpletesting... My plan is to write a new test function for viewsArgumentValidatorTest in the views_argument_validator.test file. It doesn't appear that there is a test for Validator: User at all, so first to write that and then can check to see whether or not my patch should introduce any new test requirements, but at least doesn't break the test.

function testArgumentValidateUser() {
...
}

Just want to make sure I'm not going about this all wrong... Thanks

eporama’s picture

Status: Needs review » Needs work

well, glad I wrote the simpletest above... Cause this patch causes it to fail ;-)

Turns out that with my patch, we're assuming that the argument has user information (name, mail, etc.) but the test is written against a "Global: null" argument. Guess you could have a null argument and still want to validate it as a User (that's what the test does).

However this patch calls $account->{$this->argument->options['field']} which produces $account->null and that get's warnings and then some of the tests actually fail. So until I sort that out, setting back to needs work.

webfunkin’s picture

any progress here?

dgsiegel’s picture

subscribe

MustangGB’s picture

Status: Needs work » Closed (won't fix)