Usability issues with cloning books with different input formats

Thoughts on the above;

1. Since we are relying on node clone to do the heavy lifting of actually copying the nodes we should be careful about making any assumptions unless node clone makes those same assumptions. This choice is the "safe" choice.
2. This could potentially result in even more strange behavior for the end user as this could result in sections of content being filtered out, or becoming malicious if the input filter becomes less restrictive as a result. Although that last instance is not likely to occur in the real world. This approach just seems like it will end up creating too many situations where the behavior is dependent on the content being cloned, and as such will be quite confusing and difficult to debug.
3. I think a variation of this is appropriate. Document the issue as in 3, but allow via config the admin to override the behavior such that behavior as in 1 or 3 is configurable. We shouldn't cripple a site admin from creating scenarios where only one input format is used and this is essentially a non-issue.

The only gotcha I see with the configurable 1 or 3 approach is that the real behavior for 1 would have to be if any node that would be cloned when clicking "derive a copy" is in an unavailable input format then "derive a copy" should not be available. That is, a user can only copy a book if and only if all nodes in that book are in an input format that is accessible to the cloning user.

Thoughts?

It's going to be confusing for end users, even if it's well documented, if "derive a copy" (or whatever better UI may exist) is there sometimes and missing sometimes.

A variation of #1 is the safest choice, but instead of hiding the "derive a copy" link we should either:

1. Show the link and when the user clicks on it give them an explanation as to why the can't "derive a copy" -- contact your system administrator, etc
2. Show a link with different text that takes them to the same explanation page

We can provide a utility that administrators can use to figure out which nodes in a book are problematic for the "copy deriver."

At first glance, this appears like it might be a big problem on a site with a lot of books, but it probably just points out that input filters haven't been properly configured.

If there are clear use cases for why we need to support cloning of complete books where the cloner doesn't have rights to input filters in the source book then we should re-think this.

Partial fix is in place, quite a bit of refactoring to facilitate this and make maintenance easier.

Now we control the node copy process via a call to book_copy_can_copy() so we have full control over the behavior. At the moment users are denied access to copy a book if they cannot access the necessary input format(s) and create the necessary content type(s) of any node in the book.

Remaining issue is to present a more helpful screen to the user with an optionally supplied text from the site admin in the event they cannot copy a book.

This info page may make sense to address along with #600540.