Port Views Send to Drupal 7

A patch is welcomed to start with 7.x-1.x-dev branch :)

+10!

subscribe

Added 14th of June: I have started the porting work - I'm almost there. I'm posting back when I'm done.

OK, here it is - a working port to Drupal 7. It's in no way finished, but I think it's a good start. Please consider commiting to a 7.x-1.x-dev branch so other people can contribute. (Yes, I know I should have created a git sandbox and so on, but I was in a hurry.)

PS! I have tested it with a rather simple View that lists a content type that has an email field - and that works. I have not tested with a View that uses a relation ship to fetch the email field.

Using the drupal 7 version - I've got a view with an email column but can't see how to send multiple emails out. I want to filter by expired members and send to this list.

Thanks
Sharon

I assume you have VBO 7.x-3.0-alpha2 (and Views 7.x-3.0-rc1 or dev)? With that in place, the steps are (from the VBO README.txt):

1. Create a View.
2. Add a "Bulk operations" field if available (see technical details below).
3. Configure the field. There's a "Views Bulk Operations" fieldset where the actions visible to the user are selected.
4. Go to the View page. VBO functionality should be present.

The action defined by the module is "Send mass mail".

PS! When you wrote "Using the drupal 7 version" - did you meant my version above?

yes, I am using your version, however I am having problems with views rc1 and dev, so I am currently using views, 7.x-3.0-beta3 and VBO 7.x-3.x-dev. When I get my views issue figured out, I'll try again.

Thanks
Sharon

ok, I've updated my views and VBO but don't see any action for send mass mail. I only see:

Ban IP address of current user (system_block_ip_action)
Block current user (user_block_user_action)
Delete item (views_bulk_operations_delete_item)
Execute arbitrary PHP script (views_bulk_operations_script_action)
Flag (or unflag) a user (flag_user_action)
Modify user roles (views_bulk_operations_user_roles_action)
Pass ids as arguments to a page (views_bulk_operations_argument_selector_action)

I must still be missing something...

Thanks
Sharon

You need to select the actions in the form field you added to your view - click "Views Bulk Operations" and scroll down.

ok,This is exactly what I have done. I added the User:Bulk Operations field ( I only had two options, User :Bulk Operations and File: Bulk Operations) However the only actions I have available are as listed below:

Selected operations
Ban IP address of current user (system_block_ip_action)
Block current user (user_block_user_action)
Delete item (views_bulk_operations_delete_item)
Execute arbitrary PHP script (views_bulk_operations_script_action)
Flag (or unflag) a user (flag_user_action)
Modify user roles (views_bulk_operations_user_roles_action)
Pass ids as arguments to a page (views_bulk_operations_argument_selector_action)

Thanks
Sharon

OK, you are sure you have enabled the module? And given your user's role permission to use Views Send?

I just tested, and even with User:Bulk Operations field I get a choice "Send mass mail (views_send_mail_action) ".

Yes, I'm sure I've enabled the module as I see on the config page a section for Views Send and I have permissions set for myself as administrator to use Views Send. Any other ideas?

Thanks
Sharon

I can confirm the behavior your report if I upgrade to VBO 7.x-3.0-alpha3. As I stated above, I was using VBO 7.x-3.0-alpha2. Since many operations are missing, not only views_send_mail_action, this is a VBO issue which I'll report (since it's also present in the current dev version).

