*crossposted from conversation in Open Atrium Issue Tracker - Moving content between groups not possible

"Reassignment" method vs "Recreate and Delete" method.

Previous efforts I've seen to move content between groups in OA have used a reassign method to change the group assignment (grayside, rocks!). This leaves a bit of cleanup as grayside note's on the Atrium Group Tools page. I'm proposing we use a "Recreate and Delete" method as opposed to a "Reassignment" method any time we move content into a Space that isn't Public. The argument goes as follows: Any time you are moving content into an area with higher security then recreating the content in the destination space (thus leaving behind sensitive information) is safer than reassigning the content to a new space and trying to censor the sensitive parts.

Use cases for private->private movement

Copy

User on Node 42's page in Node 42's origin Group Space. User clicks on 'Copy to Group' tab. User picks a destination Group (from a list of Groups that user belongs to) to copy node 42 to. Node add screen is presented in destination Group's Space with node 42's values prepopulated on the form. User reviews fields, adds notification subscriptions in the destination group as needed. User clicks save and then sees they have a new node in the destination Group Space.

Move

User on Node 42's page in Node 42's origin Group Space. User clicks on 'Move to Group' tab. User picks a destination Group (from a list of Groups that user belongs to) to move node 42 to. Node add screen presented in destination Group's Space with node 42's values prepopulated on the form. User reviews fields, adds notification subscriptions in the destination group as needed. User clicks save to create new node. A background process then deletes node 42. User then sees their new node in the destination Group Space.

On Node revisions (history) and why Private groups can't share it

The "Recreate and Delete" method does not copy/move revisions. Sharing history between groups will expose the origin group members that the destination group members may not have access to knowing about. A strong warning will have to be issued when moving nodes because that will delete all history on the node being moved into a destination group. Something like "Moving this node to destination group deletes this node and all of it's history in origin group. History will not be moved to destination group. Would you like to archive this node in origin group for safe keeping?"

"Reassignment" as opposed to "Recreate and Delete" is probably preferred for public->public movement

If you are performing a public->public movement of a node, then there may be no use in not just reassigning the node's group assignment thus transfering with it all of the node's revisions.

"Recreate and Delete" method may be the right method for public->private movement

After a public->private movement using the "Reassignement" method, a public user could receive a notification triggered by a private group member (Not totally sure about this). So when the public->private movement happens using the "Reassign" method, we would have some cleanup to do. I think this kind of cleanup could be messy, tough to maintain, and thus may end up in some security holes. "Recreate and Delete" may be the sensible option for public->private movement.

Managing "Recreate and Delete" method with Book structures

If the user doesn't want to copy/move children book pages with the parent book page, then it's as simple as the use cases above. If the user does want to copy the children book pages and structure, then a multi-step form to submit each child page could work. If the book has a very large number of children though, this would be really tedious. In the case of a large number of children book pages, submitting the parent and having settings like notification subscriptions inherited to the children would be handy (probably the trickiest piece of code I've proposed here). I'm not ready to tackle this yet and I'm hoping to get some other peoples' feedback first.