This was the problem and the user switching method worked. It also took care of the cron problem. Thanks for all your help! Neil Goodman On Feb 6, 2008 12:04 AM, David Metzler <metzlerd@metzlerd.com> wrote:
Yes, thanks Moshe, I will definitely include this technique in my modules. Dave
On Feb 5, 2008, at 7:56 AM, Neil Goodman wrote:
Thanks. Those suggestions are certainly helpful and I will try it out tonight (thanks for the security tip Moshe). I think you are right that permissions might be the problem.
Does anyone else know what permissions cron is run under? It would be nice if it ran under user 1 permissions, but I don't think this is the case as this same problem is happening when my module runs under cron. Can I use David's method of switching users in cron? That seems counter-intuitive to me because I wouldn't think there would be a user object for me to manipulate.
Neil Goodman
On Feb 5, 2008 9:05 AM, Moshe Weitzman <weitzman@tejasa.com> wrote:
This is quite a dangerous operation. If you don't change back to the original uid, whomever calls this page gets to be uid=1 on the next request. There are many reasons why a page might not complete so you have to defend against it. Thanksfully, core now makes this easy. Just add a call to session_save_session(FALSE) before the user_load(). After you are done with your save operations, call session_save_session(TRUE).
On Feb 5, 2008 9:33 AM, David Metzler <metzlerd@metzlerd.com> wrote:
Here's an example from my CAS module.
// Become user 1 to be able to save profile information $admin = array('uid'=> 1); $user = user_load($admin);
If you're operating as a normal user you'll want to save away the
value of
the current user, become admin , do your save stuff, then become the normal user again. Something like:
global $user; $temp_user = $user; $admin= array('uid' => 1); $user = user_load($admin);
... do some save stuff
$user = user_load($temp_user);
This of course should only be used when you're trying to circumvent permissions checked by user_save() (do you have permissions to modify user roles for example).
I thought there used to be code in cron.php to do this, but I think I may just be remembering wrong. Perhaps someone else on the dev list could answer the question of who the cron user executes as.
As I said, not 100% sure this is your problem, but I do know you'll have problems having generic users sync up their roles unless you do this permissions escalation.
On Feb 5, 2008, at 5:46 AM, Neil Goodman wrote: No, how do I go about transitioning to user 1 for the save operations?
Right now I just call the function and I assume the permissions would be of whoever is using the module at the time. How do permissions get determined with things like hook_cron()?
Neil Goodman
On Feb 4, 2008 10:44 PM, David Metzler <metzlerd@metzlerd.com> wrote:
Last time I ran into something close to this it was because of
permissions. Are you transitioning to user 1 for the save operations?
Might be completely off base.... but that's my experience.
On Feb 4, 2008, at 5:34 PM, Neil Goodman wrote:
Hello,
I'm currently trying to solve a bug report for my module
(http://drupal.org/node/217639). rallycivic keeps getting a "__clone method called on non-object" when he runs a function in my module. My module runs through a CiviCRM database and pulls out certain CiviCRM contacts that have membership status. The goal is to get this status synchronized to a Drupal role. There is a static method in the CiviCRM API called CRM_Core_BAO_UFMatch::getUFId(). This method will take a CiviCRM contact id and return its corresponding Drupal uid. I then take this list of uids and pass it to the user_multiple_role_edit() function. This function uses the user_save() function to apply role changes. I think that one of rallcivic's uids is causing an issue with this function. From reading the user_save() function's code I can see that it tries to create a new user if the uid doesn't exist. For some reason I think it is trying to do this on a valid uid, which throws a duplicate error that rallycivic has found in watchdog:
"Location
http://chelmsfordmc.co.uk/admin/settings/civimember_roles/manual_sync
Referrer http://chelmsfordmc.co.uk/admin/settings/civimember_roles/manual_sync Message Duplicate entry '' for key 2 query: INSERT INTO users (uid, created, access) VALUES (404, 1202163268, 1202163268) in /home/chelmsf/public_html/includes/database.mysql.inc on line 172."
Then the drupal_clone() function is called on a bogus object and throws the clone method error. At least, that is what I think is happening.
Has anyone ran into a situation similar to this before?
Neil Goodman