cron handled mail always tries to post as anonymous regardless of fromaddress

No solution, but I believe I am experiencing the same problem. I traced it a bit further, but I think your appraisal is about right... node_access calls the specific node type module access function (story_access in my case), which in turn calls user_access. The user variable is a global there, which says to me that the function is used for "what user is logged in" versus "what user I tell you", if that makes sense. Perhaps using a different node type would fix this. If I find anything more I'll post it here...

mailhandler used to successfully post these emails by changing $user to a global. then bruno committed a change which avoids the global.

Bruno - should we rollback your commit?

I'm at work with no access to my notes. Let me check that tonight, please ;-)

Bruno

jjanssen, you are right when you say:

The user variable is a global there, which says to me that the function is used for "what user is logged in" versus "what user I tell you"

about user_access(), and that's the problem.

I have made a change to mailhandler, removing the $user globals because it caused the current logged user to be "switched" to the user from which originated the messages, when processing the messages manually (admin>>configuration>>modules>>mailhandler>>retrieve).

It was apparently working OK with cron, because I was still logged in when I ran cron.php. Then user_access() was happy.

Now, if we reintroduce the $user global in mailhandler, we will also reintroduce the "user switching" problem. Maybe we could consider it as a minor defect compaired to this issue.

We could solve both issues easily, if user module would allow checking user access rights without the need of loading user data into $user global.

Any other suggestion?

Moshe's taxonomy_access patch [1] enhances the user_access function to allow it to check permissions of an account passed as the second (optional) argument. Perhaps this part of the patch could be separated and added to the core to solve this problem. This would avoid the problem of needing to change the $user global for CVS, but not for 4.3, I'm afraid.

[1] http://cvs.drupal.org/viewcvs/contributions/sandbox/moshe/taxonomy_acces...

Aha, but it isn't as simple as getting whether or not our specific user has access, we also need to post it _as_ that user. Using that taxonomy_access patch as an example, I tried to hack the code to to get user_access to take an optional account variable (but still default to global $user). I got it to work, but it posted as Anonymous and not my user! Rather than hack around doing the same sort of stuff (in several files), I simply added the following three lines:

FILE mailhandler.module:

FIND:
function mailhandler_node_submit($node, $header, $mailbox, $origbody) {
ADD BELOW:
global $user;

FIND:
$fromaddress = mailhandler_get_fromaddress($header, $mailbox);
ADD BELOW:
$user = user_load(array("mail" => $fromaddress));

FIND:
user_mail($fromaddress, t("Email submission to %sn failed - %subj", array ("%sn" => variable_get("site_name", "Drupal"), "%subj" => $node->title)), $errortxt, $headers);
}
}
ADD BELOW:
$user = user_load( array("uid" => 0 ));

And that's it! Three lines. Bruno, I think this addresses the problem of "user switching" by switching back to the Anonymous user just before the function ends. I'll agree that this probably isn't the "right" solution, but it is a lot simpler than patching a ton of modules and functions. I've tested this with one email, I'd like a test where there are multiple emails coming in at the same time so I can see it switch between the users successfully.

I agree that we have to change the global user as we process each message. After processing all messages, we should switch back to the original user (which is anonymous in the case of cron, but is an admin in the case of manual retrieve).

There is a fix in cvs.