Expose Reservation Status fields to be used in Rules

channelAustin uses a module that emails staff guides for the producer that makes the reservation so they can review and approve their reservations. The staff guides are defined in CiviCRM for all members. That module is about 25 lines of code. Rules is tens of thousands to do the same thing. I contributed to https://www.drupal.org/project/merci_email > 3 years ago. That module did something similar to what you want for MERCI in < 150 lines.

I'm willing to review patches to improve Rules integration, but since I consider Rules an inefficient hack used by people who can't write code I'm not going to invest any time in this. If MNN wants to fund an update/port of merci_email to reservations_email that includes this functionality it should take < 5 hours to complete.

Since I can't code. I created a Rule to send acknowledgement and Confirmation emails. I added a Boolean field type -send email y/n- and a text field for comments- confirm, denied etc- to Reservation form. If yes is selected, Rules sends an email. Not the most elegant solution, but it gets the job done.

The reason @soniat's work around works is similar to change we made to how we were handling the Title field in Airings for #1880466: Title isn't mappable using Feeds w/ Entity Parser. The Reservation status field isn't defined as a field the way we defined the Reservation Date field or Airing's Title. As a result, additional code would have to be added to allow other modules like Rules, Feeds, and Tokens to "see" these values. With the Date field, it was easier to add the field programmatically and then lock it so that users couldn't make changes that broke it. Because the status is a simple list of options and we need those options to mean something to the Reservations API, the field is added to the form by the module and the values are stored in a custom table (the old fashioned way). The reason why these decisions were made go back to 2008 and the early days of "hybrid" development in D6 where custom modules relied on specific fields on a content type. You'll notice that @fago (one of the maintainers of Rules) weighed in about support for locked fields in Workflow-NG (Rules before it was called Rules).

Keep in mid that when that discussion was happening, it wasn't possible to lock CCK fields. The Open Media Project was the first large project to use this approach. I still stand by what I wrote in https://groups.drupal.org/node/12984#comment-44038

My goal is to allow users who understand the dependencies to extend our core Open Media content types, but prevent a change that is relatively easy to make in the CCK UI and impossible to reverse from breaking things. Giving stations, libraries, and other Open Media users the ability to build Views of this content is an important feature, so the approach Eaton took with the Amazon module is not going to work.

I've opened #2305179: Use core fields for Reservation Status in 3.x to consider making in a similar change to what we did in Airings in the 3.x branch of Reservations.

the module mentioned in comment #1 is not 25 lines of code, it is 479 lines of code and based on what I understand to be a completely different workflow and data structure. As such, I don't see it's usefulness or relevance to this discussion.

While kreynen's statement "Rules an inefficient hack used by people who can't write code" is in some ways true, the same could be said about Views. Before Views existed as a module, we all had to write custom functions to query and display aggregations of drupal data. I doubt anyone would argue that views should not be used since anyone that really knows how to write code could do what views does.

The reason that people, even those that can write code, use views and rules is that they can be much more efficient in terms of developer time -- and they can empower less skilled people to take on more important roles in drupal related projects.

As such, I think that closing this as Won't Fix because of an ideological objection to Rules -- especially given the reality that most CM Drupal sites are using Rules is a mistake.

I'm going to re-open this as active because MNN has certain needs, such as sending emails upon approval of a reservation, that will certainly be of use to other stations and if that can be achieved by making this data accessible as a token that could be used in many different places, that seems like a better path forward.

As a workaround, MNN might have to start with a computed field using 3 lines of code and a rule that can be created in 5 minutes. This could easily be shared in a way that can easily be added to any other site that needs it -- either via a feature or even just a simple recipe that can be manually added via the admin interface (add a computed field, add a rule) by those stations that want this feature.

Or you could install https://www.drupal.org/project/reservations_email

especially given the reality that most CM Drupal sites are using Rules is a mistake

Since I think I have access to the most CMD sites, that is not my experience... but it wasn't marked as won't fix because I personally don't like Rules.

This was marked as won't fixed specifically regarding adding more code to the 2.x branch to increase the support for Rules. Changing the status field from something that is stored in a custom table to using a field is a big change which is why I suggested #2305179: Use core fields for Reservation Status in 3.x for the 3.x branch.

That change would enable Rules (as well a Conditional Fields, Feeds, Features, Node Export, etc) to access to the status value AND also allow us to remove code that exposes custom values to Views and Tokens and just rely on the core field functionality like we do with Date. It would also allow things like easily adding additional statuses.

The reason reservations_email is more than 25 lines is it includes a UI and option to configure it, token support, etc. To send an email when a Reservations node is confirmed with a custom module, it would look something like...

MYCUSTOMMODULE_node_save() {
  if ($node->type == 'reservations_reservation'  && $node->reservations_reservation_status == RESERVATIONS_STATUS_PENDING ) {
    
    $account = user_load($node->uid);
  
    $params['account'] = $account->mail;
    $params['topic_title'] = $node->title;
    $params['topic_author'] = $node->name;
    $params['topic_nid'] = $node->nid;
    $params['node_type'] = $node->type;
    
     drupal_mail('MYCUSTOMMODULE', 'notice', $account->mail, user_preferred_language($account), $params);
     
  }
}

That's just pseudo code but it gets you 90% of the way there with plenty of lines to spare to add additional formatting and your own custom email message.

channelAustin already does something similar, but they email each members staff guide when an unconfirmed reservation is created. The staff guide assigned to each user is configured in CiviCRM. There are other custom modules that email the studio manager when new studio reservations are created. Unfortunately these rely on configuration specific fields, taxonomy ids, etc. so they can't be shared beyond generalize snippets like this.

thanks for posting the link to the module that actually addresses this issue, it would have been great if you could have posted that to this issue earlier in response to synchlayer question about porting the module, it would have saved duplicated effort.

posted an issue to that reservations email page, seems that the module is broken so I guess we're going to take the computed field and rule path to get this done

we'll share the field definition and rule export when we are done so other stations can get some benefit from out workaround for these problems

just a warning for anyone that follows the link to the reservations_email module, in testing it instead of sending an email to only the user who's reservation was edited, it emailed all 2345 producers in the system.

I'll post my rule/computed field recipe here in the next day or two which should prove to be a more stable and useful way of sharing this functionality

Wow. I really hope you meant that you would have emailed > 2000 producers if email was enabled on the dev environment you were installing and testing a dev snapshot of module you'd never used before. reservations_email was a fork of https://www.drupal.org/project/merci_email. While I helped get that project started, I hadn't done anything with it in > 3 years before this fork. The D7 version was entirely written by @jack_tux.

I've update the UI and menus of reservations_email to address #2337141: white screen trying to load the config page and form field descriptions to address #2337151: sends email to every user of the selected role.

I think the roles option was intended to email a staff group in addition to the user who created the node (or is configured in the Author field when using reservations_staff). I don't really know what the use case was for adding the role functionality was, but I've tried to make it clear in the update that's what that settings does and removed the authenticated user role as the default for the variable.

If you actually emailed all users of a role, you should really read these tips for how to configure your dev environment to prevent something like that from happening again...

https://www.drupal.org/node/201981
http://wiki.civicrm.org/confluence/display/CRMDOC/Debugging+for+developers

the devel module used to have a nice option on the devel/setting page that allowed you to check a box to change smtp to 'log only'

I had assumed this was set but it seems, from your link, that it no longer works that way and requires a manual change to settings.php.

thanks for the info