Currently every feed item created uses inherits the workflow defined in the feed item content types settings. Published status, comments etc.

Sometimes you want the same feed item content-type to be used, but for items coming in from some feeds they should not be automatically published.

Could per feed settings be implemented to define the workflow defaults for items produced by that feed only?

Would this work as a contrib module to avoid cluttering up the existing default (already confusing) UI of FeedAPI?

Comments

ekes’s picture

I was figuring it would be something to add to feedapi_inherit? Along with the checkbox for inherit taxonomy, a replica of the workflow from the node.

What do folks think?

ekes’s picture

Assigned: Unassigned » ekes
Status: Active » Needs work
StatusFileSize
new2.11 KB

OK, I've just (like really just) written this to try it. I've made it it's own module - the taxonomy inherit wasn't right, for a couple of reasons.

Notes:

  • A bit of mission creep, this should let you do per-feed settings on publishing, comment and filtering
  • There is an additional privilege created if you want people without 'administer node/comment' or the filter privs to use them in this individual case.
  • Only the creating feed will make the settings on the node. Any other feed pulling the same item to the update the node won't make changes. I see this as a feature - nodes in the system don't suddenly change their settings!
  • Making it possible to set defaults for these fields has not been done.
  • It might be nice to develop this to cover CCK text fields - this would have to be a tab after publishing the feed, like the mapper, as there is no way of knowing what they will be until it's published!

Oh! and I've just rolled a tarball for this test - it's for the D5 feedapi, with feedapi_node obviously. Do test if you have time. I'll be back to it soon too (need it by the end of the week ;)

ekes’s picture

Status: Needs work » Needs review
StatusFileSize
new2.1 KB

Tested, should all be working for standard FeedAPI functionality - defaults now working (with #253428: _feedapi_populate fails with fapi elements using #parents)

CCK (ie FeepAPI_mapper related) still to do.

alexkessler’s picture

Thx ekes!
That's another awesome FeedAPI feature!

I posted a feature request for FeedAPI mapper a couple of weeks ago http://drupal.org/node/247819,
that sounds similar.

If i understand you correctly: This module be able to set default cck values per feed item in the near future?

tylor’s picture

Thanks for this ekes!

Everything is working great for me but I had a piece of feedback. I received a very unclear error and tracked it back to the 'body formatting' tab. Even if this option is not enabled I found that filter_form_validate() failed because no input format is selected by default.

Maybe something like:

$add['body']['format']['#default_value'] = 1;

or better validation to see if these options are even enabled.

ekes’s picture

I think I'm right in surmising this is just the case with: FeedAPI content types created before the workflow module was installed, it then also effects their nodes when edited.

If so - I think justing the sane default (which is what happens when you create a new content type and then new feeds) is probably better than offering a different validation.

I'll do, and test, it in next day if I'm right and it's just older ones. Let me know if you notice others.

Cheers,

buzink’s picture

StatusFileSize
new6.76 KB

Well, Tylors suggestion works perfectly as far as i can see. Just add

$add['body']['format']['#default_value'] = 1; under line 130 in feedapi_workflow.module. Attached is the patched file.

summit’s picture

Version: 5.x-1.x-dev » 6.x-1.x-dev
Component: Code » Code (general)
Status: Needs review » Needs work

Hi,

Setting this issue to D6 if thats ok.
Could this patch may be also be considered to be committed for D5 and updated for D6?
Thanks for considering!

Greetings,
Martijn

aaron stanush’s picture

+1. Enabling the children feed items to inherit Publishing Options (especially "Published") makes a lot of sense, instead of just author and taxonomy terms.