Possible to send email to site admin when user roles expire?

More and more people keep asking for notifications. I will need to do something. I am thinking perhaps it should be a role_expire_notifications module or provide some way to hook into notification module.

As I need this too, I'll work on it this week.
This should be added to role_expire.rules.inc

Here it is!
This patch adds a rule event called "Role has expired".
It is triggered on cron runs for each user/role that has just expired. It is *not* triggered when an admin removes a role from a user.
It also adds 2 tokens: [role:rid] and [role:name]
With this, you can easily add a triggered rule that will send a message to the user whose role has expired.

This patch is to apply to the last dev.

Patch updated!

This patch replaces the previous one.
It is to apply to the last dev.

What does this patch do?

For people who do not use the rules module, absolutely nothing! ;-)
For people who do use rules, it adds 2 rules events:
- A "Role has expired" event that is triggered on each user/role that has just expired.
- A "Role is about to expire" event that is triggered on each user/role N days before the role expires.
These events are triggered on cron runs.
The number of days before roles expirations to trigger events can be set from roles admin UI along with default roles durations.

The patch also adds several tokens:
[role:rid]
[role:name]
[role:expiry-date] (and other date tokens)
[role:nearend-days]
These tokens can be used to send custom messages to users, like:

Hello [account:user].
Your role #[role:rid] [role:name] will expire in [role:nearend-days] days, on [role:expiry-date].

I know this is a big patch. I hope it still can be committed :-)

Hey, Thanks so much for the patch.

A few problems/questions to answer!:

1) Why have you removed all the t functions from hook_schema()

2) in role_expire_write_record on update it always resets nearend_triggered to 0.

3) in role_expire_write_record on insert never sets nearend_triggered.

4) Ignored errors from the insert in role_expire_write_record

5) Basically rewritten role_expire_get_default_duration()

6) In the comments for role_expire_set_default_duration you've added Deprecated. Why is this now deprecated?

7) Ignore errors from inserts in role_expire_set_default_duration

8) Deprecated role_expire_delete_default_duration. Why?

9) The new settings system to me at the moment seems to make the module a little less simple and I love simplicity. Perhaps you can explain why you think we need a settings system.

10) role_expire_user_admin_role_submit seems to have grown by at least twice as many lines but doesn't appear to do anything new (apart from the new column)

I stopped reviewing the patch at this point as I have to go out.

Thanks for your quick review Stew! Here are my answers.

1) Because it seems that t() should not be used in install files. (Sorry, I should not have changed that in this patch. I'm aware that because of this kind of changes, patch review can become difficult!)

2) Yes, this is by design. If role expiration date is changed, then nearend event should be triggered again.

3) Yes, this is because nearend_triggered's default value is 0 on insert.

4) I haven't touched this part

5) It is just an optimization as db_result is perfect for this kind of query.

6) Because it is not used inside the module anymore (replaced by role_expire_get_settings). But it is safe to keep using it anyway.

7) Yes, this is a possible bug fix: db_affected_rows() returns FALSE no only when a record doesn't exist but also when record's fields are unchanged. So it might happen that INSERT fails and raises an unwanted error then. So it is safe to add @. That can be seen in many core modules.

8) Same as 6)

...

Have to stop as I have to go out too!

9) I added the settings thing because there are 2 now fields attached to role in table role_expire_length (not only duration) so this system makes possible to update both fields but also only one. It is flexible as it also makes possible to add other fields in the future, and also 3rd party modules could extend it if they need new fields.

10) It has grown because it save 2 fields instead of 1. It also has grown for compatibility as it keeps on working whether user has rules enabled or not (when rules is not enabled, no extra field is added thus not disturbing people who do not need the extra field). The settings system is not complete yet but when it's done, new fields could be added by 3rd party modules without having to override role_expire_user_admin_role_submit.

After thinking a bit, "Deprecated" should be removed from comments as there's no problem keeping using these functions.

If you think it's too much change, I can also release these features as a separate add-on module. Just let me know.

it's up to the module maintainer to decide, but these additions make sense to me to have within the scope of this module. I look forward to testing it. Use patch in #5, or wait for an update?

Please test the patch in #5 as I definitely need some feedback.
Thanks!

Hi! Thanks for the patch!

