Add permission to set user specific settings

You can do this by implementing hook_form_alter() in a custom module.

If you are not familiar with module development, than for God's sake, don't touch the code of the core system or any modules.

An older discussion here: #667306: Permissions to show Plaintext options by role.

I also need this feature, and IMHO it would be stupid to have to enable yet another module just to disable something mimemail added while it could leave the choice of adding it to the site admin. I'll provide a patch for this today.

I did a patch for version 7.x:

This will get you a new checkbox in the admin page of mimemail which is by default enabled and let users choose to only get plain text mails.
By disable the checkbox - the checkbox won't be shown in the user menu.

I also hide that checkbox, if all messages are set to plain text by default (checkbox in admin menu).

But this patch needs a fix.
How do I have to handle, if users were allowed to check to only get plain text messages - than this option is disabled (so they can not change there settings any more, but the settings are saved in the database).

I have to put another control element anywhere here:

file mimemail.module - around line 290

  // Try to determine recipient's text mail preference.
  elseif (is_null($plain)) {
    if (is_object($to) && isset($to->data['mimemail_textonly'])) {
        $plain = $to->data['mimemail_textonly'];
    }
    elseif (is_string($to) && valid_email_address($to)) {
      if (is_object($account = user_load_by_mail($to)) && isset($account->data['mimemail_textonly'])) {
        $plain = $account->data['mimemail_textonly'];
        $to = $account; // Might as well pass the user object to the address function.
      }
    }
  }

I guess it may work to change it this way:

  // Try to determine recipient's text mail preference.
  elseif (is_null($plain) && variable_get('mimemail_userchoosetextonly', 1)) {
    if (is_object($to) && isset($to->data['mimemail_textonly'])) {
        $plain = $to->data['mimemail_textonly'];
    }
    elseif (is_string($to) && valid_email_address($to)) {
      if (is_object($account = user_load_by_mail($to)) && isset($account->data['mimemail_textonly'])) {
        $plain = $account->data['mimemail_textonly'];
        $to = $account; // Might as well pass the user object to the address function.
      }
    }
  }

So the script only checks for user specific choises, if that is allowed.

This looks like a needed feature, but I like the idea of using a permission for this in #667306: Permissions to show Plaintext options by role much better. So I would go with the attached patch.

@sgabe, thanks for providing a patch for D6.

However, I would drop the configuration setting to enable the permission. IMHO it's better to have a permission like this always there, and for existing installations hook_update_N() can grant it to the authenticated user role.

For new installations the permission needs to be explicitly assigned, or can be assigned to the authenticated user role in hook_install(). Any thoughts on what the default behavior should be?

Attached is my attempt for a D7 patch. The permission is called "edit mimemail user settings" which I believe better reflects what its intended use is.

There is no toggle to turn on/off the usage of the permission, instead the permission is assigned to the authenticated user role in mimemail_update_7000(). Maybe that is not wanted behavior if this patch gets backported to the D6 version of this module though.

It's okay with me to drop the configuration setting, however I am not sure about the permission's name. For me neither "access" or "edit" fits for this case.

I am attaching a new patch for D6. Please add some documentation to your patch (for the hook and a plus line in the README.txt).

If this will get into the D6 version it's probably better not to assign the permission by default in the D7 update hook? Or should I explicitly check there which D6 version we're coming from?

Where do you prefer that I put the explanation about the new permission in the README? Under the "-- INSTALLATION --" section?

Attaching a new patch, with some comments added.

I still prefer "edit" above "access" as the term "access" is applicable for about any permission, in the sense that a permission gives you "access" to do something. Maybe using "change" or "modify" would be better: "Change user settings"?

If this will get into the D6 version it's probably better not to assign the permission by default in the D7 update hook?

I think we need to do this in the update hook.

We don't check for versions. The right way of core updating is to first update the contrib modules to their latest versions and then update the core and then the contrib modules according to the new core, so we can assume that the user already has this feature.

The attached patches have been committed to both branches.

Thanks @sgabe, I'm very pleased having this new permission in Mime Mail!