split permissions into 2

I could see how these permissions might be helpful. I wonder if we could have a more generic solution here. We've gotten a couple requests for creating more granular control over these kinds of events and I don't want the answer to always be "add another permission."

I think the creation of a new revision with each edit is baked pretty deep into Workbench Moderation. I don't personally have a strong opinion on the issue. If you want that re-architected please open a separate issue so that it can be tracked independent of this permissions question.

This might be better handled by the idea of a end-to-end "workflow" that integrates ctools access plugins. There are many, many useful permutations of permissions, and we need a more robust way of controlling access than pushing more concatenated strings through the core permissions system. So yes, I absolutely aggree with this use case, but we need to address it with a more structural change.

Agreed. Right now the issue I see is that I can't have an individual author send a new revision to Needs Review status without that author getting access to send any node to a Needs Review state. There should be finer grain control over these permissions but pushing them directly into the permissions system seems like it could get very complex and overwhelming very fast. Individual authors should have ability to push their content into states and edit/create new drafts of their own content but not other users.

Permissions are expected to be refactored with the new architecture. Tagging and relating to a higher level architecture issue: #1316314: Workflow Architecture for Workbench Moderation

This should be covered under the CTools Access plugin approach.

#1415938: Test common access configurations

This is my patch for 1.2 for anyone who needs the "own" permission by content type now.