I tried it, and I got the following error message: "Fatal error: Call to undefined function token_get_date_token_info() in /home/kr000437/public_html/sites/all/modules/role_expire/role_expire.token.inc on line 32"
And this is my code:
<?php
// $Id: role_expire.token.inc,v 1.3 2010/06/23 19:23:52 stewsnooze Exp $
/**
* @file
* Token module integration.
*/
/**
* Implementation of hook_token_values().
*/
function role_expire_token_values($type, $object = NULL) {
$values = array();
if ($type == 'role_expire_role') {
$values['rid'] = $object->rid;
$values['name'] = $object->name;
$tz = variable_get('date_default_timezone', 0);
$values['expiry-date'] = format_date($object->expiry_timestamp, 'small', '', $tz);
$values += token_get_date_token_values($object->expiry_timestamp, 'expiry-date-');
$values['nearend-days'] = $object->nearend_days;
}
return $values;
}
/**
* Implementation of hook_token_list().
*/
function role_expire_token_list($type = 'all') {
if ($type == 'role_expire_role' || $type == 'all') {
$tokens['role_expire_role']['rid'] = t('Role ID');
$tokens['role_expire_role']['name'] = t('Role name');
$tokens['role_expire_role']['expiry-date'] = t('Role expiration date');
$tokens['role_expire_role'] += token_get_date_token_info(t('Role expiration'), 'expiry-date-'); /*THIS IS LINE 32*/
$tokens['role_expire_role']['nearend-days'] = t('Number of days before role expiration');
}
return $tokens;
}

Really strange! :-O
Is token enabled on your site?
Anyway, whether it is or not, this error should not occur.
I'm puzzled!

You must be using an old version of token.
Please update it to the latest one.

You were right anrikun!! my token module was a previous version!
Thanks for the patch!

Please fully test the patch as it still needs review ;-)

The patch worked perfectly - the email was sent on schedule, prior to the role expiration.

Will be testing again (pre- and post-expiration emails) in the next few weeks.

Thank you for testing keva!

@natoya: does it work for you too?

Yes!! The emails were sent on time (the prior expiration and "role has expired" email).Works nicely... :-)

Thanks natoya.
Let's mark this as reviewed then :-)

I still need to review this in greater detail.

You're the boss stew ;-)!

The role expired event worked perfectly for me.

Worked here too...

One question, can i send multiple e-mails near the end? e.g: 3 days before expiration and 1 day before expiration?

This patch itself allows only a single trigger before expiration.
But using Rules Scheduler, you can easily schedule a 2nd notification when the 1st is sent.
2 actions should be run then:
1) Send the 1st notification (as usual)
+ 2) Schedule a 2nd notification to be sent 2 days later

I tested the patch in comment #5 against role_expire 6.x-1.x-dev Last updated: July 11, 2010 - 04:05 and I can confirm it works well.

#5 works great. great feature!

would be nice if this or solution from http://drupal.org/node/551722 was committed (Subscribing)

changing the status due to multiple reviews.

I haven't tested the 551722 patch, but one user seems to think this one is a more complete solution.

Yes I get a white screen of death with this patch :(
This issue should be critical

#28: The last dev version is not a real one: it's only the "Stripping CVS keywords" from GIT migration.
That is why the patch no longer applies.
Since #19 (1 year ago!), the maintainer was supposed to "review this in greater detail". Obviously, there was no progress and I don't want to post any updated patch if it is not to be committed.

This module offers the necessary functionality for this feature, and should be part of role expire or its own module. (I've closed the issue for the patch offered in http://drupal.org/node/551722)

I'm wanting to test this patch, but since there have been bugs fixed in the dev branch that isn't possible without manually applying it. Any chance of updating this?

All right guybedford, I'll update it for you :-)

I hand patched 6.x-1.9 with the role_expire.2-1.patch (comment #5) since it did seem to have issues patching the latest release and it appears to be working on my test site. I am testing now before deploying this latest module update with patch to my live site. Need to complete testing on all triggers before deployment, but the first event has completed and I am waiting for the next two.

Using the Rules module, Role_Expire module and this patch, I have three events that take place. The site emails the associated user and admins of the site as each event is triggered. It sends out a notice at 30 days and 5 days prior to role expiration and a separate final email upon reaching the expiration date/time.

I would very much like to see this patch updated and committed to the module.

Thanks anrikun, that would be amazing... will be waiting to test it.

Here is the updated patch :-)

Great the rules settings are there :)
However what does mean "Role is about to expire" exactly? I mean, how much time in anticipation?

Thanks Anrikun for picking this up again.

I tested this out on our site today, and the role expiry notifications worked fine.

There was one issue with the rules integration though - the custom rules data type was giving me a white screen with the latest version of rules. I resolved this by changing the 'role' argument to be of type 'string' instead of 'role_expire_role' and then removing the role_expire_rules_data_type_info function. Not sure what the fix would be for this, but I don't see why more functionality is needed than just a string token anyway.

Apart from that all looking good. More than happy to go with this, when the above has been fixed in the patch.

@guybedford,

could you please let Anrikun and the rest of the issue know the version numbers you are using of rules e.t.c. in case he wants to work against that.

Thanks
Stew

@guybedford: a white screen means some fatal error behind. Could you open your Apache error logs and post the error here?
Also I would like the steps to reproduce the bug.

I'm not sure what the issue was, but it is working now fine actually. I tested it on another site and it worked there as well.

I'm in the process of running updates on this site, so I suspect it may have been something unrelated.

I guess we're good to go then :)

Thanks Anrikun for your work on this - makes a big difference having this feature supported.

I've had a good play with this over the past few days and whilst it works I feel like notifications should not be limited to the nearend days column. I would like to see a separate table with notifications so that we can schedule particular mails at particular times. For instance 1 week before, 1 day before, 4 weeks after e.t.c.

Right now when a role expires the row gets remove so we'd need a way to track historical role assignments if we allow post expiry mails.

Thoughts? Anyone at Drupalcon UK. I am here and happy to discuss in person?

Patch doesn't appear to work with any current version :( Can we get this committed to core?

I can not apply this patch, it throws an error. Any help?

This is the error:

# patch -p1 --dry-run < role_expire_rule_events-827594-36.patch

patching file role_expire.install
Hunk #1 succeeded at 6 (offset 1 line).
patching file role_expire.module
Hunk #2 FAILED at 84.
Hunk #3 succeeded at 97 (offset -2 lines).
Hunk #5 succeeded at 126 (offset -2 lines).
Hunk #7 succeeded at 251 (offset -2 lines).
Hunk #9 succeeded at 383 (offset -2 lines).
Hunk #10 FAILED at 436.
2 out of 10 hunks FAILED -- saving rejects to file role_expire.module.rej
patching file role_expire.rules.inc
Hunk #1 succeeded at 7 (offset 1 line).
patching file role_expire.token.inc

Im using Role Expire 6.x-1.9 and Rules 6.x-1.4

This issue is about version 6.x-1.x-dev.
So you have to apply the patch on 6.x-1.x-dev, not 6.x-1.9.

Sub

is there a chance that we may see the event for the 7.x version? I am trying to react to the case where a user role expires in order to unflag nodes that this user has flagged.

subscribing to have this set of rules for the 7.x version too

Subscribing, hoping this gets into the production version of the module soon.

Not sure exactly where to post this, but for Drupal 7 users, I found a way to send an admin an email when a user role expires. It uses a combination of: Views, Views Bulk Operations, Rules, and Rules Scheduler. I assume you already have your Role Expire settings all configured, so I won't go into that.

1) Create a View with fields:

