This implies adding triggers here: 'admin/build/trigger/comment') and configuration of actions here: 'admin/settings/actions'.
It is the uniform method of dealing with triggers and actions within Drupal.
This means (among other things) that role privileges can be set via the global "administer actions" option under the "system module" section of the "admin/user/permissions" form.
It would improve the consistency (user friendlessness) of the UI.
NB: If also (besides the optional core module Triggers) the module http://drupal.org/project/token is installed and enabled, more fine-tuned actions are configurable, like sending tokenized emails.

Drupal guidelines recommend maintainers to join forces (whenever modules offer overlapping functionality): http://drupal.org/node/23789
Advantages of joining forces:
1) As development effort is focused on ONE module (a SINGLE codebase), solving issues happen faster and (functionality, security and performance wise) better.
2) No incompatibilities can arise between similar enabled modules.
3) Less effort is needed from the maintainer and the rest of the module community (incl. submitting and processing issues and feature requests).

Comments

not_Dries_Buytaert’s picture

This would allow to also send emails (which is not possible currently) when roles are DELETED.

rfay’s picture

Role Change Notify already provides a tokenized trigger - please see the project page at http://drupal.org/project/role_change_notify

not_Dries_Buytaert’s picture

Yes, you are right, as this module adds following:
1) triggers to the form "admin/build/trigger/user":
1a) "When a role is added to an account"
1b) "When a role is removed from an account"
2) actions to the form "admin/settings/actions/configure/{action id}
2a) User tokens
2a1) [login_uri] = Login URL
2a2) [role] = Name of the role being added or removed
2a3) [role_changed] = Name of the role being added or removed
2b) Global tokens
2b1) [uri_brief] = Brief site URL

Ad 1) This makes the fields for the outbound email message template in the form "admin/user/role_change_notify" obsolete. Please, remove them.

Ad 2) The role selection fields in the form "admin/user/role_change_notify" do not apply to any of the aforementioned two triggers.

3) The [role] and [role_changed] tokens are duplicates, so one should be removed.

rfay’s picture

Status: Active » Closed (won't fix)

Not everybody wants to use triggers and actions; they were *added* to this module. I'm not going to invalidate every user who has used the module just because you don't like it.

[role_changed] was added as a workaround for when other modules overwrite [role]. Sorry if you don't like it.

Your constructive participation is welcome, but I'm not understanding your intent at this point.

not_Dries_Buytaert’s picture

Status: Closed (won't fix) » Active

Ad 1) I was merely suggesting to DIE and make the UI more consistent to increase the general user friendliness of the module. To deal with this change for current users of the email template form: Another release of this module could transfer the values from the "outbound email template" fields into a new "send tokenized email" action and link that action to the trigger "When a role is added to an account".

Ad 2) What about my suggestion to apply the "role selection fields" also to the two triggers, so that they also function with emails when roles are removed? This was part of this feature request. So, I hope you don't mind me re-activating it.

Ad 3) You could change the description behind the [role] token to explain the duplication and avoid confusion. Perhaps something similar to: "This token is a duplicate of the [role_changed] token (mentioned below) and is listed here only for technical reasons."

teliseo’s picture

>Ad 2
Current functionality in 6.x-2.x-dev (see #557458: Different Notification Messages for Each Role) triggers add or remove of individual roles. This is a different implementation than you suggested, but is an equivalent feature.

>Ad 1
Migrating data from the current email template to triggers and actions is a significant feature request, not without its own set of issues, such as dependence on the Token module. Given the new separate role functionality, this mapping is now possible (i.e. there is nothing that the original email feature can do that can not now be done with triggers), but I don’t believe it’s worth the effort to implement. Feel free to log a separate issue and provide a patch if you think this is important.

>Ad 3
I think that [role] is ambiguous, and [role_changed] is a better token keyword. Since [role] has already collided with another module, I think it should be marked “(deprecated)” in its description, but that’s up to rfay. Note that this has changed again (to [role-changed]) for Drupal R7 (see #944268: Cleanup token implementation and add token validation if available).

rfay’s picture

I agree that [role] should be deprecated.

teliseo’s picture

Status: Active » Fixed

I’ve added a (deprecated) note to the [role] token (committed to DRUPAL-6--2: http://drupal.org/cvs?commit=488822). As there is no further discussion, I consider this issue closed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.