Assign author of imported nodes

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.

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

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.

Hi,

got a patch that covers the three cases - default to anonymous, can set user explicitly or inherit from Feed node (if Feed attached to Node).

UI wise it is all in settings section of NodeProcessor. Ideally the inherit author setting should be grayed out if the Feed is not set as "attachable" to a node - any suggestions on how to achieve that simply would be great.

Didn't test extensively - but hope this helps to move things forward.

Also, user choice happens outside the loop to avoid having to repeatedly load the Feed node to get the user id.

Attached is the Patch, the entire FeedsNodeProcessor (just replace your existing one..) and an image with the UI.

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!

excellent - thanks all. should be able to have a look at this next week I absolutely agree with 3 from alex_b, just need to have to figure out a good way to do it.

Subscribing

I need this feature too!

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

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.

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!

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.

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.

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.

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?

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

#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 ;-)

#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.

Hi alex_b was trying to figure out where I should be looking so that we can make a decision about whether to grey out the checkbox or not (point 3 of #13).

I thought it would be a case of having to check the value of $this->config['content_type'] that is available in configForm. However, no matter what the setting of Attached To in the actual form that variable is always feed_item. Which means that I am probably looking in the wrong place so any pointers would be greatly appreciated and I will try to take care of the remaining bits to wrap this issue up.

#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 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?

subscribe

subscribe

Hi, updated patch for this. It will now work against current head.

Given that inherit author from feed node issue gets solved somewhere else the option to assign a user explicitly only shows up when you choose Standalone form as an option.

Still doesn't handle assigning a user by uid which I need to fix but at least the issue is re-activated and people can go ahead and look at this once more. Will do more testing + refinements over the next couple of days.

---

one note: in order to check whether this is a standalone or whether it is attached to a content type I use

maybe we could assign a specific value to this (e.g. 'none')?

#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.

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

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

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