role management and unpublished pages

Hi, this is my next issue concerning workflows (my first was "ReplacePage" http://www.modxcms.com/ReplacePage-702.html)
What I want to achieve is a user role which can create documents, but cannot publish them and which does not permit to edit/unpublish/delete published pages.
Sadly, there is no "can publish pages" checkbox in the role-config and also no "can edit published docs" box.
Will there be something like this in the next releases? Or must I try it for my own? Creating the checkboxes and the required db-fields would not be that difficult - but making it work would be tough.

By examining the role/permission stuff I found another strange behaviour:
If I unpublish a page it does not appear in the menu anymore and is also not searched. But by typing in the URL directly the page is shown. So I assume that unpublished pages will also be found by external search-engines and spiders.
Do I have to delete a page (and even clear the trash and cache) to get rid of it?
I do not think this does make much sense. If I unpublish a doc I do not only want to remove it from the internal working of the site - I want to make it dissapear completely!

if you’re logged into the manager you can view unpublished pages. That’s helpful for viewing them while working on them without getting redirected to the not found page. Try logging out.

If you can get this working, you can certainly expect to see in a release coming soon to a location near you. I think you could get by with just a simple wrap on a new permission to show or not show the checkbox row on the save_content page as well as setting the default publishing status to be unpublished. And add a new role of course to the DB.

Ahh! Stupid me! Of course I should have logged out before testing the availability of unpublished pages!

For the rest: hiding the checkbox of save-content? No idea yet on how to do that. From a usability point of view it would be better not to show the "edit" button/box at all. Preventing a user from saving changes he was allowed to make? Not good.

One more reason to dive even deeper in all that stuff: Maybe creating "dynamic" document-groups based on their state (published, unpublished, deleted) which can then be handled like normal groups would be a better approach than to "hack" the manager-interface?
What do you think about that Ryan?

Thanks for your help!

EDIT: I think some more additonal document-states, like "in progress", "submitted", "rejected" would enhance modx’ abilities to support common workflows. I just installed SPIP which comes with a full-fledged and very reasonable version of this kind of stuff. Maybe MODx does not have it because there is a potential incompatbility of these aspects with the cool front-end editing features?