Hi

Thanks alot this great module. I have a content type with a filefield and I would like to have that content type being saved immediately whenever a file has been uploaded. I tried with rules module and I couldn't get it worked. If possible can somebody please help me out to create that kind of rule.

Thanks
Hlan

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mitchell’s picture

Title: Create Content with autosave » File API events
Version: 6.x-1.x-dev » 7.x-2.x-dev
Category: support » feature

To have this type of functionality in Drupal 7, there would need to be events, such as 'when file is uploaded' or 'when file is saved'. This would probably be part of a larger set of integrations, but if you would like to start, I believe the function you're looking for is file_save_upload().

For more information and a list of functions and methods in FIle API, see http://api.drupal.org/api/drupal/includes--file.inc/7

fago’s picture

Indeed, we should events just as for any other entity type too. Patch welcome.

stevector’s picture

Status: Active » Needs review
FileSize
3.83 KB

Here is a starter patch in this direction.

It adds _insert, _presave, and _update events. There are plenty of other file related hooks that could also have events which I document in a @todo in this patch.

I also put a @todo in the comments for ules_file_integration_access(). I don't know what it does exactly. I copied and modified from node.rules.inc

fago, how much do you want done before a patch like this could go in? I'm sure there are also plenty of file related conditions that could go in a hook_file_rules_conditions_info()

Status: Needs review » Needs work

The last submitted patch, file_events-826986-3.patch, failed testing.

stevector’s picture

I'm unsure if those test results mean that mailing breaks or that mailing for those events breaks.

Coincidentally I did my testing for those events with mail actions and a dsm() inside of drupal_mail() and they worked.

Here are the Rules I used:

Presave:

{ "rules_mail_on_node_presave" : {
    "LABEL" : "mail_on_node_presave",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules" ],
    "ON" : [ "node_presave" ],
    "DO" : [
      { "mail" : {
          "to" : "persch@palantir.net",
          "subject" : "Hi - Node Presave. [node:title]",
          "message" : "hi",
          "language" : [ "" ]
        }
      }
    ]
  }
}

Insert:

{ "rules_mail_on_file_insert" : {
    "LABEL" : "mail_on_file_insert",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules" ],
    "ON" : [ "file_insert" ],
    "DO" : [
      { "mail" : {
          "to" : [ "file:owner:mail" ],
          "subject" : "file insert",
          "message" : "insert a file\r\nnew name: [file:name]",
          "language" : [ "" ]
        }
      }
    ]
  }
}

Update:

{ "rules_mail_on_file_update" : {
    "LABEL" : "mail_on_file_update",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules" ],
    "ON" : [ "file_update" ],
    "DO" : [
      { "mail" : {
          "to" : [ "file:owner:mail" ],
          "subject" : "File Update. [file:path]",
          "message" : "Saved a file\r\n\r\nold name: [file-unchanged:name]\r\nnew name: [file:name]",
          "language" : [ "" ]
        }
      }
    ]
  }
}
mitchell’s picture

Status: Needs work » Active

Issue to fix the broken test: #1540266: Fix broken simpletests.

Dave Reid’s picture

Status: Active » Needs work
+++ b/modules/file.rules.incundefined
@@ -0,0 +1,85 @@
+     * hook_file_delete

This hook should definitely be covered in the patch but isn't currently.

mitchell’s picture

Component: Rules Engine » Rules Core

Marked #1343788: Set a data value: add file to a node as a duplicate of this issue.

griz’s picture

File Entity and Rules. I'm so excited that I'm going to apply the patch without backing anything up.

griz’s picture

It's all good.

Needs work --> RTBMe

semei’s picture

Is this issue taken care of in 7.x-2.x-dev?

rlmumford’s picture

Is there any progress on this patch?

rodrigoaguilera’s picture

I think this issue is about files in core and not about file entities (fieldable files), am I right?

Dave Reid’s picture

Correct, this is about the core file entity and not related to the file entity module in contrib that extends the core file entities.

rodrigoaguilera’s picture

Ok, I was confused because I don't quite understand the arquitecture of file_entity but this patch allowed me to trigger the event for when a file_entity is created and set values.

I understand that next thing to do to get this patch in stable is to solve issue #1540266 but another RTBMe here

rlmumford’s picture

Status: Needs work » Needs review

#3: file_events-826986-3.patch queued for re-testing.

fago’s picture

