There are various issues where people have reported issues with private message when they simply haven't enabled the sub-module.

It seems like if realname is enabled, privatemsg_realname should also be enabled without any intervention.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

japerry’s picture

Here is an initial patch. It checks upon enabling of modules if realname is enabled, and enables the associated privatemsg_realname module.

Also has an update hook to enable if it hasn't been enabled already yet.

japerry’s picture

Status: Active » Needs review
Issue tags: +commonslove
ptmkenny’s picture

Is there any precedent for this? I don't know of any other Drupal modules that automatically enable themselves when another module is enabled (except dependencies).

If there are lots of issues being reported where this is a problem, please link to a few of them.

Modules are permitted to force their dependencies to be enabled, but if it is not a dependency, I do not think we should be automatically performing site administrator tasks (it is conceivable that someone wants to use Privatemsg and Real Name without combining the two.)

ptmkenny’s picture

Status: Needs review » Needs work
felipeolcav’s picture

@ptmkenny

The issue is reported and discussed here: https://drupal.org/node/2070719

It looks like when realname is enabled, it's necessary to enable pvtmessage realname integration or it's impossible to send pvtmsg.

ptmkenny’s picture

@felipeolcav

It looks like when realname is enabled, it's necessary to enable pvtmessage realname integration or it's impossible to send pvtmsg.

Is that true for all configurations of Privatemsg, or just the one used on Drupal Commons?

ptmkenny’s picture

ivnish’s picture

Category: Bug report » Feature request
Issue summary: View changes
Status: Needs work » Closed (works as designed)
Issue tags: -