In the parent meta issue #2269577: [META] Port all actions to 8.x, it was decided the actions in node.rules.inc did not have to be ported:
node.rules.inc
node_publish_action', 'node_unpublish_action', 'node_make_sticky_action', 'node_make_unsticky_action', 'node_promote_action', 'node_unpromote_action- those are covered in Core already
These actions were deliberately left out of the initial port of Rules to D8 because at that point Rules was using core Actions. Because core Actions in D8 already defines these actions, it didn't make sense to duplicate that functionality in Rules.
However, once Rules had to fork Actions to be RulesActions the core Actions no longer work, so they DO need to be ported to D8. Unfortunately no one considered this when the fork was made, so that part of the meta was never reopened.
Note that these are in a sense convenience actions. That is, all these things can easily be done using the existing data_set action, so they're not strictly necessary. However, having them in D8 makes it easier for inexperienced users or for users who are familiar with D7 Rules and expecting the same actions in D8.
This should be a simple task - it's really easy to write simple actions like these. Any volunteers?
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 3114756-6-port-node.rules_.inc_.patch | 17.94 KB | tr |
| #4 | 3114756-4-port-node.rules_.inc_.patch | 16.08 KB | tr |
Comments
Comment #2
bojanz commentedI'd expect to have publish/unpublish actions for any entity type implementing EntityPublishedInterface (which means EntityPublish/EntityUnpublish + a deriver for each).
Perhaps it makes sense to move those two to a different issue, while doing the node-specific actions here?
Comment #3
tr commentedYes, I agree.
I'll leave that up to whoever does the port, but yes it probably makes more sense to split them because the deriver/derivitave implementation is a little more involved.
Comment #4
tr commentedComment #5
tr commentedI didn't do the derivative thing as suggested in #2 because Rules really operates just on Typed Data datatypes (Entity for instance, or Node) - objects that implement EntityPublishedInterface are not separate Typed Data datatypes in Drupal. While all content types (Nodes) implement this interface, not all Entities do. So for Nodes we know we can always publish/unpublish, but for Entity datatypes that ability may be missing. Type checking based on interface implementation rather than datatype is not something that is currently built into Rules, and adding it just for this case doesn't seem very high priority to me.
As I said above:
Specifically, if an Entity implements EntityPublishedInterface we can still publish/unpublish it using the data_set action. We don't need a separate action for each Entity type.
The place where the convenience actions are most useful is with Content types, as those are the user-facing concept in Drupal that all users should know about and need to use. So the patch above implements the 6 node-specific actions mentioned in the original post, with tests. I'm planning on doing a little manual testing before committing this, and I'd like to get some reviews/feedback also.
Comment #6
tr commentedManual testing shows #4 doesn't work because the node context wasn't marked for autosaving. Here's a new patch, including modifications to the tests to check the autosaving.
Comment #8
tr commentedCommitted #6.
Comment #9
jonathan1055 commentedNice work. Thanks for doing this.