is a separate permission needed?

One problem with a separate permission is that if evaluated alone, it can result in people saving a draft that they can't then view or edit. This patch fixes that to combine the permission with a sanity check for that.

Also, I liked the original premise of this issue and #1: that replacing a checkbox that the user is already allowed to toggle with 2 buttons should not require a new permission. This patch restores that ability, while also allowing the new permission to be used to grant less privileged users the ability to use this module's feature.

This patch also fixes the checkbox access evaluation logic from #1 to be more robust. #1 had the if statement always evaluating to TRUE since it was checking $form['options']['status']['#access'] only, whereas node_form() controls access via $form['options']['#access'].

Finally, while I was in there, I cleaned up some of the form altering logic, and added some code comments. Doing so helped me understand the code flow as I was working on this. I hope these changes are ok.

You can use drupal_clone() in D6 to be safe for PHP4. But very few people probably care anymore :)

edit: I commented too soon. Just manually applied the patch, but now the only button on all node creation forms, is the 'save as draft' button. Even on nodes for content types where the current user doesn't have the edit permission. If the user can even get back to edit the node, then the "Publish" and "Preview" buttons show up again. Using the April 26th d7 release of save_draft. Thank you.

sub (to know when #5 gets committed to module) This is an issue I've been dealing with, and maybe having a save draft setting per content type would fix it too, but I have "Save Draft" buttons on content types where the user isn't allowed to edit nodes of that content type. And Drupal lumps published and unpublished together so I'm in a tricky spot with that.
Everyone's work is much appreciated, thank you!

#5 does not seem to have been committed to 7.x, despite the indication of that in #6 on May 4th.
The last 7.x-1.0-dev is from September 15, 2010 at 9:54am.

#5 was committed here: http://drupalcode.org/project/save_draft.git/commit/2f8c343

And it's in the latest 7.x-1.x code available from Git.

There hasn't been a new release of the module since that commit though (i.e., the latest release on the project page, 7.x-1.4, does not have this fix, since that release was made in April but the fix was committed in May).

Changing version - the patch in #7 is against Drupal 6.

yes, so can the -dev version under All releases here on D.o. be updated too, so that non-git users can get to it as well? (http://drupal.org/node/912106)

It looks already updated to me... The date of that tarball is May 3, 2011, and it contains the above code in it.

In general, the generation of -dev tarballs and zip files happens automatically when a patch is committed to a module. It's not something that module maintainers control directly.

#14: ah, ok, great. Sorry about my confusion.

Edit: Hm, I think I see why I was confused;
on the All releases page, the date is shown as:
"Last updated: May 4, 2011 - 00:32"

But the comments display like this:
#6 Posted by ksenzee on May 4, 2011 at 12:00am
and
#7 Posted by ksenzee on May 4, 2011 at 12:33am

So if reading hastily and not paying sufficient attention to AM/PM, then 12 seems "noon" compared to another with the same date that says 00. So I probably just thought the comments about committing it was 12 hours later than the last commit, hence my impression about it not getting committed.

Not sure why those date formats differ atm.

Patch already committed.

This was still open for Drupal 6 because the patch was never committed there. However at this point, I doubt it is likely to be... So I'm leaving this at "Fixed", but moving back to Drupal 7.