Assign author of imported nodes

If we get user assignment to nodes we should offer at least 3 options:

- anonymous
- specific user (this screenshot)
- inherit from feed node (only available if an importer config is actually attached to a content type).

I'd appreciate your patch as it's a step in the right direction. Ideally we can get the inherit option before committing. In any case, this feature warrants tests.

I also need this functionality.

In FeedAPI, I had the 'source' content type called feeds, and I had a node that initiated the download/import. In this case, I was able to set the authoring information on that node. All of the resulting imported nodes were then owned by the author information specified. In your example I am guessing this would be 'inherit from feed node'.

In Feeds, I have the exact same setup - source content type Feeds, a CSV feed configured, and authoring information. In this case, it is not respecting the authoring field. All of the resulting imported/created nodes are owned by 'anonymous'.

I don't quite know how to develop this, but I would love to have it fixed if someone submits a patch.

In FeedAPI, it seems this magic happened in feedapi_node.module, in the _feedapi_node_save function. There is a $node->uid = $feed_node->uid; statement right before the node_save($node); at the end of the function. I'm assuming this is what set it.

OK, here is my completely unscientific patch that replicates the functionality from FeedAPI. I simply grab the node ID of the feed node, run a node_load against it, and map the UID. There is probably a better way to do this that doesn't involve node_load, but I really needed this to work tonight.

I'm wondering if it's a better idea to move the node_load above the foreach. That way it is loaded only one time.

#3: certainly one of the puzzle pieces required here. Setting to NW as there's a patch.

Here's a new version of the patch. The only difference is the node_load was moved outside of the loop. Now it just does a single node_load of the original feed node instead of doing it on every loop. I don't believe it would ever change so I don't think it really needs to be done inside of the loop.

Setting the status back, sorry it defaulted to active.

Yes, scenario 1 in #7 will be much helpful and needed very much as this is what happened normally with feedapi-6.x-1.8 and this is what is normally expected in a multiuser scenario.

For example, let us suppose a drupal site like blogger.com, where each user has his blog and wants to occasionally import from feed of his other blogs, like wordpress.com blog or similar. What he imports need to be under his authorship in his blog (irrespective of whether he is the true author or user names are same across the net).

Assign_author.png is good at the "Admin" level, but at user (auth user) level the user needs to simply have the feed items/posts filling up his blog as blog posts (when feed item=blog content type)

Thanks for the patch, I got refererred here from #664348: Blog posts imported by an user do not show up in his blog and will highly be obliged if a patched FeedsNodeProcessor.inc is made available for download as a whole file.

As I'v blogged about at http://hojtsy.hu/blog/2009-dec-17/highlighting-some-tweets-my-blog-exper... I'd be very supportive of this functionality. (Did not test the actual patch yet).

The patch doesn't apply (it needs to be with the module folder as root, not drupal as root).
If applied manually the patch works as expected, but here is a style review.

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -18,7 +18,23 @@
-
+    
+    //The user id to assign to FeedItems

Trailing space on the empty line.
There should be a space after //

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -18,7 +18,23 @@
+    //If Feed is not attached to a Node or inherit author not set assign user
+    //based on the explicit author setting

