This patch is the first of what I hope to be a series of actions (as in the actions.module) using CCK fields.

This patch adds two actions:
- Assigning node ownership from a user reference field
- Send an email to 1 or more users in a user reference field

These actions have been extensively tested using single and multi-select user reference fields, both required and optional. To test yourself, you will need to create a CCK type with a user reference field. Enable the actions and workflow modules. Create an action in /admin/actions, selecting either "Change node author based on user reference field..." or "Send email to user reference field". Fill out the rest of the action form and submit.

Create a workflow with at least 1 state. Create a transition between states and add your action to that transition. Create the a node under your test work flow, and select a user in the user reference field. When you transition, the authorship should change, or the user should receive an email, depending on the action you selected.

A viable use case for this patch is to create a review system. Each review would be a CCK type with a "review by" user reference field. With two roles, reviewers and editors, editors could have "create reviews" privileges, while reviewers could have "edit own reviews". Editors could create a review and select a user in the "review by" field. When the workflow ran, and this action is invoked, the node would be assigned (by a change of ownership) to the reviewer. He or she could now edit it. Additionally, an email could be sent this user using the other action.

Hope you like it!
-Mark

CommentFileSizeAuthor
userreference_actions_0.patch8.3 KBmfredrickson

Comments

karens’s picture

karens commented

Mark, this is looking very interesting. One quick question though. Would it make sense to make a separate content_actions module that would be enabled only if actions is enabled. Then have that module include actions for any or all fields that you are defining actions for. I'm just thinking we're adding a lot of code for something that may or may not even be installed. Plus, if it shows up as a separate module, it's more clear that all this functionality is available, which might give it more visibility with end users.

Maybe you've already thought about that idea and discarded it for some reason, so let me know your thoughts.

Also, what is your suggestion as the best way to test/review this??

karens’s picture

karens commented

Oops, skip the last question, you already provided instructions on how to test it :-)

mfredrickson’s picture

mfredrickson commented

I do not have a strong opinion on how actions should be structured within CCK. I was originally going to write a "field actions" module, but then realized the appropriate place for these actions was with CCK.

I like your point about raising visibility, and I do like keeping the code as small as possible, but it seems to me the easiest thing to do is just keep any actions in the appropriate modules. Then it is clear what field type each action works on.

But, I'm really not picky on the matter. I'd just like to see the functionality included in CCK, either in a content_actions.module or in the userreference.module.

If it makes a difference, I am planning on writing some actions for nodereference.module (e.g. "Perform on an action on referenced node(s)..."), but I don't know when I'll have the time.

mfredrickson’s picture

mfredrickson commented

And another thought on this: if there is a content_actions module, it may have actions for field modules users do not enable. If the user doesn't enable the userreference module, it doesn't make sense to have actions that act on user reference fields.

karens’s picture

karens commented

I was assuming you'd put each module's actions in a separate .inc file and conditionally include it in the content_actions module if the field module exists. Most people seem to be enabling all the core fields (or at least that is my impression) so I don't think there are that many times when you wouldn't need all the available actions for the core modules, but using 'if_exists()' will take care of that either way.

The more I think about this the more sure I am we don't want this code actually in the userreference module code itself, especially since the actions module is not a core module. Anyway, I still like the idea of a separate module so people can easily see that there is another 'package' of functionality they can use. If it had its own project page you could link it to CCK, Actions, and Workflow so anyone looking for any of those programs on the downloads page could see it is available, which again would increase visibility. And we can link to it in the CCK Handbook and project page, etc. etc.

Plus it's conceivably possible (but maybe not likely) that someone would want to have the actions module enabled to work with something else but not want to enable it for CCK, and having it a separate module keeps things nice and modular -- you can use it or not.

BTW, I do like this feature. This could be very handy!

Anyone else want to weigh in on how to incorporate this functionality??

mfredrickson’s picture

mfredrickson commented

Karen,

To clarify: do you purpose that I start a separate project? Or are you purposing that another module file is added to the CCK package.

I would prefer to put the content_actions.module in CCK, but if this would clutter it up, I'll go start a separate project.

karens’s picture

karens commented

Sorry for the confusion. I'm not completely sure, and I don't know which JonBob would prefer so I'm trying to be cautious about adding things to core. Why don't you write it up as a module that can be optionally enabled or disabled, but don't create a separate project and I'll try to get some clarification about whether or not it belongs in the core CCK package. If it doesn't get included in CCK core, it could maybe get bundled with Actions. It seems to me that either packaging option could make sense.

moshe weitzman’s picture

moshe weitzman commented

great stuff. makes sense to me as separate module that is or isn't in core cck. who cares :)

@mark (two mostly unrelated questions):
- is there any reason why workflow is mandatory for this? couldn't an action fire just based on saving a node? can you not attach an action to the save itself?
- in general the actions emails a bit limiting. how could we get data fro mthe node into the email itself. for example, imagine the node in question has an integer field called 'qty' and we want that integer displayed in the email body.

i'll add this to the list of cool shit to review.

RobRoy’s picture

RobRoy commented

