Conflict with Flickr module?!

I studied the module in question and it implements hook_user which could've gotten confused from our call to user_save sending through the default category 'account'. NULL is also very common and might also result in conflicts so I opted to make it unique and send a category called 'remember-me'.

It is not clearly stated anywhere what the use of the $category is exactly, I could not find anything else using it outside of the standard ops other than profile module.
If you do indeed go and create a group for your profile fields called remember-me you will be getting trouble. Just as you would calling it account or register. Needless to say profile module is deprecated in D7 and hidden from the modules page so it can't be enabled anymore and we have already effectively removed the $category value from the user hooks in D8.

Please test your configuration again with the new release and let us know.

Conflict with other modules in D7:
Remember me uses user_save to save data. The data option is obsolete in D7 and may disappear in a future Drupal. The user_save also conflicts with other modules in ways we should not here.

The saved data could go to a discrete field or separate table for long term compatibility. The field could then be viewed in the administration user pages and listed in views so people can report on the status. Many modules put their data in a separate table they can update themselves without hitting other modules. I prefer a separate field because it is easy to list who has the attribute.

As an example, the IP Login module reacts to a user update by updating the ip_login_user table. The IP Login module does not check the source of the update. When Remember me does the user save, IP Login thinks we updated the user with an empty IP address range. IP Login can be changed to response only to updates from the admin user update form. We then have a problem if an update arrives from somewhere else and does want to update the IP address range.

Some modules bypass the problem by replacing their empty string with *none* or some other special string. If they get an update with an empty string, they do not change anything. There are other user modules that could need a change. A slight change to Remember me could bypass all the conflict.

* Update: In the IP Login case, mentioned in #6, IP login sees an empty string when the IP login field is from a form with no data and sees null when the update is from the Remember me user_save. IP Login can use that difference to ignore user_save updates that are not from the user update form. *

Please check the version you have installed, we have already updated the functionality to hook_user_presave() instead of user_save.

It would also be useful if you update the version when submitting an issue to help identify which version you are referring to.

Help us to help you...

D7 RC1 conflict with IP login. Change to IP login proposed at: http://drupal.org/node/1482934

Not using user_save anymore as the functionality that was previously done in user_save has been replaced by the new safer hook_user_presave() in D7

Both rc3 and the dev version from Feb 18 use user_save:

function remember_me_user_login(&$edit, $account) {
  if ($account->uid) {
    user_save($account, array('remember_me' => !empty($edit['input']['remember_me'])), 'remember-me');
  }
}

Other modules may still need the type of change mentioned in http://drupal.org/node/1482934

If core goes and breaks the hook systems then core needs to fix it, modules rely on the hooks and it is bad form to not use them, imho.

Just to add another note on this topic.

Remember me has taken every precaution to safely and only modify the remember_me user data value and will not harm any kittens. It is only acceptable to expect other modules treat us with the same consideration. Bypassing the hook system in any way is, in my experience, only looking for trouble and makes integration with other modules more difficult not the other way around.