If the user has access to one content type only, jump to that page

works as advertised. good idea. why it took so many years to do this i do not know.

I don't think it is a good idea to add code for such fringe use cases.

usability is all about paying attention to these cases even at the expense of some extra code. where to draw this line is often a matter of taste, so i won't debate it much. fwiw, i think this is a reasonable use of code. the fewer people that see node/add, the better.

Firstly, I don't think this actually improves usability as such. If anything, it decreases it: if a site only allow its users to create book pages, a newbie clicking on "create content" wil be taken to a page that says "Submit book page". But he has no idea what a "book page" is as he never got a chance to read the enlightening spiel on the "node/add" page:
A book is a collaborative writing effort: users can collaborate writing the pages of the book, positioning the pages in the right order, and reviewing or modifying pages previously written. So when you have some information to share or when you read a page of the book and you didn't like it, or if you think a certain page could have been written better, you can do something about it.

Secondly, how often does a site have just one node-type?

My 10p,
-K

We already have an admin defined help message at the top of node/add/x which can be used to describe book page and how to make one. This is superior to the description on node/add since thats just some drupal engineer's vision of the module and not specific to the site where it is deployed.

I think the use case where users have only 1 content type to post is very common. I have sites where users only post stories or blogs and all interesting stuff happens with taxonomy associations.

Resetting statuses

This still applies, and is a fine, fine idea. Tried it out, works great, no test regressions.

Forgot to set RTBC.

We already have an admin defined help message at the top of node/add/x which can be used to describe book page and how to make one. This is superior to the description on node/add since thats just some drupal engineer's vision of the module and not specific to the site where it is deployed.

Fair enough but it introduces a number of extra configuration steps. Isn't that something you're concerned about?

If there's only one kind of content on a site, then I don't think a description of it makes a lot of difference to be honest - you're either going to post it or not, you don't have to make a decision about which one to choose (which is pretty much what those descriptions are for). So in the rare case that those descriptions are very important to sites with individual content types, there's a fair chance they'll have extra help on the node/add/$type page anyway.

OK, I buy into this. However, I'd like to see us add a tiny bit of code comments to the patch. Should be an easy re-roll.

Re-rolled with a code comment.

Last patch still applies, tested and good to go for me.

Committed to CVS HEAD. Thanks.