project/issues/user a 404 when not logged in

Fixing this will depend on a patch to views to let you return a 403 when a views argument is missing or invalid. Currently, 404 is the only option like this. Not sure if a feature request already exists for this in the views issue queue or if we need a new one. I'm also not sure how hard adding such an option to views would be -- a very quick skim of the code doesn't look too promising. Views basically only has a notion of an argument causing a view to "fail", which each display handler decides what to do with. The page display thinks "fail" == 404. So, it's probably going to involve some rather far-reaching changes to views to allow both 403 and 404 style failures. Earl's not answering in #drupal-views right now, so this will have to wait for Monday at the earliest. My guess is this isn't going to happen anytime soon...

Yay. I hung out with Earl tonight to talk about project* views stuff, especially this issue. Turns out that thanks to the cool helper function I wrote at #369505: Add helper function to get the value of a view argument, it's now relatively easy to write views access plugins that can know about argument values and return 403 in the right circumstances. It's going to be a little bit of trickery, but it should be relatively easy to make this work. Basically, we'd define our own access plugin for this (something like "View per-user issue queues" in the UI), add an option to define which argument to use for the access check, etc. Then in the appropriate access methods, check this option, call the helper to grab the current (validated) value of that argument, and do our logic to decide if the given $account should have access to see the per-user issue queue for the given argument. I should hopefully be able to work on this sometime on Friday @ DCDC, if all goes well. See also #367297: Restrict users from viewing other users signups, which needs to be solved in almost exactly the same way.

sub

Try these as an anonymous user:

http://d6.drupal.org/project/user
http://d6.drupal.org/project/user/dww
http://d6.drupal.org/project/issues/user
http://d6.drupal.org/project/issues/user/dww

This was a little more tricky than I hoped. I've got to figure out if there's a good way to move parts of this into views core to make it easier for other folks who need similar functionality. But for now, this works.

works on the test site, code looks ok as far as my views knowledge goes (which isn't that far yet).

i read this description four times and it still didn't make sense to me:
'#description' => t('You must select which argument to this view represents the user the issues are associated with.'),

perhaps that can be clarified a bit?

Yeah, those UI messages are pretty crappy -- I just threw them together without much thought. Here's what it's about:

The access plugin needs to know which views argument to use for its logic to determine the user. The access plugin then tests the value of the argument when doing the logic to figure out if that user should have access to the view or not. So, when you configure the access plugin, you have to point it to one of the arguments of the view.

Does that help explain what this setting is about? Given that, any suggestions on a way to say that concisely? ;)

We went with 'Select which argument represents the user whose issues this view will display'. Committed to HEAD. I'll mark this fixed when it's deployed.

didn't mean to wipe out that tag, sorry.