The pm_email_notify module and the user_relationships module(s) both place settings on the user edit page, but in different field groups. pm_email_notify creates a "Privatemsg e-mail notification" fieldgroup with a checkbox to enable/disable email notification upon receipt of private messages. The user_relationships module can optionally add a "Private Messages" field group with radio buttons allowing the user to permit reception of private messages from everybody, or just from people with whom they have a relationship.

Ideally, all projects that add PM settings to the user edit page should group them together under the same fieldgroup, preferable one named "Private Message Settings".

Comments

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Makes sense, but the only thing we can do is rename our fieldset and then you have to create a new issue for the user relationship project. The tricky thing is that privatemsg.module does not yet contain a user-level setting, so it is not guaranteed that the fieldset created by the pm_email_notify module is there...

sja1’s picture

sja1 commented

If I understand you correctly, you're thinking that the fieldset should be defined by privatemsg.module. I agree that that is the best place, and then other modules that create user settings can just add their form elements to that fieldset.

But as you point out, there is an issue if privatemsg.module isn't currently providing any settings itself. We don't want it to define a fieldset, and then have it show up empty on the user edit page if no modules that use the fieldset are enabled.

What might work is if privatemsg.module defined the fieldset, but then just before it was rendered (after all hook_user functions have been run), check the fieldset and unset it if it is empty. I'm inexperienced in form api, but looking through the possible options for fieldsets, perhaps the #pre_render attribute would allow us to define a function to be called that would do just this.

Does this seem like a viable solution?

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Now that we have a user edit page setting in privatemsg.module, I'd suggest to either put other stuff in there or add a Privemsg category and pull all settings there.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Active » Closed (duplicate)

Implemented here #902402: Combine user-facing settings into one fieldset (and change fieldset name)