Status: Needs review » Needs work
+++ b/modules/file.rules.inc
@@ -0,0 +1,85 @@
+    /**
+     * @todo, add support for more file module hooks.
+     * Eligible hooks include:
+     * hook_file_copy
+     * hook_file_delete
+     * hook_file_download
+     * hook_file_download_access
+     * hook_file_download_access_alter
+     * hook_file_load
+     * hook_file_mimetype_mapping_alter
+     * hook_file_move
+     * hook_file_url_alter
+     * hook_file_validate
+     *
+     * Some of these might not work as Rules events.

As #7 said, file delete sounds reasonable to include with this patch. Let's add that before committing this.

+++ b/modules/file.rules.inc
@@ -0,0 +1,85 @@
+ * @todo, this is modeled on rules_node_integration_access(). Not sure what it does.

It's used to check for non-super-admins whether they are allowed to use this events.

fago, how much do you want done before a patch like this could go in? I'm sure there are also plenty of file related conditions that could go in a hook_file_rules_conditions_info()

I think we could start with just the events and have more in follow-up issues. Unfortunately we do not have test-coverage for events yet, so we have to rely on manual tests only here :(

semei’s picture

Are there any news concerning this issue? I think thank file API events would be a great improvement of this module.

rogerpfaff’s picture

This patch fails in my installation of 7.x-2.x-dev

patching file modules/events.inc
Hunk #1 FAILED at 52.
Hunk #2 FAILED at 68.
Hunk #3 FAILED at 84.
3 out of 3 hunks FAILED -- saving rejects to file modules/events.inc.rej
patching file modules/file.rules.inc
patching file rules.rules.inc

SocialNicheGuru’s picture

Issue summary: View changes

the patch no longer applies to the march 18, 2014 dev version

SocialNicheGuru’s picture

deleted comment. found out how to add fields: add the fields you want to the conditional area.

paulihuhtiniemi’s picture

FileSize
4.34 KB

Here's an updated version of the patch that should work with latest dev version. Didn't add any new events.

AjitS’s picture

Status: Needs work » Needs review
AjitS’s picture

Status: Needs review » Reviewed & tested by the community

Thank you for the patch! I have confirmed the patch works for me without any issues. It's been long time on hold on a review; so being bold and marking it RTBC.

fago’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/modules/events.inc
    @@ -56,6 +56,10 @@ function rules_entity_view($entity, $type, $view_mode, $langcode) {
    +      rules_invoke_event('file_presave--' . $entity->type, $entity);
    

    Is file type there if file entity is not used? I don't think so?

  2. +++ b/modules/file.rules.inc
    @@ -0,0 +1,85 @@
    + * @file rules integration for the file module
    

    Missing trailing point.

  3. +++ b/modules/file.rules.inc
    @@ -0,0 +1,85 @@
    +     * @todo, add support for more file module hooks.
    +     * Eligible hooks include:
    

    Let's open an issue for that but remove the comment. We do not have todos for adding new features else.

  4. +++ b/modules/file.rules.inc
    @@ -0,0 +1,85 @@
    + * Returns some parameter suitable for using it with a file
    

    Missing trailing point.

  5. +++ b/modules/file.rules.inc
    @@ -0,0 +1,85 @@
    + * @todo, this is modeled on rules_node_integration_access(). Not sure what it does.
    + * It does not seem to get called.
    

    It's called from the ui. should be fine, but comment nees to go.

mtoscano’s picture

I tried the patch and actually it works, I can now receive an email notification when a new file is uploaded, thanks!
Anyway the event is triggered as soon as the file is uploaded and not once the file is saved. So for example using it in combination with Media module 2.x and File Entity, you cannot use tokens coming from file fields, as they are filled once the file has been uploaded and before saving the file.
Trigger the Action once the file entity is saved it will be a better option.

spgd01’s picture

any news on a commit?

drupalevangelist’s picture

Could you commit the patch #22 to the latest dev release?

melonangie’s picture

FileSize
751 bytes

Applied patch #22 to rules-7.x-2.x-dev, got this message.

patching file modules/events.inc
patching file modules/file.rules.inc
patching file rules.rules.inc
Hunk #1 FAILED at 21.
1 out of 1 hunk FAILED -- saving rejects to file rules.rules.inc.rej
melonangie’s picture

FileSize
580 bytes
Ace Cooper’s picture

I needed this feature as well and I ran into the same problem with applying the patch. Here is quick fix for patch #22 to apply cleanly to latest rules-7.x-2.10, though without any new features. I will look into all fago's suggestions and include them in the next patch.

P.S. For anyone like me looking to attach the uploaded file to the entity image field via Rules with Set Data Value (which only accepts field_item_image) - try the wonderful module File System Rules. It provides a new action "Add file to the list" which is exactly what I needed. Don't forget to add another action to save your entity after you added the file to the list.

NWOM’s picture

#31 worked perfectly. Thank you!

Toki’s picture

I am using the patch #31 and it's working great (see here details) Many thanks for that.

Now, I would really need a "When removing file from content" event.
Is it available somewhere or anyone knows how to fire a Rule when an image (file) is removed from an Image field (with multiple values)?

Another question here if you have any tip.

Thanks.

NWOM’s picture

@Toki: You can compare the field value before/after as a condition. So have two conditions: "before: has value" and "after: empty" with each using the "compare" condition.

Toki’s picture

@NWOM, do you mind elaborating your answer here or on Drupal Answers? I have tried to follow your suggestion but it is really tricky to build condition with File/Image fields. Thanks in advance.

TR’s picture

Issue tags: +Needs tests

Patch in #31 still applies. BUT @fago's concerns from #25 were not addressed in the patch, so this is still "Needs work".

Likewise, testbot shows that the patch introduces 9 new coding standards violations. These should be fixed.

While the testbot shows that all the tests pass, that's not surprising because this patch doesn't test any of the new added features. There really should be tests to accompany these new features, especially this late in the D7 development cycle.

Toki’s picture

I'm afraid the patch in #31 is broken since the last Drupal Core update. Could it be fixed @Ace Cooper? Thanks in advance
EDIT : my bad, it works, sorry for that...

Toki’s picture

[SOLVED] Finally, it seems broken since the last Rules update (march 19). I have built a simple Rule based on After updating existing file and I can not access the file updated values anymore, only file_unchanged. To reproduce, simply create a Rule with event After updating existing file, add an action (for me Execute custom PHP code) and browse the replacement patterns or variables available, you should find only site and file_unchanged. I have tried with a Fetch entity by ID, using file_unchanged:ID but it did not work either. Any idea here?

EDIT : The Rules evaluation log displays : Unable to load variable file_unchanged, aborting

EDIT2 : after several tries, actually, I can not access the file values at all (type Image with custom fields) using the event After updating existing file. The variable file_unchanged (and I guess it should be possible with another variable called file as updated file) is not accessible and can not be loaded?

EDIT3 : finally, I found a mistake in my patch (probably entirely my fault), in file.rules.inc (line 64), $args += array was $args = array, in the section returning parameters (the famous file_unchanged).

shevgeny’s picture

Is there any news in this area?

Andras_Szilagyi’s picture

Status: Needs work » Needs review
FileSize
6.04 KB

Attached patch that fixes issues mentioned in #25 and adds a test that asserts the new file events under class RulesTestCase.
Also fixed

FILE: ...vironment/drupal2/sites/all/modules/rules/modules/file.rules.inc
----------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------
 12 | WARNING | Format should be "* Implements hook_foo().", "*
    |         | Implements hook_foo_BAR_ID_bar() for xyz_bar().",, "*
    |         | Implements hook_foo_BAR_ID_bar() for
    |         | xyz-bar.html.twig.", "* Implements
    |         | hook_foo_BAR_ID_bar() for xyz-bar.tpl.php.", or "*
    |         | Implements hook_foo_BAR_ID_bar() for block
    |         | templates."
----------------------------------------------------------------------
TR’s picture

Thank you. I will try to review this entire issue and take a look at the patch in detail over the next few days.

In regards to "Implements hook_rules_event_info() on behalf of the file module." ...
These hooks, in modules/*.rules.inc, are not exactly Drupal standard. For example, you can see that rules_file_event_info() does NOT implement hook_rules_event_info(), because if it did the name would have to be file_rules_event_info() instead. What is happening is that Rules is implementing that hook for the file module (because an implementation of a Rules hook cannot be put into a core Drupal module) and is using a different naming convention to distinguish this from a "true" hook and to prevent namespace conflict in the case where some other module wanted to add more file events.

phpcs doesn't know about this - it thinks that this is a standard hook implementation and demands a standard hook comment. But this is not a standard hook implementation, and we've chosen to consistently document these hooks with a comment in the form "Implements hook_rules_event_info() on behalf of the file module." to point out this difference. I would like to keep it that way.

I don't want to change the documentation comment just to please phpcs. I guess we could just put in @codingStandardsIgnoreStart/@codingStandardsIgnoreEnd tags on all these, but I don't think it's worth the trouble.

My focus is on preventing NEW coding standards violations when committing patches. This patch adds 4:

modules/events.inc ✗ 3 more
line 70	Case breaking statements must be followed by a single blank line
103	Case breaking statements must be followed by a single blank line
136	Case breaking statements must be followed by a single blank line
modules/file.rules.inc ✗ 1 more
8	Separate the @addtogroup and @{ sections by a blank line.
Andras_Szilagyi’s picture

Thank you @TR for the explanation and the feedback, I fixed the mentioned issues.