Event: Content is going to be edited

Use the content is new condition + Content is going to be saved

Ah, I see. I fear thats currently not possible as there is no suiting event.

So there is a core event that's part of hook_nodeapi called 'prepare' which triggers when "The node is about to be shown on the add/edit form." So, maybe this would work?

@benone, no this is not in dev (version 6.x at least), so to help get it in, it would be great if you could test the patch in #6 and provide your feedback.

@jrguitar21: That's really sweet you posted this patch. It looks very elegant and appropriate for full node_api coverage. Fortunately/Unfortunately, fago is almost laser focused on D7, so AFAIU, the 6.x-1.x-dev branch is mostly there for backports and bugfixes. Therefore, I highly encourage you to post this as a patch to Rules 7.x-2.x-dev along with the 6.x-1.x-dev ver.

In my best guess, incredibly similar code would go into events.inc and wrap around hook_prepare or hook_node_prepare.

Ok.. so I havent looked at d7 much at all and definitely haven't looked at Rules D7. A quick look at the api, seems to suggest to me that we'd use hook_node_prepare, instead of hook_prepare, 1) because this action is node specific, and 2) hook_node_prepare runs later, providing an opportunity for other modules to react to this event first? Or is it better to get rules to react first?

That sounds neat. Let's implement it for D7 first, then we can add an analogous d6 version.

#11 sounds good. Rules should always react after the modules.

+1 subscribe

+1

(Workflows in D6 with moderation based on taxonomy terms would benefit a lot from this. See : http://drupal.org/node/362105)

+1 for this new event (D6)

The maintainer has already said he wants it done in d7 first. there is a working patch for d6 above. please leave this set to the d7 branch.

D7 patch, tested here and confirmed to work, it triggers on node add and node edit forms and you can use the 'entity is new' or 'node is new' conditions to single out for new versus edit form.

Now that I've looked at the d7 code, I'd bet that with the new entity system we could add in a complete set of rules triggers for all the CRUD methods for any entity type (nodes, comments, users, etc). that was a stupid comment :/ sorry. I see that all crud triggers have been implemented for users/nodes/comments.

grrr. is this patch serious flubbed? try again...

About the patch in #6 (for D6)

Applied it manually and it works, although I think it would need to be re-rolled to sync with latest version (+ - lines changed)

Patch does not apply.

reroll.

Please Ignore this patch. :D

hmm... opening the patch in #22 it is written :

name = Wordpress import
modules/wordpress_import

HAHA. oops sorry. working on two things at once.

the **right** module this time...

--- 98,107 ----
+ }
+ ¶
  function rules_node_delete($node) {

trailing white space

Powered by Dreditor.

Thanks. Also I don't think we should add the unchanged content variable, as it probably will just confuse users (what's the difference to the "edited content"?). I don't think one wants to compare the edited content with the unchanged content anyway, so having just "edited content" should be fine.

Also, could we get a small rule in the tests (core integration test case) making use of the event? test coverage ++

subscribing

Is this going the be in anytime soon?

Updated the D7 patch to use the Entity API, I looked at the testEntityIntegration() test in tests/rules.test but don't have the first clue about how to create a test for this. Perhaps someone with a little more experience with Rules and the test framework could provide some help.

Forgot the actual patches....

fixed whitespace issue on patch in #31.

