Implement Profile based configuration

[evilaliv3]

This ticket is to discuss an collect the requirements fro the implementation of a Profile based configuration.

For what collected so far profiles should:

• Allow the user to pick up a Profile during the wizard (primary)
• Allow the user to pick up a Profile during a later stage of customization (secondary)
• Allow the user to customize the Profile (secondary)
• In case of customized Profiles the platforms should allow manual reset by the a more up-to-date version of a full profile or its individual sub-component.

To be defined is the content of the profiles, that i expect to be preconfigurations of the default settings:

• default node configurations (intended as recipients configurations, context configurations, notification configurations)
• questionnaires / questions loaded

A proper db structure should be discussed and defined in order to host at least the primary requirements and allowing extensions towards the secondary requirements.

[evilaliv3]

With a recent discussion it has been identified to simplify this initial implementation to the load of the Config table, involving a simple load/export of key value pairs.

Specifically it has been also consider to left out of the implementation:

• configuration of contexts: e.g. creation of multiple contexts with different configurations
• configuration of users: e.g. creation of multiple users with different configurations

[NSkelsey]

To support a public version of the configuration that describes the loaded profile we would need:

• A single JSON description of that profile.
• The ability to POST that JSON to store/apply/load that profile
• A format for the profile makes no bare references to UUIDs and interprets a map of "name" => "key"
• Must be versioned and updatable

Helps us keep tighter control over nodes that are using a specific type of configuration. Up to user to choose to update to the new current default with a big "RESET DEFAULTS" button.

In order to Explain to users the changes to a profile, changelog entries, a paragraph, and maybe even a logo could describe it. All of this could be displayed in the wizard UI.

[NSkelsey]

An example profile could be Civil Society Activism:

{
   "contexts:" [{
     "name": 'public-campaign",
     'title': 'Report pollution and illegal dumping in the river Po',
     'tip_timetolive': 90,
     'enable_comments': true,
     'attached_questionaires': ['action-requested', 'types-of-pollutants'],
  }],
  "questionnaires": [
    {'name': 'action-requested', 'steps': 3, 'field-groups': {'.....'}, 
  ]},
  "config": {
     'enable_expiremental_features': true,
     'allow_indexing': true,
     'wbtip_timetolive': 180,
     'can_postpone_expiration': true,
     'show_small_context_cards': true, 
   },
  "key": {
    'public-campaign': 'ecd3a0fc-bc6a-400e-875c-5dd8e5ab8869',
    'action-requested': '0c2b6b14-71c4-4d50-92e0-cd9cf44a52e9',
    'types-of-pollutants': 'eeee3f03-dd94-4c96-b081-9e599647433d',
  },
}

[NSkelsey]

Todo
In order to implement this feature in devel this is roughly what is needed.

• Implement an UI for selecting Profiles [e.g. Empty, Profile1Name, Profile2Name]

• Implement a first POC where the selected profile correspond to the preconfiguration of the table Config table by using a json dictionary key:value stored as a file on the backend

{
  node: {
       key1:value1,
       key2:value2,
       key3:value3,
       key4:value4,
    }
}

• Update E2E tests to select profile in wizard and to check vars in the initialized backend.

• Extend the POC for preloading on at the initialization a selection of questionnaires; the questionnaires at this stage will be just passed as 'keys' and will correspond to files stored on the backend and possibly reused among templates. Examples of the possible modified data structure is:

{
  node: {
       key1:value1,
       key2:value2,
       key3:value3,
       key4:value4,
       default:: questionnaire1
    },
    questionnaires: [
       questionnaire1,
       questionnaire2
    ]
}

• Adjustment of wizard API endpoint to accept further structured JSON

• Implement config sanitization and assignment

• Implement needed DB and parsing changes to handle Key-UUID maps

[evilaliv3]

@NSkelsey: i've added some revisions on the plan and reordered so that each of the items could be integrated and tested opening the both of us to work on the next steps.

I've removed two items that should not be condisered in this topic:

• contexts: a profile is not intended to load contexts but just to set the configuration for the context generated during the wizard; i dont know if you already considered this but i let you notice that the simple configuration of the defaults values of Config determine the configuration of this context.
• questionnaires: questionnaires import and export are part of Implement support for the import and the export of questionnaires #2042 that will be a subsequent ticket we will start after this one. In the profile we will for the moment just configure the key of the Default questionnaire; check the 4th item above

[NSkelsey]

Ok, I totally agree on the simplification of the questionnaire in this case. The specification of the context likewise could work.

[NSkelsey]

This is the basic interface for the feature.

There are now two new questions to answer. What are the first profiles we ship and what settings do they flip?
The learn more link will point to a page in the documentation that will describe the various settings each profile throws. In previous revisions of the UI each profile had its own link (which can be brought back). That link can provide a detailed explanation of what settings get enabled.