Flow of social structure

Output/creating social attributes

A social structure can only be created by a social operator, the output of which might be one or more attributes. Each socialOperator package has to specify its output definition, either as a static array, or a function taking the config data as input, and returning an array of social attributes.

Example of a static definition:

export default ({
  id: 'op-argue',
  type: 'social',
  operator,
  config,
  meta,
  outputDefinition: ['group']
}: socialOperatorT);

In this case, the operator op-argue will always produce a social attribute called group.

Example of a function:

const outputDefinition = conf => [(conf && conf.grouping) || 'group'];

export default ({
  id: 'op-create-groups',
  type: 'social',
  operator,
  config,
  meta,
  outputDefinition
}: socialOperatorT);

In this case, the operator op-create-groups will generate a social attribute whose name depends on the config field grouping.

Input/consuming social attributes

There are two ways in which social attributes can be consumed. The first is through the groupingKey of a plane 2 (team based) activity. It is statically verified by the graph editor that all team based activities have a grouping key, and that this grouping key matches an incoming social attribute.

The second is through an operator or activity configuration. An activityPackage or operatorPackage can request a social attribute using the type socialAttribute, example:

export const config = {
  type: 'object',
  properties: {
    roles: {
      type: 'socialAttribute',
      title: 'Social attribute to get role: editor'
    }
  }
};

In this case, the activityPackage will customize the activity view for different roles within the same instance. The graph editor provides a drop-down to select available social attributes, and verifies statically that the social attribute chosen still exists, and does not overlap with the groupingKey of the activity. Note that in the case above, it would be valid to not select a socialAttribute, if the package wants to enforce choosing a socialAttribute, it needs to add the roles field to the required fields.

All social attributes are interchangeable

Currently all the social structure checks assume that all social structures are interchangeable. For groupingKey this makes sense -- there is no semantic difference between groups: [1, 2, 3], and roles: ['chef', 'waiter']. etc. However, for an activity which uses roles to distinguish between different roles during the activity in the same instance (for example, only one person can edit, but everyone can see, like in the example above), it actually requires an activityStructure with specific attributeValues. This is currently not statically verified.