Agains space after the //

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -18,7 +18,23 @@
+    if (($source->feed_nid=='0')||$this->config['inherit_author']==0){         

It needs space before and after ==, ||, ==. There should be a space between ) and {. There is trailing spaces at the end of the line.

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -18,7 +18,23 @@
+    //Load the user object based on the user name

It needs to be inline with the code below it. It needs a space after //

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -18,7 +18,23 @@
+    //If Feed is attached to a Node check whether user asked for Feed Items to 
+    //inherit from Feed node author

Again space after //. Remove trailing space after the first line.

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -18,7 +18,23 @@
+    elseif ($this->config['inherit_author']==1){

Space before and after ==. Space between ) and {

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -60,8 +76,8 @@
+        $node->uid=$feed_item_uid;

Space before and after =

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -150,8 +166,10 @@
+      'explicit_author'=>'anonymous',

Space before and after =>

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -150,8 +166,10 @@
+    );    

Trailing space at the end of the line (nothing else changes in this line)

+++ sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc	28 Dec 2009 22:00:39 -0000
@@ -181,6 +199,24 @@
+    
     return $form;

No need to add the empty line, but if you do, remove the trailing space.

This review is powered by Dreditor.

Ok so i tested this patch and it works wonderfully. It applied correctly to HEAD. I reworked the patch to patch from the module root and I believe I made all the style changes mentioned above.

Thanks istos & rjbrown99 for the work!

Great.

1. "Feed attached to Node" should be "Importer attached to Content type" - on UI and in code.
2. Add a period after all comments.
3. Can we grey out the widget for inherit_author if the importer is not attached to a content type?
4. Both modes: inherit and explicit need tests.

Some of the code in FeedsNodeProcessor.inc will change if/when #600584: Use Batch API is committed. This patch currently conflicts with #7 in that thread.

Assuming that patch is applied first, only the first hunk of this fails. It's pretty trivial to reconcile, but I thought it was worth mentioning.

Subscribing

thanks a lot. this is exactly what i needed.

edit: as mentioned above this patch isn't working anymore in alpha-11 due to code changes.

I need this feature too!

One idea: create a rule to set the owner when a new feed item node was created!

This is a necessity for a site I am currently working on.
Please fix to work with Alpha 11

Thank you for awesome module

This is great if you're using the Feed API method and attaching feeds to a feed node, but what about support for the stand alone form? In a number of the use cases I've worked with we wouldn't actually want a whole content type just to attach the import form to. Feeds claims support for this, and starts to provide it - but falls very short in a number of cases like this where it goes back to relying on feed_nid.

Right now I'm getting around this by just hard coding a nid in a custom node importer class which is easy enough thanks to the way feeds was built, but some of this would be nice out-of-the-box.

How would you propose UID selection for nodes generated from a stand alone form? One thought would be to provide a drop down or some other form element (perhaps just a field where you enter a UID) on the node processor's configuration. If there are some consistent thoughts on this topic I can likely through together a patch.

#20:

but what about support for the stand alone form?

This is actually taken care of. See the patch in #12 and my suggestion in #13 3.

Revisiting the patch in #12 I notice that we shouldn't store the user's name but her uid. The name can change.

Feeds claims support for this, and starts to provide it - but falls very short in a number of cases like this where it goes back to relying on feed_nid.

There are some rough edges, indeed. One of them that using "feed_nid" as a variable name to identify a source is plain misleading. It should be "source_id" or plain "id" (although that starts to conflict with FeedsImporter's id). However, there aren't many hard assumptions on that feed_nid is actually a node. If there are, we should clean them up. Recently I used feed_nid to attach sources to users (uid = feed_nid) without any problems. Please open follow up issues if you find concrete items that need clarification or clean up. Thanks.

Related: #702734: Rename FeedsSource->feed_nid to FeedsSource->sid and FeedsImporter->id to FeedsImporter->name

Ah, that's what I get for not taking the time to read over the entire issue. Sorry about that Alex. I knew I'd glanced over this in the past and had missed that addition when coming back today.

I'll review the other items I was having troubles with and see what their state is and open issues as needed. Thanks!

Quick re-roll of #12 against CVS HEAD. I tried to account for alex_b's comments in #13, although I didn't see an easy way of doing item 3. I'm not seeing a good way of determining the state of content type attachment from FeedsNodeProcessor::configForm();. If you have some ideas I'd be happy to try it again. Also, no tests. I don't have the time at present to roll them.

I'm not seeing a good way of determining the state of content type attachment from FeedsNodeProcessor::configForm();

The configuration of a plugin is present as an array (from within a plugin) at $this->config.

Right, but within FeedsNodeProcessor::configForm(); $this is the FeedsNodeProcessor object, and $this->config only seems to contain the mappings and items from FeedsNodeProcessor::configForm();. I'm not seeing the content type attachment setting. I'm sure it's probably available, I just haven't found it.

Uh - sorry. The content type attachments are importer level. You can get them through feeds_importer($this->id)->config from within a processor.

There is only one possible importer for a given processor and that is the importer with the same id.

Thanks for the patch but No 3 is the functionality I am chasing. Using the default RSS importer, changed to import blog posts, I need the Author of the imported blog posts to be the same as the author of the feed used to import them.

My php knowledge is is not up to this challenge but I would be happy to test.

Thanks
Gregg

For what it's worth, I moved to using the patch from #12 which does what I originally wanted it to do in #3. I create a node of type feed which contains my feed settings. While editing that node at the bottom in the "authoring information" section, I assign the owner to be the user ID of whoever I want to own the created nodes. During the creation process it correctly sets the owner of the nodes.

Look at your feed node and make sure you have authoring information set to the correct user.

Thanks.

I tried this but my use case involves a variety of different users importing blog posts through Feed.
The posts need to be the same author as the feed and they do not have access to the feed importer settings to manually set a userid

Any other ideas?

Thanks
Gregg

Is there a way to map a drupal user to the author of the feed entry? I'm thinking on matching the feed author field with a profile field on user accounts or something similar. Any ideas?

any updates on this?

is any possibilities to know when this patch will be updated to the latest release?

4vinoth: What you see is the state of the art. Patch should apply against 6.x 1.x dev.

OK alecx, Thanks for the update,
But when I can expect this issue is fixed, because without this i am unable to use this module. :(

#33 - Looking at the movement on this issue in the last days and weeks, I wouldn't wait for anybody. You will either have to step up yourself and work on the patch or get somebody to do it for you. Remember, this is open source ;-)

I applied the patch from #23 - worked fantastically. Are the maintainers of the Feeds module planning on making this a part of the first dev release?

Anyway, thanks for the work you guys put it on this - you got one thankful 'customer' !!

#23: great.

The plan is to commit the patch when #13 - 3 and 4 are addressed. I am looking for volunteers to bring this puppy home.

Subscribe - this causes a headache for content managers who have to sort the imported content, as they have to switch the input format manually from Filtered HTML to Full HTML, since the anonymous user defaults to Filtered HTML :(

I just found this issue. FWIW, I posted a patch on Feeds Inherit settings from parent feed node (like taxonomy). All I did was merge the feedapi inherit code into feeds. So it allows you to have your feed items inherit the following settings from the feed node: organic groups, author, taxonomy, and language.

Should one of these issues be marked as a duplicate of the other?

#39: Indeed, there is overlap on the inheritance patch that picked up speed now: #632920: Inherit properties from parent feed node (taxonomy, author, OG, language). That patch will cover the inherit author option. This patch can now focus on assigning a specified user to a feed item.

#38: this question is now not relevant anymore, but what you're looking for is: feeds_importer($this->id)->config['content_type'].

The contradiction is pretty self explaining, right? I would suggest to deal with this on validation - throw an error with a brief explanation if both options are set:

"A feed item cannot both have an assigned author and inherit its author from the feed node."

I can confirm that patch from #39 works nicely to fix the author inherit issue.

It does not seem to be inheriting the authors default input filter so all imported items still default to the site default which in my case is plain text.

I second #30.

The best approach strikes me as a custom mapper that tries to find the source author in the local usernames. Failing that, default to the selected UID assignment described here.

Should something like this be in a separate project?

/**
 * Implementation of hook_migrate_fields_node().
 */
function feeds_usermapper_feeds_node_processor_targets_alter(&$targets, $content_type) {
  $targets['uid'] = array(
    'name' => t('Node author'),
    'description' => t('The owner of the node.'),
    'callback' => 'feeds_usermapper_feeds_set_target',
  );
}

/**
 * Mapping callback for author.
 */
function feeds_usermapper_feeds_set_target($node, $target, $value) {
  // [insert optional username transformation here]
  $user = user_load(array('name' => $value));
  if (isset($user->uid)) {
    $node->uid = $user->uid;
  }
}

subscribing

subscribe

#44/#30: yes. This patch should either accept a uid or a name for specifying an item's author.

#23 accepts a name.

In order to make sure we're all on the same page, I'll reiterate what I've stated in #40: #632920: Inherit properties from parent feed node (taxonomy, author, OG, language) will cover inheritance of authorship from feed nodes, hence this patch can focus on assigning a specific author user to a node.

subscribe

I applied the patch in #23 to Alpha 15 and get a 500 error when visiting the admin section of feeds, anyone else having this problem?

I am assuming a few things here and may be wrong so with that said, I assume #50 is a reply to #49, and acknowledges that patch feeds-652180-2.patch (#23) does not work with Alpha 15. I also assume that the patch in #50 is meant to be applied after the patch in #23. If all these assumptions are correct I have a Hunk #2 FAILED at 68 error. If my assumptions are incorrect then it is only logical that I have an error.

#50: The patch should store a uid for an assigned author instead of a name. Thus we can avoid doing a user_load() when it's expensive: when importing items. configFormValidate() might be your friend here.

Further, it assigns a user object to $node->uid which will break.

This is looking good. Need to get some time to do a good review.

- simplified
- added tests

I am going to commit this soon.

Committed. Thank you.

http://drupal.org/cvs?commit=382136

I am new with Feeds, still wandering in its quite complex settings and future promised features (compared to Feed API we are invited to move from)
Apparently, this was committed in Beta 2, and it only gives the possibility to assign a specific author to all feed items coming through a given importer. If I set several Feeds, all items get the same author or anonymous depending on the choice.

It seems that it was discussed here (#30, #44) the possibility to inherit the author from the feed item, at the item level, but I don't find any such option.

1) is the latest beta2 incorporate the discussed features?
2) If yes, does it provides the possibility to inherit the author name from the feed item (providing the name matches a Drupal user I suppose)?
3) If yes, how to do that?

Thanks

1-3 will be available with #632920: Inherit properties from parent feed node (taxonomy, author, OG, language)

I succeeded to get the feed item authored by the Feed author thanks to
http://drupal.org/node/632920

My second issue seems to be the subject of this discussion: how to assign the original article author to the feed item Drupal node?
The node processor mapping offers the "Author" information as source, but nothing is selectable on the target side to link this to the feed item node author.

Thanks

subscribing.

#60: You're looking for #699176: Mapper for user id and user name

subscribe

PS: I am using mailhandler + feeds to import emails as nodes.
The athor is set to some user which I never defined to do so ...

At the moment I am using a rule which changes the author after node is saved.

has this ever been committed? Don't see it in the current dev...

I'm interested on this too... any news?

I also faced this issue, namely that if author is left empty nodes are imported to anonymous.

This patch changes this so if author is left empty for node processor, the current user will be set to the owner. I think noone would want to import nodes as anonymous...

Hi,

is the patch in #67 for the current dev branch? If so, will it be committed?

Thanks,

Evelyn

#67: feeds-anon-652180-67.patch queued for re-testing.

#67 wasn't working for me. I found a few more lines that needed to default to the current user id. I've also added back in default_value on the form selection of author.

If I understood correctly by this thread, the #72 patch is supposed to give me the chance to set the author as the user who actually imported the CSV?
That's exactly what I'm looking for, could anyone please confirm it. Also, is it only for the dev version?

Thank you.

Actually the #72 patch is working when submitting ... but after that if the feed is set to fire (e.g.) every 30 minutes - those that are imported are not assigned to the author of the feed content

edit: sorry I just saw it is about CSV - so it is always about submitting a file - so I confirm this patch is working as it should be.

Just not to leave it as a lame answer I would recommend using hook_feeds_preserve() instead.
Here is how it could be done without patching:

/**
 * Implement hook_feeds_preserve
 */
function your_module_name_feeds_presave(FeedsSource $source, $entity, $item) {
  if ($entity->type == 'machine_name_of_the_contetn_type_to_which_the_feed_is_attached') {
    global $user;
    $entity->uid = $user->uid;
  }
}

subscribe

i was working with same and found a simple solution by changing

$this->config['author'] in FeedsNodeProcessor.inc file

goto protected function newEntity(FeedsSource $source)

and change

$node->uid = $this->config['author'];

TO

$node->uid = $user->uid;

it will automatically assign the node author to the logged in user

@seehive - you don't have to hack the module, when you could do the exact same thing in hook_feeds_preserve ... this way - when the new version of feeds appear - you don't have to apply your changes again - instead you could just update the module as recommended

@flesheater,

can you pls explain how to do what you suggest?

thanks :)

edit : just noticed #75 .. so never mind :)

I have been struggling with assigning the author of an imported node based on the feed node author. Below is the module file code in a custom module called "jlsa_feeds". This seems to have no effect. The module is enabled and my feed importer settings are as follows:

Basic Settings:
Attach to content type: "Import"

Parser:
CSV Parser

Processor:
Node Processor
Bundle: Log Entry
Author: anonymous

I create a "import" node and feed it my csv. It imports the nodes(log_entry) just fine but the author is anonymous. Any ideas on where I am going wrong? I would also like to do something similar with a list(text) field but I figured I would get author working first.

<?php

/**
 * Implement hook_feeds_presave
 */
function jlsa_feeds_feeds_presave(FeedsSource $source, $entity, $item) {
  if ($entity->type == 'import') {
    global $user;
    $entity->uid = $user->uid;
  }
}

?>

Code from #75 doesn't work for me either. Code from #77 does the trick, but I prefer to use the combination of Feeds, Feeds Tamper and Feeds Tamper PHP modules to get the user:
- go to Edit tab of your feed importer
- go to Mapping tab
- in "Source", put a dummy number that represents an empty column from your CSV file. For exemple if your CSV has 6 columns, put "7".
- in "Target", choose "User ID (uid)" from the select dropdown
- Hit Save
- go to Tamper tab
- click "Add plugin" link in the "7 -> User ID" table footer
- Choose the "Execute PHP code" option from the select dropdown
- In the PHP code textarea, add:

  global $user;
  $field = $user->uid;

  return $field;

Still, there is one bug I am struggling with. In the Basic settings of my feed importer, I checked both "Import on submission" and "Process in background" options, so when I start to import nodes from the CSV file, a first bunch of nodes is created, while the rest of it is created on cron runs. Well, the first bunch has the correct user (the current logged in user that did the import) while the rest of the nodes created on cron runs has Anonymous (user uid 0)...

Is there any more work being done on this? Would love to be able to assign author on import, otherwise rules may be an option. Thanks.

why sailing on different boat?
there are many threads for this feature
#1414080: Automatically assign the userneme that imported nodes to the node author

#632920: Inherit properties from parent feed node (taxonomy, author, OG, language)

and also very old issue at SO with some methods which claimed working at that time using hook_nodeapi and hook_feeds_presave. But none of them is working with current dev.

#10 is exactly what this issue all about and needs to be ported to 7-x.

I had this issue I was fortunate enough to have found a fix for pretty much any content type.

Just add another column in your CSV file and map it in the feeds module (whatever you upload)
I called it User Name in column 1 and linked it to User Name field and placed that first in the feed mapper (up top) and the title (unique) in column 2 just below the User Name.

The rest is easy. I have No issues now and that works on all user configurable content types and views. I am using D7 with ubercart, ubercart marketplace, ubercart auction and ubercart feeds.

If you want an easier time and less access for files that took you a long time to create select delete feed on import. If you have a column full of terms you will need to use tamper to separate them correctly via explode.

Hope that helps :-)

Hi guys,

thank you very much for your help in solving this problem. Especially to Attribution: julien.reulos whose solution worked great for me. I made a short tutorial on Youtube on how to implement this solution in combination with Node View Permissions module: https://youtu.be/xqWQSRUwDRU

Hope I could help to make the Drupal community even better :)

Changing title back, since it was most likely accidentally changed.

++1, #86, thanks a lot!!!

#72 worked
Many thanks

The module (for a few years now) has the ability to assign author directly when importing. There are user fields that can always be mapped by default.