Could you please downgrade to VBO 7.x-3.0-alpha2 and try again? (It's completely safe - there are no database updates going from VBO 7.x-3.0-alpha2 to alpha3.)

Added: The bug in VBO 7.x-3.0-alpha3 has been confirmed by the VBO developer - see #1198374: Operations missing after upgrade from alpha2 to alpha3/dev.

I made a complete test for "User:Bulk operations" with the email from the user as the email field, and found a bug. A new version is attached.

PS! VBO 7.x-3.x-dev (2011-Jun-24) works - in addition to 7.x-3.0-alpha2.

hansfn -
Ok, I've updated to your new version and switched to the new VBO dev version, but now I get the error

Fatal error: Call to undefined function mimemail() in C:\wamp\www\drupal\sites\all\modules\views_send\views_send.module on line 739

when sending emails out.

Thanks
Sharon

I haven't tested sending HTML mail at all - I'm old school and use only plain text e-mail. Sorry. Please test sending plain text.

PS! The README.txt says: "When Mime Mail module is enabled, the user can choose to send rich HTML messages."

I was sending plain text, but did have mime mail installed. so I removed the module and now get this error message:

Fatal error: Call to undefined function drupal_eval() in C:\wamp\www\drupal\sites\all\modules\views_send\views_send.module on line 351

Thanks again
Sharon

Sorry that you got into so much troubles, but you are probably the first to test this port ... (As you probably guessed everything just worked in my setup.) I wasn't even intending to support my work - it was mostly to help the real maintained get going on the D7 port.

Your last problem is that you have enabled the PHP filter for your role, and that triggered a part of the code that wasn't ported to D7. Also just having mime mail installed shouldn't break anything. I'll post a new version later today with these two issues fixed.

Thx for your patience (and testing).

Glad to help! My client want to mass email from views so it's a win-win for us all :)

Sharon

Find attach an updated version that works if you have enabled the PHP code text format/module and if you have installed Mime Mail.

PS! If someone wonders why I haven't created a Git sandbox: I expected/expects the maintainer to create a branch soon - since patches was requested ...

So, you've worked around not having #1180538: Pass the selected views row(s) to the action? Good (though I still plan to fix that).
Glanced at the code, seems nice.

Subscribing...

hansfn -
I was this time returned to my view and got the following messages when attempting to just send one message to myself:

1 row processed in about 101 ms:
Performed Send mass mail on user SharonD214.

Error messageNotice: Undefined property: stdClass::$rid in views_send_mail_action() (line 339 of C:\wamp\www\drupal\sites\all\modules\views_send\views_send.module).

The email never arrived.

Thanks
Sharon

Views Send is sending the messages when cron is run. (The message is added to the table views_send_spool when you submit - it's not immediately sent.) How often cron is run depends on your setup.

The notice can be ignored - it's not related to the actual sending of the mail.

hansfn -
Thanks so much for your help. I ran cron and the message was sent. I'd like it to send right away, but this is working now and will work.

Thanks again
Sharon

+1

Note that #1180538: Pass the selected views row(s) to the action has been fixed in VBO, and that's probably the way forward for Views Send. You get the rows data and don't need to load up the whole view yourself.

+1

subscribe

Thx, arywyr for creating a Git patch. Now it should be a no-brainer for the maintainer to create a 7 branch and maybe a first release - so we can get some feedback. Please, dear maintainer.

The code is still less than perfect - in particular it should fetch the Views rows data properly as bojanz mentions above. (Currently, it's "Work's for me" quality.)

PS! I would be happy to help maintaining that branch.

subscribe

I'm happy to apply this patch and create the new 7.x-1.x branch. Thank you for you work.

Before doing that, let's reviewing a little the patch.

+++ b/CHANGELOG.txt
@@ -1,6 +1,7 @@
+Initial ugly port to Drupal 7, by hansfn

Should be: - #1052040 by arywyr: Port to Drupal 7 (Views Send).

+++ b/views_send.cron.inc
@@ -21,22 +21,21 @@ function views_send_send_from_spool() {
+  $query = "SELECT * FROM {views_send_spool} WHERE status = :status ORDER BY tentatives ASC, timestamp ASC";
+  $result = $limit ? db_query_range($query, 0, $limit, array(':status' => 0)) : db_query($query, array(':status' => 0));
+  foreach ($result as $message) {

Let's use the nice D7 new PDO implementation. This will became:

$query = db_select('views_send_spool', 'v')
  ->fields('v')
  ->condition('v.status', 0)
  ->orderBy('v.tentatives', 'ASC')
  ->orderBy('v.timestamp', 'ASC');
if ($limit) {
  $query->range(0, $limit);
}

foreach ($query->execute()->fetchAll() as $message) {

+++ b/views_send.cron.inc
@@ -21,22 +21,21 @@ function views_send_send_from_spool() {
-      db_query("UPDATE {views_send_spool} SET status = %d WHERE eid = %d", 1, $message->eid);
+      db_query("UPDATE {views_send_spool} SET status = :status WHERE eid = :eid", array(':status' => 1, ':eid' => $message->eid));

Same PDO adaptation.

+++ b/views_send.cron.inc
@@ -21,22 +21,21 @@ function views_send_send_from_spool() {
-      db_query("UPDATE {views_send_spool} SET tentatives = tentatives + 1 WHERE eid = %d", $message->eid);
+      db_query("UPDATE {views_send_spool} SET tentatives = tentatives + 1 WHERE eid = :eid", array(':eid' => $message->eid));

Same PDO adaptation.

+++ b/views_send.cron.inc
@@ -102,5 +99,5 @@ function views_send_deliver($message) {
   $expiration_time = time() - variable_get('views_send_spool_expire', 0) * 86400;

Replace time() with REQUEST_TIME (see http://drupal.org/node/224333#time)

+++ b/views_send.cron.inc
@@ -102,5 +99,5 @@ function views_send_deliver($message) {
-  db_query("DELETE FROM {views_send_spool} WHERE status = %d AND timestamp <= %d", 1, $expiration_time);
+  db_query("DELETE FROM {views_send_spool} WHERE status = :status AND timestamp <= :expiry", array(':status' => 1, 'expiry' => $expiration_time));

Same PDO adaptation.

+++ b/views_send.install
@@ -10,7 +10,7 @@
  * Impementation of hook_schema().

Use "Implements" instead of "Implementation of" (see http://drupal.org/node/224333#implementation_hook_comment). Change all occurrences.

+++ b/views_send.install
@@ -98,21 +97,11 @@ function views_send_schema() {
   db_query("DELETE FROM {variable} WHERE name LIKE 'views_send_%'");
   db_query("DELETE FROM {cache} WHERE cid LIKE 'variables%'");

Same PDO adaptation and "variables" CID has moved to "cache_bootstrap" table.

+++ b/views_send.module
@@ -10,7 +10,7 @@
+ * e-mail priorities.

"E-mail" (not e-mail) is used widely in "Drupal World" to describe mail messages, so revert back to "E-mail" everywhere in the module.

+++ b/views_send.module
@@ -64,7 +63,15 @@ function views_send_action_info() {
+  /* This copied from SMS Bulk - not sure if it always does what we want */

Use "//" commenting for single lines an a preceding empty line.

+++ b/views_send.module
@@ -226,43 +231,33 @@ function views_send_mail_action_form($context) {
+      /* The following line is inspired by _views_bulk_operations_get_selection */

Use one-line style commenting "//" with an empty line before.

+++ b/views_send.module
@@ -226,43 +231,33 @@ function views_send_mail_action_form($context) {
+    } else {

"else" should start on a new line (see http://drupal.org/coding-standards#controlstruct)

+++ b/views_send.module
@@ -305,38 +298,57 @@ function views_send_mail_action_submit($form, &$form_state) {
+    if (substr($field,0,6) == 'field_') {
+      $token_arr = field_get_items($context['entity_type'],$object,$field);

Spaces after each comma in function call (see http://drupal.org/coding-standards#functcall).

+++ b/views_send.module
@@ -305,38 +298,57 @@ function views_send_mail_action_submit($form, &$form_state) {
+    } else {

"else" issue again.

+++ b/views_send.module
@@ -830,11 +856,10 @@ function _views_send_allow_php() {
-    $result = db_query("SELECT format FROM {filters} WHERE module = 'php'");
-    while ($row = db_fetch_object($result)) {

Same PDO adaptation.

+++ b/views_send.module
@@ -851,6 +876,8 @@ function _views_send_allow_php() {
  *   A themed table wirh all tokens.

Typo: "wirth" is "with".

***

I didn't look now into new API changes that VBO or Mime Mail. It was just a formal review.

Thanks again for your contribution. Will commit as soon as you provide the patch with necessary corrections.

Prompted by #1275578: Pass view in action configuration form, I've taken another look at how Views Send works.
While there's nothing bad with VBO passing the $view to the action form (from a performance or "cleanliness" point of view), the need for an action to actually use it strikes me as odd.

As far as I see it, people use Views Send because the alternative mail-sending solutions (actions) suck.
They use it to send mail to addresses they have on the system, and in D7 I see these primary sources:
1) User entity - probably the most common
2) Profile (either a profile2 entity or a commerce_customer_profile_entity)
3) Commerce Order (has an email attached in $order->mail) or equivalent Ubercart entity (not familiar with Ubercart on D7).
What stands out is the fact that all possible sources are entities.

What I would do is make the action apply to all entities ("type" => "system"), in the config form use Entity Metadata to get a list of all columns & fields that an entity has, and then offer that in the "E-Mail" dropdown. Since you know the exact entity type, you can also easily pull a list of all tokens for that entity type and offer it to the user. I have code that does this in my first draft of the fields.action.inc rewrite. There's no $context['entity_type'] passed, but that's easily fixable.

What this would give you:
1) The ability for the action to be reused outside of VBO
2) The ability to show the user a complete list of tokens for the specific entity type
3) The ability to avoid needing "pass rows" => TRUE. Instead of VBO passing you the raw rows, you can just get what you need from the given entity (by using Entity Wrappers you don't need to care if it's a field api field or a column, you just do $wrapper->{$selected_field}->value()). Not requiring the raw views rows dramatically lowers the memory requirements and makes it possible to use the action on a virtually unlimited number of results (not sure what the limits are, but I've ran it on 50 thousand entities without a problem. Guessing 100 thousand is just as possible).

And the code is smaller and cleaner since you don't need to touch the view or view results at all. Not to mention not having to do things like _views_send_normalize_context().
Since the new VBO can be on relationships, you can easily add a relationship from a node to a user, profile, order or whatever, and then add a VBO field on that relationship (hence making sure that the action gets the correct entity type).

Those are just my thoughts.

Uhh... think you lost me :) but I understand your point and sounds interesting.

Some comments:

• Can't find fields.action.inc file to see how works. Is it in VBO module?
• What would be a fallback when not using entities? For example fields build with Views PHP or other "Global" fields.

• Since the new VBO can be on relationships, you can easily add a relationship from a node to a user, profile, order or whatever, and then add a VBO field on that relationship (hence making sure that the action gets the correct entity type).

  This I don't understand at all.

In the meantime people need Views Sent 7. Will create a 7.x-1.x branch based on the actual patch and also a new 7.x-2.x where will refactor based on your proposals. That's why fixing #1275578: Pass view in action configuration form should help for 1.x branch.

Okay, I'll commit the patch you need, and we can explore the idea further.

1) fields.action.inc is still in progress. I hope to post a first version soon, when work allows.
2) No fallback. The only data used is the data on the entities. We're avoiding any type of hack here.
3) Create a node view. Add an "author" relationship (that likes nodes to users). Then click "add field" and you will see a field "User: Bulk Operations". If you add it, it will give you a checkbox on each node row, but the actual operation will be done on the user who authored the node.
That's the beauty of having VBO as a field.

3) Create a node view. Add an "author" relationship (that likes nodes to users). Then click "add field" and you will see a field "User: Bulk Operations". If you add it, it will give you a checkbox on each node row, but the actual operation will be done on the user who authored the node.

I have played around this but it seems that it doesn't help. Imagine that based on your example I want to use the node title as "Real name" (from entity node) and user mail as E-mail (from entity user).

Unfortunately there's no way to have both objects but only the main object. Based on Views Send functionality some conditions need to be met:

• Action configuration form. We need not only the $context['entity_type'] but a full list of all entity types involved in the relationship so that I can generate a list of possible fields (to be used as recipient realname & E-mail) & tokens (to be used in message subject and body).
• Action callback. Not only the main object but all objects involved in the relationship so that we can extract properties (columns) & fields needed for building each recipient address (eg. "Claudiu Cristea <foo@example.com>") and tokens.

What you think? How to address that?

No. You always operate on one entity. If it's the user entity type, then you have the user entity. Anything else you can load yourself.
I fail to see why you'd be taking "Real name" from a node.

Yes, the simplification of code also takes away your ability to handle some of the corner cases. I fail to see anything critical in there, though.

Anything else you can load yourself.

How? I have no information inside configuration form function or action callback. To load related objects some infos must be passed about how entities are related.

I fail to see why you'd be taking "Real name" from a node.

OK. Forget realname. How about a node (or other entity) that store some user points/credits. I need to send him a notification:

To: mary.jane@example.com
Subject: Congratulations Mary Jane, you just earned 230 credit points!

"Mary Jane" (Field API), mary.jane@example.com (property) taken from user entity and "230" (Field API) taken from an custom entity.

The advantage of Views Send over other systems is that allows building complex lists using Views. And yes... complex means in most of cases relationships that consolidate infos from several related objects.

I like very much your approach and I want to use that direction but this is really a blocker. I'm asking myself if properties (columns) and fields from all entities invlolved in the relationship are not valuable for other VBO actions too? Why some people would build VBO Views with relationship if not to take advantage in actions for having values from both entities?

@claudiu.cristea:

Should be: - #1052040 by arywyr: Port to Drupal 7 (Views Send).

I hope that is a typo - arywyr just turned my tar-ball into a git patch.

Will commit as soon as you provide the patch with necessary corrections.

Sorry, that won't happen. I spent a lot of, or better, way too much time getting it to (barely) work for Drupal 7 - I have never claimed the code is perfect. (Sorry about the else coding standard issue, I'm used to the Pear standards. When it comes to PDO - you don't have to use it.) Maybe arywyr can do it ;-)

Regarding your discussion with bojanz: I follow your reasoning, but maybe bojanz knows something that we overlook...

@#40
Okay, I understand your point.
Technically, you have the relationships in Entity Metadata, so you can see that $node links to $user, and offer the user's fields as well (if you're using Entity Wrapper, $node->author->mail works, it loads the user in the background).
However, Views will always be able to do it more powerfully, pulling data from 3, 4, or X joins if needed. No limit on how deep it can go.
So maybe the current approach should stay. It sacrifices performance for features, but I guess the admin doesn't need to send 15000 emails at once...

Why some people would build VBO Views with relationship if not to take advantage in actions for having values from both entities?

It's tricky.
Instead of one entity, you pass two. You've just cut the performance in half.
I haven't needed it in my use cases. I can always load what I need in my custom actions (like the user that authored the node).
I know some people needed to know the parent as well, in which case they used "needs rows" to get the raw views rows and the entity id of the parent entity as well.

@hansf please don't rework that code. Looking deeper in the code we'll have to change more things. I'm discussing with @bojanz and after I will create a starting 7.x branch.

Thanks for your efforts.

Any progress on the git patch and/or git branch?

I'm looking into a way to mass email selected users and Views Send seems to be what I need!

subscribe

subscribe

Wow. This could be a case study on how striving for perfection can kill progress.

What's the downside of creating a 7.x.1.x branch based on @hansfn work and starting the rewrite on a 7.x.2.x branch like @claudiu.cristea planned back in September?

http://drupal.org/node/1052040#comment-4973494

Yes, it is disappointing (and discouraging) that my (agreed less than perfect) patch hasn't been turned into a branch yet. I would probably have improved it a lot if that had happened.

If it is the coding standard issues that is stopping the maintainer from using my code, I'm willing to spend the extra hour or two to fix it. Just let me know.

Please port the module for D7 ...

subscribe

Thank hansfn for your work.

Please Claudiu just create this branch now. This module could have been used as dev version already 6 month ago... What is the point to wait for more time ?
-> It'll be still time to write on a 7.x.2.x branch later on.

Please move things up.

I tried contacting @claudiu.cristea via his D.O. contact form last week about this. No response.

It's probably too soon to consider this project abandoned, but it's certainly being neglected. Maintaining a module can be a thankless job, but in this case several people are offering to help and just being ignored.

I see a few options to move forward...

1. @claudiu.cristea remains the sole maintainer, commits @hansfn's code as the starting point of a 7.x.1.x, reviews patches from @hansfn, @kreynen, and anyone else to address any major issues, new structure started in a 7.x.2.x branch.
2. @claudiu.cristea asks for a co-maintainer for the 7.x branch. Someone qualified (at least understands git and issue queue) steps up, commits @hansfn's code as the starting point of a 7.x.1.x, reviews patches from @hansfn, @kreynen, and anyone else to address any major issues.
3. Someone forks the project.

Obviously forking the project isn't ideal, but the only other option to get some level of version control is to go through the process of having the project declared abandoned and finding a new maintainer if @claudiu.cristea isn't going to respond. Even if it's only forking to someone's sandbox, it still adds a level of version control required to development collaboratively.

Unfortunately I don't have time to help maintain yet another module. I don't want to speak for @hansfn, but I'm not sure he has time/interest beyond scratching his own itch either. It won't take much to get form @hansfn's initial work to a stable release. This module has a very limited feature set and install base so maintaining it (responding to issues in the queue, reviewing patches, making commits) should be a relatively minor commitment.

Side note: A big advantage of the old +1 subscribe vs. the new Follow button is everyone can see who's interested in an issue. There is obviously some level of interest in a D7 port of Views Send. The questions becomes is anyone who's +1'ed interested enough to actually contribute?

For the record: I would be willing to (co-)maintain the D7 version of this port. If that happens, I'll of course fix the coding standard issues and make the necessary changes to take advantage of the possibility in VBO to pass the selected views row(s) to the action. (I have improved my Drupal coding skills slightly since writing the port back in June.)

I'm surprised that claudiu.cristea hasn't done anything - it really looked as something was going to happen in the mid of September ...

Please port the module for D7
Thanks

@hansfn I would start by creating a git sandbox version. I did this for the user_stats module. In that case it took a few months between the time I started that...

http://drupal.org/node/813600#comment-4751126

...and when the module's maintain tuned back in...

http://drupal.org/node/813600#comment-5075226

I don't know why @claudiu.cristea isn't responding, but a sandbox version would give us a the version control we need to create patches in a productive manner, show that you understand git well enough to co-maintain, and give @claudiu.cristea more time before flagging this project as abandoned.

People tune the community's needs out for any number of reasons. I know I've taken my share of breaks from projects.

@hansfn Let me know if you need help with git or creating a sandbox.

Thx for offering to help, but I'm a long time user of SCM systems - I have even used RCS for a long time ago. I'm not a Git expert, but I get the job done.

The sandbox is up and running - Views Send Drupal 7 Port. Let's see if this helps.

Some people are actually following the sandbox project, but for the rest of you I'm posting a dump of the sandbox here. The code is much better and by passing the rows from the view, you can now robustly use any field as the recipient e-mail address.

Guys I was terribly "loaded" with other projects, issues. I will get back to this shortly. Thanks for understanding.

@claudiu.cristea Everyone understands juggling priorities and that being a module maintainer is done as a volunteer when and if people have time, but that's why D.O. supports granting multiple people permission to make updates.

@hansfn has shown that he understand git, D.O.'s project process, the communities coding standards... AND he has the time to help support this.

PLEASE, give @hansfn access to the project so he can create a 7.x branch and patches and issues can move out of his sandbox.

@hansfn, would you expect tokens from custom fields to work properly with the head of your sandbox version? For example, I have a "first name" (field_first_name) text field for users, and [views-send-field_first_name] shows up as a token in the "replacements" table, but it doesn't get substituted into the e-mail body.

I'm willing to work on the issue, but despite poring over the module (and examining $context in views_send_mail_action) and the token module documentation, I can't find any meaningful clues about where the tokens or their values come from.

@HorsePunchKid Yes, I expected it to work, but I can confirm that it doesn't. (The results from Views are organized slightly different from what I expected in some cases.) Follow the #1449988: Fix token replacement for fields issue to get news when it's fixed.

OK, it seems I posted the zip file above (views_send_drupal_7_port-2012-02-16.zip) prematurely. I need to fix #1451594: Make field support more robust for the recipient's name/e-mail first. In addition, I have noticed that the filter handling needs to be very much improved - no use of filter_access and so on.

You can expect a new version/zip file early next week.

subscribe

Again, a dump for the people who don't follow the sandbox project. This time I think I got it right ;-)

PS! Please report bugs/issues in the sandbox project.

I can report that the module is getting better and better - people are submitting bug reports and patches in the issue queue. We are really ready for a D7 branch and release. (I'm not adding an updated zip file.)

@claudiu.cristea: Three weeks have gone since you said you would "get back to this shortly". And nine months since my rough initial port ...

I support hansfn receiving commit access.

I've been following his work and answering his questions, and during that process I've grown convinced that Views Send should not depend on VBO at all, but implement a Views Form handler instead. Gonna try and make a patch against his sandbox when the code stabilizes.

Okay, so hansfn and I just made Views Send use Views Form, eliminated the VBO (and Entity API) dependency: #1477828: Stop relying on VBO, implement a custom Views Form handler instead.
This is awesome :) Let's get this branch up, ASAP.

For the convenience of people that don't use git, I have attached a new snapshot of my Views Send sandbox. Please test it. (Flush the cache after installing the new version.) It's working very well for me.

NB! Since the code has be rewritten as a Views Form handler, thx bojanz, you need to edit your views:

1. remove the VBO bulk operation field
2. add a global field of type "Send E-mail".

Based on @hansfn sandbox and build above ^ here is a patchfile to use in makefile if necessary.

What is holding back the 7.x-1.x-dev branch from getting created?

I'm guessing that someone now needs to test @christianchristensen's patch. Probably run it through Coder & verify that it works. Then mark the code RTBC.

If at that point it's not fixed then reach out to the maintainers.

Okay, you want the RTBC, here's the RTBC :)

I think the problem is just claudiu.cristea being very busy. Let's get hansfn commit access!

thanks hansfn - and please give him access to release a 7dev

@hansfn, per #1502976: Re-assign Views_send to hansfn you are now a co-maintainer of Views_send.

You can now commit your D7 update code and make a new release. Thanks :D!!!

This is great news. I have been very busy with a major infrastructure change at work the last two-three weeks, but hopefully I'll be apply create a branch and a (dev) release already on Friday this week.

That would be awesome! :)

Sounds great... I'm very excited to test out the forthcoming Drupal 7 branch! :-)

--Ben

The first Drupal 7 release of Views Send is now available.

I'll do my best to maintain it.

Hooray!!! Thanks :D!!!

I wanted to followup here and mention that I just went to get a git checkout of Views_send in preparation of filing some D6 patches and I saw that I have code commit access. Apparently I received that a year ago and forgot that I had it.

So, I could have committed the D7 work here instead of waiting for the webmaster team to help out but didn't realize I had that ability. Sorry about that! On the bright side, I'm glad that hansfn now has commit access and is helping to push the module forward!