Thanks Johnny. That is what I thought, but I came across this paragraph in the Admin Guide and it threw me off:
The D2 engine determines which config, that is autolinking, check-in, inheritance, and other such component configurations to use, by scanning all contexts defined in the matrix from left to right. The first context which is matched will result in the D2 engine applying all component configurations associated to the same context from top to bottom.
Do they mean that the first Context will be matched then the second all the way down. Right? Why don't they say something like "All Context are matched; in case of conflict, the most left context takes precedent".
The D2 contexts are unique or additive depending on the configuration element.
For example, in case of D2 security template - contexts are unique. That is for any object, the FIRST context encountered (context A) (while moving from left to right) that satisfies the criteria - the FIRST security template (Template 1) mapped to that context will get applied.
Context A Context B Context C Security Template 1 X Security Template 2 X Security Template 3 X Security Template 4 X
If the object falls under more contexts to the right of the first one, then the security templates mapped to it (Template 2 and 3) will never get applied. This is because, the contexts B and C will never get evaluated at all!
While applying security, D2 will just look for the first context that satisfies and the first template mapped to it (Template 1). Hence, template 4 will also never get applied.
This is the unique behavior of contexts.
The unique nature usually applies to Menu, Toolbars, Theme, Security, Property Page, Inheritance, Widgets, Extended Creation Profile, Workspaces etc.
Now coming to additive behavior:
Context A Context B Context C Autonaming Template 1 X Autonaming Template 2 X Autonaming Template 3 X Autonaming Template 4 X
In this case, all the four autonaming contexts will get applied in the order -> Autonaming 1, Autonaming 4, Autonaming 2 and Autonaming 3.
As evident, in the case of additive behavior, D2 evaluates all the contexts. Then it applies the configuration from left to right. In case more than one configuration is mapped to a context, the configurations are applied from top to bottom.
The additive nature usually applies to Auto naming, Auto link, Lifecycles, Workflows, Query Forms, Subscription, Distribution, Audits, Mass Update etc.
Now coming to the question about workspaces:
Workspaces are a work-area for users - where the users roles can be configured. For example we can have a workspace for Contributors, one for Document Controllers and one for System Admin.
Like most security-related configurations in D2, it shows unique behavior during selecting workspaces from contexts.
Hence, in your example - only Workspace 1 would be available to users who fall under both the contexts A and B.
If you want to make two workspaces available to the user, you need to map both the workspaces to context A.
A user can have access to multiple workspaces - but ONLY if they are mapped to the same context.
While picking up the workspaces and widgets for the logged in user, D2 will pick up the first encountered context that has widgets and workspaces mapped to it.
Once D2 gets hold of the context, it will apply the widgets and workspaces mapped to that single context and will look no further.
As far as my experience goes, only child context can suffice above requirement as mentioned clearly in question user is not configuring both the workspaces against same context. As mentioned in question if there are two group contexts and user is part of both group then the leftmost context is loaded and only workspace configured for that context will be visible to user.
The original post about the question is just a query regarding the unique or additive behavior of contexts in D2.
There is nothing stopping us from mapping both the workspaces to the left-most context. In fact, it is the simplest way to arrive at the solution. Child context creation doesn't make sense when a simple checkmark would achieve the same result.
There will be numerous requirements where in you will have two group context and two workspaces and you want to show only the workspace which is configured for that group context. So this clearly stops from configuring both the workspace for the particular group context. And this was the requirement of Alain.
Context A Context B Workspace 1 X Workspace 2 X
Now coming back to question, the question was if there is user who is part of both the groups should see both the workspace.
Only child context creation makes sense over here and it is only solution to achieve this requirement.