I have a patch somewhere to extend the default email action to allow passable a variable/value array for both the recipient and subject/body. Still needs some work so I haven't posted it anywhere, but would probably be the way to go here for dynamically passing cck field names/values. BTW, it doesn't use workflow as you can just call actions_do().

You could call it like this for example:

$variables = array(
'recipient' => array('%donor' => $donor_email),
'message' => array('%donor_name' => $donor_name, '%donation_amount' => $donation_amount),
);
actions_do('action_send_email', $node, $variables);
?>
RobRoy’s picture

RobRoy commented

Ehh, my little sample code above is pretty worthless as it's pretty specific code, but hopefully you get the idea. Basically, we should extend the generic email action to accept a variables array as the 4th param.

mfredrickson’s picture

mfredrickson commented

Ok. I think the consensus, small as it might be, is to launch a separate contrib module.

@moshe:

1. RobRoy is correct. Workflow is not specifically required, but actions doesn't provide a UI for usefully invoking actions. at least until this gets in: Run actions on specific node from a tab.
2. That's a whole other kettle of fish: some sort of tokenizer language. Perhaps we could do some sort of php/%token combo? Something like


if (%field_blah) {
print "Hurray for %field_blah";
}

foreach(%field_baz as $baz) {
print $baz;
}

I'd like something similar for feeding data from a node into viewfield arguments/exposed filters, but haven't had the time to play with it. We could certainly enumerate all possible fields when creating an action, but it would be impossible to know if a given node contained that field (except for %title, %created_at, etc).

@robroy:

i certainly think the emailing functionality of actions could be factored out. this is at least the third action I've written that emails people in another way. (Check out og_actions for another example, and there's a snippet somewhere for emailing an entire role group.)

But let's take that conversation to the actions module.

@all:

I'll update this issue when I release Field Actions.

liquidcms’s picture

liquidcms commented

this sounds pretty cool.. but just to be sure i get this.. here's my current application

- I need to build a relational database.. simple enough if I was wirting php code from scratch; but how do I do it in Drupal..

my example.

- I have 2 node types: matches and games
- a match has a set of games associated with it

pretty simple… in sql world.. a table for games, a table for matches and a relation table to link them

so in Drupal I figure something like this:

- each match gets a term
- a game gets assigned a term

BUT… I don’t want user adding a game or a match to know anything (and certainly not do anything) related to creating or adding terms.

So… and I knew you were wondering when I would get to the point

what if I could:

- add an action to my match CCK type that creates a tax term based on info I know (uid, nid, title, etc)
- add an action to my game type that would assign a tax term based on uid and referring page (i.e. in a workflow I would go from create match to create game (which now actually becomes “add a game to a match”)

in other words

- user Joe (uid=3) creates a new match (nid =17) and I auto create a term “match_3_17”
- when I come from nid=17 to add a game; when I save game I auto get tagged with same term based on referring page (and looking (i.e. nid I came from) and current uid (which is still Joe’s).

I can now, of course get a view based on matches for given user and also list the games that go with it.

Have I missed something here? Does this sound like an application of what is suggested here? Not sure without extending CCK by adding action there is a way to accomplish this (outside of custom module).

Also

- why require workflow (I agree with moshe)
- would think separate CCK .inc file that give some predefined actions but that user would use to store their own custom actions
- but, like workflow would pick up any other actions included in enabled modules.

- and of course this could be done in custom action code .. but (and maybe what KarenS is getting at) but could actions be enabled depending on field selection - i.e. assigned to a field??? not sure what i mean and doesnt apply to my example; but if radio A is selected then action A gets triggered upon save .. etc.

this is way too cool…

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

mfredrickson’s picture

mfredrickson commented

@ptalindstrom:

I would skip the use of terms and look at using node references (another CCK field) instead. This is the foreign key you're looking for. You can combine views and node references to limit what users see. Play around, I think you'll find what you want.

On the issue of requiring workflow: Actions (and the actions.module) do not require workflow. However, to my knowledge, no other modules invoke actions (including the actions.module!) so to test this module, you pretty much have to use the workflow module. I already posted a link to a quick and dirty way for the actions.module to provide a UI - but the patch has not yet been accepted.

Re: a .inc file: As discussed, I'm going to release a content actions module to hold actions related to CCK types. I just haven't found the time to refactor the code appropriately. FWIW- I would still rather see these actions in CCK, but I've been overruled. :-)

liquidcms’s picture

liquidcms commented

thanks... shortly after my post i found idea of node reference and nodefamily.. havent all got it working.. but i think this may be it..

although still not sure that an action associated with submitting the form is not still requierd. and certainly something like fire an email when saved would be handy as well.. but i think that is the action you are suggesting here to add to userrefence field (which makes sense it would go there).

will be looking at this all this weekend.. should have better view of this all then...

thanks again.

mfredrickson’s picture

mfredrickson commented
Status: Needs review » Closed (works as designed)

I've released a module (Field Actions) to handle this functionality.

@KarenS: I'm happy to give any CCK maintainers access to field actions.

Thanks for all the thoughts. I'll try to incorporate them as I work with field actions.