Introduce BulkSpaceEvent

(Bug, Investigate , Priority: High, Test Status: No automated tests yet , Reported By Justin du Coeur, )
Summary: At the moment, we're doing things like SecuritySpacePlugin as multiple Events. Conceptually, that's wrong -- they should really be one aggregated Event.
This is not easy to do right, since later Events potentially depend on the result of earlier ones. (Eg, Create-then-Edit.) But in principle, so long as we've handled all the side-effects like fetching OIDs before we actually persist anything, it does make sense.
This BulkSpaceEvent should contain some sort of indicator of what this Event is accomplishing. This should probably be a hookable enumerator, which gets translated to a user-visible (and localized) message for showing in the History.
Here are my old notes on the subject:
  • Lift the guts of normalReceiveCommand out to a PartialFunction that, again, takes the current State and returns an RM[(List[SpaceEvent], State)]. The actual persisting happens outside of this.
  • Now introduce a new BulkSpaceCommand case class, which encapsulates a List of commands. We probably want a SpaceCommand marker trait for this stuff (if we don’t have it already), and BulkSpaceCommand should also have an enumeration (and possibly a Note field) saying what’s going on here. We will also need to introduce a corresponding Event and UI Summary.
  • The BulkSpaceCommand gets processed like the other SpaceCommands, but it folds over all of its contents, resulting in the final RM[(List[SpaceEvent], Space)].
  • Then rewrite SecuritySpacePlugin to work this way.
  • Rewrite anything that’s using SpaceBuilder -- at this point, we’re thinking of these sorts of problems differently.