Prevent DELETE carnage

[gregmalcolm]

3 rules will be initially be implemented to prevent Bad Things occurring.

1. User param requirement for applications

Deletes sent from trusted applications (like EDDiscovery) will need to include a root level user param with the DELETE telling us who the commander is. If that commander doesn't match the one owned by the record the deletion will be rejected. Particularly needed so Site Survey records owned by commander A doesn't get deleted by commander B.

Rejected Deletes of this kind will fail with a 403 ("Forbidden change.") response

2. No deletion of parent records

If a World is linked to a World Survey or Basecamp then deletion will not be allowed until the children are removed. This will obstruct big cleanups, but at least a user can quickly correct a mistake if they created a record in error.

Rejected Deletes of this kind will also fail with a 403 and a slightly different text response ("Forbidden because of dependencies."

3. No deletion of records created by another user

Materializer will start keeping track of how has updated a shared record. Delete requests will only be honoured on records by the original creator. So if commander A creates a world Commander A can destroy it but commander B cannot. Again, this allows the swift correction of mistakes but does not allow someone to systemically to demolish all known records.

Rejected Deletes of this kind will fail with a 403 ("Forbidden, not the creator.") response

[gregmalcolm]

1 is done. You can no longer delete another commanders site survey.

[gregmalcolm]

2 is done

[gregmalcolm]

... and 3 is done too. We are now safe from having everything wiped out by a single crazy person. :)