+++ b/modules/events.inc
@@ -47,6 +47,22 @@ function rules_entity_view($entity, $type, $view_mode, $langcode) {
 /**
+ * Implements hook_entity_prepare().
+ */

There is no hook_entity_prepare(), only hook_entity_prepare_view() or am I missing something?

Also: that hook is triggered when entities are viewed, not edited?

+++ b/modules/events.inc
@@ -47,6 +47,22 @@ function rules_entity_view($entity, $type, $view_mode, $langcode) {
+  $entity_types = array(
+    'comment' => TRUE,
+    'node' => TRUE,
+    'taxonomy_term' => TRUE,
+    'taxonomy_vocabulary' => TRUE,
+    'user' => TRUE,
+  );
+  if (isset($entity_types[$type])) {
+    rules_invoke_event($type . '_prepare', $entity);
+  }

You invoke the event for all this types, but you register the event for nodes only?

The event sounds very useful, sad there is only the hook for nodes.

Hrm, yes. That sucks. I'm considering filing a core issue about this. From a quick glance over system.api.php, I see no other obvious way to hook in before displaying an entity edit/add form. The only thing I can come up with is executing the trigger inside a hook_form_alter that checks to see if its a node-edit node-add form. Thoughts?

just implement hook_node_prepare() and add the event "Content is going to be edited", so that it at least works for nodes.

There is http://drupal.org/project/entity wich extends the entity API. But there is no prepare in there either....

@fago, per #34, could this be implemented for user profiles via the Profile2 module, or is that modules hooks dependent on user hooks?

Attached patch uses hook_node_prepare(), in a parallel way to the existing user-specific event hooks like hook_user_login().

Yes, it's a shame we don't have an equivalent hook with other entity types. But for nodes this is very handy, e.g., for conditionally assigning default values to fields on new nodes.

Here's a sample rule to test the event with. Assumes a 'page' content type. Import the rule and then visit node/add/page. You should see the new node has a default title of "New page by [your username]".

{ "rules_set_page_title" : {
    "LABEL" : "Set page title",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules" ],
    "ON" : [ "node_prepare" ],
    "IF" : [
      { "node_is_of_type" : { "node" : [ "node" ], "type" : { "value" : { "page" : "page" } } } },
      { "data_is_empty" : { "data" : [ "node:title" ] } },
      { "entity_is_new" : { "entity" : [ "node" ] } }
    ],
    "DO" : [
      { "data_set" : { "data" : [ "node:title" ], "value" : "New page by [node:author]" } }
    ]
  }
}

Add summary.

The rule in #40 doesn't work as intended. When testing it, I get a new node created before the node/add form is created. Does setting a value on a node trigger a save operation? Is there a way to set an entity value without triggering a save?

This issue doesn't necessarily invalidate the patch, but does limit its use cases and provide potential confusion.

Tried to address the issue noted in #41 by setting 'skip save' to TRUE for the node_prepare event, updated patch attached, but that didn't seem to fix it. Other testers or suggested fixes?

I just added the core issue #1537452: Generalize hook_node_prepare() with hook_entity_prepare().

sorry for trying to push in more in to this, but it should be a good idea to put it here at least I feel so,
"The going to be" actions may be extended to 'going to be created' , 'going to be edited(updated)', 'going to be deleted'. these feature requests were in request que. and should be applicable to nodes and entities as well.Please consider.

@kaizerking: support for all entities would require a solution to the core issue colan posted, #1537452: Generalize hook_node_prepare() with hook_entity_prepare(). To distinguish between add and edit, you can use an entity is new condition in your rule. "going to be deleted" is probably not relevant here since hook_node_prepare() applies only to add/edit. It's true that there is a delete form for a node, but IIRC only the ID and title are used and I'm not sure there's a strong use case to alter either.

My point is with reference to this request here Entity, node going to be deleted Since the current issue is for an action"going to be"I have high lighted.

@kaiserking: The "is going to be" convention seems to have been D6-only. The first commit of node.rules.inc in D7 uses the "Before" convention. The fact that "Content is going to be saved" occurs in rules.api.php may not mean much.

@nedjo: The word "passing" is not really user-friendly. On account of hook_node_prepare(), I propose "Before showing content on the add/edit form".

I guess the component terms have changed.

Also, the 'skip save' attribute should be on the variable. Something along the lines of:

  $variables = rules_events_node_variables(t('edited content'), TRUE);
  $variables['node']['skip save'] = TRUE;

Any chance this made it into 6.x-1.5?

By the way the D6 patch in #31 worked great for me.

Patch in #42 solved my problem in D7 allowed me to create a rule that fires when someone of a certain role tries to edit a particular node type. By combining this patch's "Before passing content to the add/edit form" event with a "NOT Entity is new" condition and a "node:status" text comparison matching "1" condition, I can now allow creation of the node and editing of unpublished nodes, but prevent editing of nodes once they've been published.

Thanks! I had been banging my head up against this for a while.

See #49 - skip save needs to move.

Improve #42 with #49. New patch.

bot

This is exactly what I need, however it only runs on node content - anyone have any pointers on how to include entityforms? a basic pointer would be immensely appreciated
Thanks!

@alibama: see the issue summary above for explanation of why this patch addresses only node entities.

@alibama #55: way back in #35, i suggested that a trigger could be added inside a form alter hook, though it would take some experimentation on how and when to trigger it correctly.

Explain more about current patch.

What is the status of this feature? Is it already in a dev version?

@kitikonti: Changes aren't in dev releases until they're marked "Fixed". Feel free to move things along by reviewing the code (or having someone else do it) and testing it. If everything is okay, the state can be changed to RTBC.

1. +++ b/modules/node.rules.inc
   @@ -18,6 +18,13 @@ function rules_node_file_info() {
   +  // submitted.  ¶
   

   Has some whitespace here.

2. +++ b/modules/node.rules.inc
   @@ -18,6 +18,13 @@ function rules_node_file_info() {
   +  $variables['node']['skip save'] = TRUE;
   

   Let's better just assign that for node_prepare *below*, so it's obvious this only applies to node_prepare.

Here is a re-rolled patch of #53, which includes the first change noted at #60. I have not added the second suggested change, since I was not entirely what was supposed to be edited. Leaving it as Needs Work for now.

Patch #61 works for me*. Thank you.

* if I disable the jammer module - the "Generic Jammer" in particular

This patch #61 works for me too. It is super helpful!

I'll see if I can find the time to figure out what fago wants us to do in the 2nd part of #60

PostgreSQL test fails because of #1627174: Error in rules Scheduler module on PostgreSQL, it's not the fault of this patch.

This is a re-roll of #61 against HEAD.

I have also addressed @fago's second comment from #60.

I added a "Needs tests" tag.

We are not really adding new features to D7 anymore, but since there's been a patch here for a long time I'll still consider it. BUT at a minimum this patch should include a test for this new event, in RulesTestCase::testNodeIntegration().

Following TR's feedback on the related thread I created for D8 #3130326 - I am continuing the discussion here.

I have partly ported this patch to D8 following the same principles (but using the hook_entity_prepare_form).

2 main things remaining:
- Tests: I have added the Unit test for that Event, but I am not expert in Kernel tests. What would be the best way to simulate the form going to be displayed (to trigger the hook)?

- I have the same issue as reported in #41 that the entity is created if you set a value, which may not be the desired behavior. I am wondering what the best way to overcome that issue would be, and I thought that maybe it would be best to do it in RulesAction:dataSet where we can add an option to enable or disable the autoSaveContext. What do you think?

Attaching patch & running tests

hi
i was using #65 on D7 that was working great until today where i just noticed that when editing a node (with or without condition), actions are not fired.

There is no problem for when adding a new node

###EDIT###
SORRY IT IS WORKING AS EXPECTED... there was another condition from custom module that was not correctly working... so IT IS WORKING correctly for ADD and EDIT

I would love to use #67, but I just read that the following would still need to be added in a D9 equivalent way:

$variables['node']['skip save'] = TRUE;

Any ideas on how we can achieve this? I really miss this feature from D7.

@vdsh: Is it possible that the solution provided in #3172088: The "Set a date value" action results in an infinite loop if it's using in the "Before saving a content item" event at comment #7 could be the fix for this issue as well?