Compared to Tattler, one of the weaknesses of Managing News is the lack of topic monitoring - where a user inputs a keyword phrase representing a topic and the system takes care of tracking this topic across pre-selected RSS sources.
Soon after we started using Managing News, this requirement came up.
Here's the situation: when a change occurs on a node, you want to modify a bunch of related nodes accordingly. On my site, when a Job's state moves from "accepting proposals" to "in progress", I want to change all pending Job Offers (those that haven't been accepted yet) to "closed".
I rely on actions extensively to build functionality in my sites. I find them convenient for business logic because they are packaged chunks of functionality that can be called from many places, including Trigger, Rules, and VBO. Today, I've added a new place where actions can be called: the URL. Actions REST provides this functionality.
Consider a job site where a supplier receives an invitation to participate in a project. The supplier logs on the site and views the invitation, then wants to accept or decline it.
It's no secret that version control on Drupal is hard. Specifically, the problem of iteratively building a site on a staging server, then moving it to a running production system has been the source of countless wasted hours, lost data, pulled hair, blog posts, and modules promising a solution. On Twitter, some would say #drupal #migration #fail.
This post is not the answer to this problem. I just want to show actual code that helps with a small part of it, namely keeping views under version control.
Actions are a convenient way to package functionality in reusable chunks that can be called upon specific events. Countless modules expose actions, and at least the following consume them:
I found it useful to manually call actions in the business logic as well, typically during form submissions or in