This concept is not yet dead. It may be implemented sometime in the future. But it was decided that it is just too complex for now and does not bring enough value
Staging is creating a preview of user object (and other objects) for the purpose of presenting them to the administrator. The GUI component calls IDM Model to create a stage, short XML document that contains the object to modify. The stage also contains interactions state, original values, etc. The stage is under the control of IDM model. The GUI should call IDM model to make any substantial changes in the stage (e.g. adding new role or account to the user). Such a change may be constrained by a policy or imply values of virtual properties. Therefore asking IDM model to do it will help maintain consistency and automatically recompute the values as well. Minor changes (e.g. changing a values of a single standard property) can be done by the GUI itself. The rule of the thumb is: If there is a method to manipulate the stage provided by the model, such method should be called. If there is no such method, GUI can manipulate the stage by itself.
Submitting a stage will trigger changes in the system. E.g. submitting a stage that has one extra account assigned to the user will trigger "modifyUser" operation with the description of the account. This can be intercepted by the business logic for approvals, notifications, etc.
Staging works with absolute state, therefore is suitable for GUI and similar interactive components. Stage must not be kept for a long time. The lifetime of a stage should not exceed the lifetime of typical user session, which is approx. 30 minutes. If stage is held around longer, submitting of the stage may fail or the results may be different than expected.
Non-interactive components should not use staging at all. Such components should use directly the IDM model, using relative change descriptions.
Note: Staging is similar concept to the view as used in Sun IDM (Waveset). However, the staging does not imply that the data are freshly squeezed from the resources. We also hope to keep stages considerably simpler than views and much more similar to objects in the repository (in fact they will be almost the same). Also the view is quite confusing name in this context, especially considering that stage will be used by the GUI. It may easily get confused with the view of Model-View-Controller (MVC) pattern. However, the stage is part of the model aspect of MVC, not view aspect.