None/Live state names should be configurable

First of, this was on the roadmap (thats why those to methods were present) and iam very thankful that you implemented and contributed this back. Its quiet a huge patch though, not easy to read that way.

Would you mind :
-- comment your changes in the code
-- branch(fork) in github so we can better work together (http://github.com/EugenMayer/content_moderation)

I expect quiet some testing with this changes, as the string(s) where used in logical statements and conditions etc... how far did you get there?

Well its not strongly needed to do some simletest, but it would be awesome. Drupal has a simpletest implemetation and framework and a module for it for easy implementation.

I rather ment to test the module deeply, because this module will be critical for a lot of cases. We need to test all the implementations ( all the switches ).

What would be really awesome is github, because this will make the process of working together much easier.

Actually you seem to have a deep insight of the module already and seem to have clients needing it, so maybe you are interested in co-maintaining it? I would really be glad to have a help of your kind here to get this module were the community wants to go to. So let me know, i would really be excited.

Thought I'd toss this in since dparks and I are on the same team and I found a limit to the patch he submitted (for our use case anyway).

We are using a workflow similar to the following:

none -> review -> published -> unpublished (and 'review' can send back to 'none' as well). The 'unpublished' was hardcoded to reset back to 'none' which is not exactly what we wanted. So the mini-patch I'm attaching addresses that. (Along with his patch, this one adds the ability to set that state to follow the 'publish' state via the admin form.)

Great module btw! We're getting some great use out of it, and might be looking at continuing to help beef it up. :)

Thanks,
-dellintosh

I will not included this patch in 1.5 as it could cause to much damage with bugs. Nevertheless iam very interested in getting this generalization into the core module.

Thanks for your effort!

Thank you!

Looks good to me, iam really going to take this one in for 1.6.

i fixed the current issue with 1.5 and iam not going to take this one into 1.6 just for the maintainace release.

Can you reroll this patch for on 1.6, i will include this patch in 1.7 so we finally get this into the module. Thank you very much for your effort!

I've just implimented something very similar to this against HEAD. Will get it checked in tomorrow for review.

Gold, see my reply in the other issue. This can actually cause a lot of new bugs. We really need to check this. If we take that one in, we should maybe make a 2.0-beta1 out of it. what do you think?

Sounds good. I've just pushed this to my github repo. Grab that and test to hell and back.

I did notice that there were quite a few knock-on issues around this and an hour "estimate" turned into a days work. Client needed it though so it got funded. It's also going to be used in a live environment and is currently deployed to the test environments so we should spot and squash any issues with this fairly quick.

Thanks go to NIWA for this. Actually, NIWA are the client funding most of this. If we could get them mentioned on the project page that would be great.

Checking out the other replies now.

@"mention clients". Yet my clients also did not get mentioned on the project page, eventhough they founded the whole work of creating the module. Iam not sure how we should handle this currently, maybe we should have a small chat. Iam always open to ways of "credit your funder" to actually get more of those in the drupal ecosystem.