• User:name
• User:role expiration date/time
• User:role expiration role
• User:bulk operations

2) Configure the User:role expiration date/time field's date format to be "Time hence" (not sure if this is necessary, but it certainly looks better telling you how many days are left in the user's role before it expires.

3) Create a filter with User:role expiration date/time to be less than or equal to 0 hours. This basically means, when their role expiration time reaches "zero", they are added to the View. I set my View to be "Less than or equal to 1 month", as I wanted to send an email to users a month in advance to remind them to renew their membership to our site.

4) Save your View.

5) Create a Rules Component using an Action set called "Send email for expiring roles".

6) Add an action, "Load a list of entities from a VBO View". Select the View that you just created.

No arguments necessary. List of Entities... Variable Label: Upcoming User Expiries... Variable Name: upcoming_user_expiries.

7) Add a loop.

Data selector: upcoming_user_expiries (the variable we just added in the last step).

Current list item... Variable label: Expiring Users... Variable name: expiring_users.

8) Add an action in this loop: Send mail.

Data selector: expiring_users:mail.

Depending on what you're doing with this (I'm sending it to notify expiring users), do what's necessary in the email subject/message. I don't know... sound sexy or whatever in your email (*cough*).

9) When you're done this, you can test it by going to the Components list and clicking "Execute". But we want this to automatically happen. That's where Rules Scheduler comes in.

10) Go back into your component we just created, and add a new action (outside/underneath the loop) "Schedule component evaluation".

Select the value of "Send email to user with upcoming expiring role" (or whatever you named your Action Set).

If you would like to run this action daily, put +1 day. Once a month? +1 month.

Identifier (not necessary): Send email to upcoming role expiring users.

Save.

------

You'll have to have Cron set up properly in order for the scheduler to work.

Obviously, my setup is a little different. As mentioned above, I set this up in order to notify users of an upcoming role expiration, and to encourage them to renew on our site (via Drupal Commerce).

What I also did, so that users wouldn't keep getting reminders every day to renew their membership, I created a field in the User Profile called "Expiry Notification", which is a simple "Yes/No" list indicating if the user has been notified yet. If that field, which I've set to be the default, is "No", then they are put in the Views list. If it is set to "Yes", they are not added into the View.

In my Action Set above, I added a "Set a data value" action so that when the action is run, it changes that field to "Yes". That way they don't keep getting notifications every time Rules Scheduler runs.

OK, super long post fueled by a crappy café's coffee. Hope this helps some of you out.

Subscribing for patch for drupal 7

Sub - waiting for this to be merged into v6 release version.

any update on this?

