Taxonomy inheritance

Hey inari - This is not possible ATM. Planned for future releases? Not decided yet.

Not sure if this going to be close enough @alex_b so let me know if you want me to start another issue.

But this may help solve the issue for @inari too...

I would like to be have a link from each item created to edit said item (at least the location). As @inari pointed out the text extraction is not always correct. I am using Yahoo Placemaker BTW. It would be nice to be able to edit the item in question and fix the location in a form - Say something like a typedown field. Right now I am going to the admin/taxonomy screen and doing it by hand. Most of the time just deleting the bunk location. e.g. Venice, LA shows up as Venice, Italy or Venice, Los Angeles. If I had a simple form to change it to the correct Venice I would be happy. This may be a bit more manual than the way the original feature request is stated but I think it would be a good usability add.

R,
C

@inari you may be interested in this issue #632920: Inherit properties from parent feed node (taxonomy, author, OG, language) but there is another challenge with inheritance via Feeds and MN out of the box. MN is using DATA API which creates a table to stuff feed items into - In other words Feed Items are not always nodes. I am sure it's still doable but the architecture is a bit different as far as I can tell.

1) Allow your geotaxonomy to be attached to a Feed node

2) Add a checkbox that says something like "Feed Items Inherit this term"

3) On Feed Item creation automatically copy geotaxonomy Term ID from Feed node property to Feed Item table field

Overall there is *extensive* use of Views to pass this stuff around MN and it can be a bit mind boggling to track down a small change and its attendant consequences

A big +1 for this functionality. I'd just applied a patch from http://drupal.org/node/632920, which cglusky cites above, when it dawned on me that MN isn't using nodes to store imported news items.

I'm looking at the changes that patch makes to the Feeds module's FeedsNodeProcessor.inc right now, and looking for similarities in the FeedsDataProcessor.inc, but I suspect that the very different table structure would require a very different-looking solution...

Update: Cross-linking to http://drupal.org/node/858672 in the Feeds issue queue.

@TKS. Yes, if your Feeds Importer is not using a node to store Feed Items things will change. The Feed will still be a node so if it has taxonomy terms attached that should be stored in $node->taxonomy (?) so those values need to be saved for each Feed Item that belongs to the parent Feed. I don't think there needs to be any code changes to get that far...

I am typing this without looking at an install so it's all a bit general...

- Add setting (checkbox) to Processor "Feed Items inherit Feed taxonomy"
- Gets a bit more interesting if you want to restrict it to certain vocab(s)
- If the above checkbox is enabled then add taxonomy id's as a field table->addField('newfield', $spec);
- Hmm. Need to relate that new field to term (taxonomy) table. Probably using Schema hooks. Otherwise can't do much with the data.
- As each Feed Item is saved then add node->taxonomy info from parent Feed to data array and save - table->handler()->save($data);

This might be better served as a feature request for Feeds and move to that queue.

My short term recommendation might be to just use a Feeds Importer that uses a node based Processor (vice Data/Schema) as it could save on some of the initial complexity. Using Data with Feeds is nice I guess, but not sure how many nodes you need to have before you see a big difference in performance. Heck, you might be able to do it with triggers/actions/rules if Feed Items are nodes.

Hmm...teach me to start rambling before I go review all the movement on the related issues. I am going to take back everything I said in #8 except my part on recommendation to use node based Processor. From the looks of everything people are trying to inherit it would not make much sense to do it outside of the node to node context. IMO you start to loose the efficiency of using Data with Feeds if you build a huge number of fields to track inheritance info. My vote would be to allow inheritance with Node processors and keep it simple with Data and not support inheritance.

cglusky -- Thanks for the suggestions, both here and over in the Feeds queue. But does Managing News event allow the switch from Data to nodes for imported items? I haven't gone digging or experimenting on that front -- I just assumed that would create all sorts of downstream problems in MN.

@TKS Good Question. Not sure but you are probably right. As you have seen by now MN is very Views driven so might have some issues unless you also modified the related views. This is one of the reasons I am building my own instance. MN is awesome if it does what you need out of the box, but it's quicker/easier for me to build my own instance with what I need than it is to modify MN. Also does not help that there seems to be a bit of churn with modules trying to fulfill their pledge to release a D7 version when some of them do not have stable D6 code. But that's a vent for another day/queue as it does not apply here.

Indeed, #858672: Taxonomy Inheritance for the Data Processor is the feature request to tackle.

I think once #864362: Unify Channel tags with Location vocabulary is released, we should go about this feature.

This feature has been implemented in 1.1.