add basic workflow-ng integration

I think having integration with other modules is a good idea.

But in this case, all the code can go into a new module in userpoints contrib.

Let us keep the API small and clean.

If you want commit access to userpoints contrib, let me know.

Khalid - did you really mean to point the version to 5.x-3.x? Aren't we putting all new dev into 3.x? Especially something that bolts on a new API should be 3.x right? Or is this 2.x version of "userpoints contrib" which is a wholly separate project. Is that why it's 2.x?

I can't speak to the quality of the workflow-ng integration code but I have this strange feeling fago knows what he is doing there ;)

fago - any chance of you turning this into a module that has a dependency on workflow_ng AND userpoints ? Then it could just get committed, right?

My two cents.

Just like views integration I'd prefer to see this in a separate module simply so that it stays out of the core module right now. This module could go over to the contributed modules project or it could stay with the core module, just like views integration. I'm really cool with either.

My main reason is that the core userpoints module is already 1,000+ lines of code with a fairly hefty rewrite. There are bugs in there I know. Although I trust fago's code its adding new functionality that wasn't there before and that has been tested by a community.

The same process happened with transaction_tools, points_expire and is now happening with views.

My second reason to keep it in a separate module is that it functions differently than the core userpoints. If you enable workflow poinits you do not set points on the userpoints settings page, you instead use the workflow page. This is most likely obvious for those that use workflow but may not be crazy obvious for everyone.

So the only real difference here is that if its a module
From the user's perspective
1) Users have to enable the userpoints <--> workflow_ng module
2) Issue/Support queue has a component called "workflow_ng integration (my big thing that I like)

To make this into a module its only create a .info file and copy/paste from the patch to a .module file.

My 1 cent to leave it with the core module. This has been requested by others for quite some time.

Greggles: "User Points Contributed Modules" doesn't have a 3.x branch yet which is why I think kbahey put it on 2.x.

greggles, yes, there is no DRUPAL-5--3 tag for userpoints_contrib yet, that is why it is 2.0 for now. The reason is that the modules in there have not been ported to the 3.x API yet, and I don't want to give the impression that they are so until someone starts porting them.

I guess jredding agrees with me. Let userpoints workflow-ng be its own module. All it needs is a .info file with the dependencies, and that is what I meant in my original comment.

I can make it part of the API, but as a separate module, just like the views/basic modules. Hence it will be: userpoints_workflowng.module.

Fago, my comment about commit access is for you to get credit for committing the code, and so you can maintain that module in the future, as you change workflow-ng.

So, to summarize:

- Most agree to make it a separate module
- It can be in the API or in contrib.

Modularized and committed as part of 3.1.

Let us see how this goes, we can always move it to contrib later if need be.