looks like anrikun and guybedford kicked ass and got a great patch put together, but were not committed and now the core has moved on making the patch obsolete... as far as I can tell their patches were only omitted because guybedford didn't put a period in one of his comments, and omitted brackets from a single-line if statement (http://drupal.org/node/551722#comment-4098800), and anrikun's patch was "too complicated" (http://drupal.org/node/551722#comment-4713182)

is that where it ends -- am i missing a resolution?

Patches welcome.

would it make more sense to break it out into another module?

maybe you could provide hooks in role_expire for various events (like record write, record removal, etc)

I started a module, but then I found a way to make everything I want to happen work in Ubercart's role assignment module.

If anyone is interested in taking over what I started, I've got a bare-bones module (that so far only provides a settings page and db_schema) set up on this sandbox:
http://drupal.org/sandbox/tmsimont/1463236

it needs a lot of work... i don't plan on continuing development on this.

FYI to anyone searching for how to do this with ubercart, see
uc_roles_renew()
uc_roles_grant()

and this:
http://www.ubercart.org/forum/support/9545/automatic_role_assignment_dru...

What patch should I use and what version of this module do I need for the notifications to work ? :)

Thanks

I don't think they reliably work in any version

Im surprised no one has thanked Trevor for his thorough step by step tutorial. Thanks, saved me a lot of hassle!

Re: trevorkjorlien #51 above . . .

I'm not getting the data selector:

8) Add an action in this loop: Send mail.

Data selector: expiring_users:mail.

I only get expring_users:0 expiring_user:1 etc.

what am I doing wrong? what do I need to do to expose the :mail as a data selector?

can you help?

Nevermind. I think I figured it out.

For what it's worth, role_watchdog more or less accomplishes this, though not specifically for expirations.

The module also logs it.

How did you manage to expose the :mail? I can get expiring-users but it wont let me add the :mail

Eric

Aitala: In Trevor's rule, you MUST be careful to pick "Load a list of entities from a VBO View." There are two options here that look very similar, and the other does gives only the "expring_users:0" options mentioned by royerd.

Trevor: I am having trouble with the scheduling step. When I select my component for the action, I get "Missing configuration for parameter date." Everything else works (THANK YOU!!!!). Any ideas?

Maria

How to create a "Role Expired" event in Drupal 7 / Rules 2 (hack):

STEP 1: Add the Rules Event code to role_expire.rules.inc:

function role_expire_rules_event_info() {
  $events = array();
  $events['role_expired'] = array(
    'label' => t('Role has just expired'),
    'group' => t('User'),
    'variables' => array(
      'user' => array(
        'type' => 'user',
        'label' => t('Expired user'),
      ),
    ),
  );
  return $events;
}

STEP 2: Add the code that invokes it in role_expire.module:

rules_invoke_event('role_expired', $account);

Put it immediately after the user_save() function in role_expire_cron().

Flush all caches. You can now create Actions based on this Event.

As If: I had a quick stab at making your changes, but got system errors. Do the code chunks need to be in any particular location in the files? Would it be possible for you to supply zipped copies of your edited files? Thanks.

@adam_b -- I should mention that (a) I am using version 7.x-1.0-beta2, and (b) first I applied this patch:
http://drupal.org/node/1370262#comment-5487138

After that, I added role_expire_rules_event_info() at the very bottom of the file.

The rules_invoke_event() function I placed on the line directly after the user_save() function. That would be line 445.

Add the rules event 7.x version:
#1820306: Integration of Rules Event on Role Expiration

I believe that I can get something working similar to #51 using views rules.

Using what I believe is described in #51 (but now it seems to be called "Load a list of entity objects from a VBO View" I can't figure out how to access the fields in the VBO within the rules loop.

However, I would prefer to send and email with the expiration date without the time. One way to do that might be with the Ubercart date format, but I can't get that to work within views rules without errors. If I choose the rendered field option in views rules for the expiration date I get: Notice: Undefined property: role_expire_handler_field_rid::$items in role_expire_handler_field_rid->render() (line 115 of /srv/bindings/0c0af6161f58491a8df36a8322c62f11/code/sites/all/modules/role_expire/role_expire.views.inc).

Can someone check that #51 is still working for them and whether the documentation needs to be updated at all? Would that solution provide a way to use the expiration date (assuming it is a field in the VBO) in a short format that doesn't include the time?

Thanks.

Where does any of this stand, now that it is September, 2014?

Role Expire is potentially very useful, and could even take over the expiration rules and notification bits from ubercart and commerce, with a little help.

Any chance of an update on where things stand and whether any of the patches might make it into a release?

Thanks.

There's a simple patch that looks good for 7.x over here: #1820306: Integration of Rules Event on Role Expiration

As issue #1820306: Integration of Rules Event on Role Expiration is already commited, I would suggested to use the Rules module to send an email when a role expires.