Affects Version/s: None
Fix Version/s: None
Component/s: GPII Framework
GPII-2556 will require some adjustment to core framework workflow. Whilst the PCP edits information which is isomorphic to settings (and, primarily, with the lifetime of settings) it does so in a schema aligned with preferences. This requires a route for preferences metadata (for example, the stickiness of a PCP setting, and indeed whether it appears in the PCP or not) to be able to find its way from a preference set as well as a core ontology and solutions registry into the PCP payloads. This requires us to adjust the way in which the "untrusted" (currently the default) configuration of the FlowManager manages its data, and create some new cloud endpoints.
Meeting of 21/8/17 written up at https://pad.gpii.net/p/pcp-with-memory-core-team-discussions-tby4n2s discussed the need for the new endpoint required for the PCP to write to the user's preference set. Discussion with Kaspar today suggested that the best route for getting metadata, provenance info etc. to the client will be to implement a matched endpoint to the planned /untrusted-preferences PUT to implement a GET which returns the slice of the preference set corresponding to the applied settings.
The local FlowManager then has 3 sources of information to synthesize to construct the final PCP payload:
i) metadata and structural information (and in fact, initially, the preference values themselves) from the /untrusted-preferences endpoint
ii) schematic information about common terms as extracted from, e.g. Steven Githens draft gist at https://gist.github.com/sgithens/95190bfb47f8b4ce57a3a2bf1ed39d1e tracked under
GPII-2343. This will be housed in the ontologyManager's area in a file matching, e.g. https://github.com/GPII/universal/blob/master/testData/ontologies/ISO24751.json5
iii) information from the solutions registry which will also be supplied metadata under work such as
GPII-1909 and others.
It will then require to operate a very minimal form of "spinal matchmaker" - payloads at https://github.com/GPII/gpii-payloads/blob/master/CloudBasedMatchMaker.md show the CloudBased MatchMaker returning common terms nested within solutions, although this has been removed by a recent pull of KASPAR's - https://github.com/GPII/universal/pull/512/files#diff-8ac2708b41bf6c4ebfe9ecb8f892a386 for
GPII-2297. We will need to revert part of this to retain the information necessary for the client to correlate use of preferences as common terms with their use in solutions. When the preference model is updated via the PCP UI, we map the values into place in the matchmaker's return payload, then run the transformer, and then apply the lifecycleManager's "update" lifecycle, which Kaspar assures us will work.