When logged in as root, the Experimenter field of Details should be honored.

[Josh Moore <josh.moore@…>]

Unlike "normal" users, root should be able define to whom an object belongs by calling:

 iObject.getDetails().setExperimenter( user )

This will be needed to support #50 in which the importer/resurrector wants to save an entire multi-user graph in a single transaction.

Current, best, short-term solution is to add an if-clause in the Details managing code of UpdateFilter which checks the current user for being root.

Things that go along with this:

• Can a regular user do this by sudo-ing. (needs @RunAs?)
• Can other "Admins" do it (don't currently have them)
• ...

[jmoore]

Discussion with Chris. Moving to iter3 to not rush this.

[jmoore]

r700 implements this in UpdateFilter. It's currently a bit limited so I'm going to leave this open for discussion.

Limitations are:

• To fulfill #50, resurrect will need to be run as root
• Currently, the group of a user is not taken into account. The logic is: if (root) then ... else ....
• Testing. There are mock tests for all the cases I can think of, but we need to review. Integration tests would also make sense.

Any other requirements short-,mid-, and long-term?

[jmoore]

r704 and r705 support this. SecurityViolation thrown on any misuse.

Testing is fairly extensive, though the changing of group fields could be more thought thorough. ( We don't have that many groups at the moment. :) ) Currently, there are no plans for allowing the system (i.e. admin) group to do this, but a @RunAs("root") annotation should be simple enough.

In general, the security logic will need to be factored out as it gets more complicated. Something along the lines of:

   new UpdateFilter( hibernateTemplate, securityFilter );

[jmoore]

r713 fixes a small mistake in UpdateFilter. Changes allowed root to set Details to null even though the Details fields are usually not-null.