15.2.9. Connecting users
It turns out that a user graph that consists of unconnected subgraphs certainly means synchronization cannot be complete, but it is not the other way round. In other words, this test is not strong enough. Have a look at Figure 13. There are no unconnected subgraphs, but only changes made by Client will be communicated to Sales Person and Controller.
Figure 13. A UserGraph that does not allow synchronization of changes made by Controller.
A better test is to check whether, from a node representing a user with a modifying perspective, all other nodes representing users can be reached. This can be done with a simple depth first search (while preventing loops).
We still want to project the graph for a given mutation, but on top of that we need a list of nodes that represent a user with a modifying perspective.
15.2.9.1. A special case: modifying a property on the role graph of a user role
Consider Figure 14. This user graph allows for complete synchronization, as the left user is the only one to modify R and has a perspective on the only other user who, in turn, has a (consulting) perspective on R.
Figure 14. The left user has a modifying perspective on R, while the right user has a consulting perspective.
What about when it is the other user itself that is being modified? Figure 15 depicts this situation, with an added twist.
Figure 15. User A modifies a property on user B. B is filled by the system role User, having a self-perspective.
Now suppose that a modifies a property P on User – by virtue of having a perspective on B (this is allowed, as a perspective includes all fillers of the role, recursively). Clearly, because User has a self-perspectives (and we make it include P), he should be informed. The user graph projection for P is given in Figure 16. The synchronization checker will report a problem: changes made by A to P will not arrive at User! This is because a has no expliciet perspective on User.
Figure 16. User graph for Figure 15. There is no path from A to Role “User”!
However, a user role with a perspective on a calculated object needs access to all entities along the query path. We say this user has an implicit perspective on those entities. This is worked out by establishing an inverted query on each entity along a query path, for the user having the calculated perspective.
We consider the property P on User to be a calculated property on B. Consequently, there will be an inverted query on P saying that when it changes, A should be informed.
In other words, A has an implicit perspective on User. This is not just theory but works in practice: User makes sure that A has all information about him that his (A’s) perspective allows – due to the inverted query on P.
So the simple connection check between A and User gives us a false negative. Should we include implicit perspectives when we build the user graph? It turns out that this is not necessary (and that is a good thing, because recursively adding perspectives to all fillers of a user role would make the graph grow very big).
Instead, we can simply skip the connection check for projections on a user role U and its properties, for a modifying user M and U. The reasoning goes like this:
-
We should check whether M can reach U;
-
We do check because M modifies U;
-
Hence M can reach U.
We should still check other user roles with a perspective on U. M may or may not have a perspective on them.