devel_generate.module is a great way to create dummy nodes on your site. It now works works with CCK to fill in all those fields with dummy data and OG adds dummy group relationships as well.

So, i'd like for generated nodes to have flags added. For global flags you just add a TRUE or FALSE for each flag that applies to the content type. For user flags, you just create a few flag instances for some random users. Ideally, you would respect role configuration.

You should do this by implementing hook_nodeapi('presave'). In that hook, look do this:


if ($node->devel_generate) {
  // Inject your data into $node
  $node->flag = [STUFF]
}

Comments

mitchell’s picture

Status: Active » Fixed

I think you would have to use the actions system unless there's another method for programmatically flagging. Flag includes support for both trigger and rules.

Marking as fixed, but I'm personally still interested in other ways.

quicksketch’s picture

Status: Fixed » Active

Thanks for cleaning up issues mitchell, but this request is not about actions at all, it's about using the devel generate module to programatically create nodes. A lot of modules support devel generate (like CCK and Organic Groups), and it'd make sense if Flag provided this support as well by implementing hook_content_generate() to randomly populate nodes with flagged statuses.

joachim’s picture

Version: 6.x-1.x-dev » 7.x-3.x-dev
Component: Code » Flag core
socketwench’s picture

If someone could point me to some example code, I could work on this.

joachim’s picture

Looking at devel_generate_content_add_node(), this only calls a helper to add field data. And devel_generate_fields() only invokes a function for the module owner of a field type.

Admittedly this is a very quick glance I've had at the code, so I could be wrong, but I don't think there's a nice way for us to support this.

joachim’s picture

Yup, I think we'd have to patch devel so that devel_generate_content_add_node() or devel_generate_node_insert() invokes a hook -- probably the latter so there's a nid. The comment and statistics code should then be moved to hook implementations probably.

moshe weitzman’s picture

See my example code in the OP. That runs during your presave hook. No devel patch needed.

joachim’s picture

I'd rather not have to pollute the main workflow with code for a developer use case. My preferred scenario would be a hook we can stick in a flag.devel.inc or something.

Or indeed, barring that, we could stick it in flag_devel module itself?

moshe weitzman’s picture

i personally think a flag_devel module is poor dx for the users but whatever flag maintainers want to do is fine. devel isn't planning on duplicating presave hook.

joachim’s picture

> i personally think a flag_devel module is poor dx for the users

I'm inclined to agree.

But most sites won't be running Devel generate -- surely this is meant for development copies only. So how is it good DX to have code just for that in the main flow?

moshe weitzman’s picture

Sorry, I meant UX there. So, I favor UX over DX here. It is arguably not even a regression in DX because hiding functonality in many small helper files has its own annoyance. Anyway, feel free to put everything but the hook declaration in an include file. And now I've said all I want to say on this issue. Thanks for Flag!

joachim’s picture

It's my opinion that my suggestion gives us the best of UX and DX.

Flag module is a complicated beast with a lot of code flows going on, and I don't want to add complication to them for a developer-only feature.

This is a wontfix unless devel module provides a hook, or it goes in a submodule.