Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify user_input data model for different configurations #1045

Open
JGreenlee opened this issue Feb 1, 2024 · 0 comments
Open

Unify user_input data model for different configurations #1045

JGreenlee opened this issue Feb 1, 2024 · 0 comments

Comments

@JGreenlee
Copy link

JGreenlee commented Feb 1, 2024

Background

There is an inconsistency in the structure of user inputs stored on the server, depending on whether the configuration is "MULTILABEL" or "ENEKTO", which we have been talking about unifying for a while. (This is concerning the user_input property of confirmed and composite trips.)

Current data model

Current structure of confirmed/composite objects:

MULTILABEL: ENKETO:
{
  ...
  "user_input": {
    "mode_confirm": "walk",
    "purpose_confirm": "exercise"
  },
  ...
}
{
  ...
  "user_input": {
    "trip_user_input": {
      _id: ...,
      data: {
        name: "TripConfirmSurvey",
        xmlResponse: "<user response>",
        start_ts: ...,
        end_ts: ...,
        ...
      },
     metadata: ...,
   },
   ...
 }

Current structure of UserInputMap on the phone (since e-mission/e-mission-phone#1106):

MULTILABEL: ENKETO:
{
  ...
  "<tripId>": {
    MODE: {
      data: {
        label: "walk"
      }
    },
    PURPOSE: {
      data: {
        label: "exercise"
      }
    }
  },
  ...
}
{
  ...
  "<tripId>": {
    SURVEY: {
      _id: ...,
      data: {
        name: "TripConfirmSurvey",
        xmlResponse: "<user response>",
        start_ts: ...,
        end_ts: ...,
        ...
      },
      metadata: ...,
    }
  },
  ...
}

Proposed Change

Proposed structure of confirmed/composite objects

MULTILABEL: ENKETO:
{
  ...
  "user_input": {
    mode_confirm: {
      _id: ...,
      data: {
        label: "walk",
        start_ts: ...,
        end_ts: ...,
        ...
      },
      metadata: ...
    },
    purpose_confirm: {
      _id: ...,
      data: {
        label: "exercise",
        start_ts: ...,
        end_ts: ...,
        ...
      },
      metadata: ...
    }
  },
  ...
}
{
  ...
  "user_input": {
    TripConfirmSurvey: {
      _id: ...,
      data: {
        name: "TripConfirmSurvey",
        xmlResponse: "<user response>",
        start_ts: ...,
        end_ts: ...,
        ...
      },
      metadata: ...
    },
    ...
 }

Proposed structure of UserInputMap on the phone:

MULTILABEL: ENKETO:
{
  ...
  "<tripId>": {
    mode_confirm: {
      _id: ...,
      data: {
        label: "walk",
        start_ts: ...,
        end_ts: ...,
        ...
      },
      metadata: ...
    },
    purpose_confirm: {
      _id: ...,
      data: {
        label: "exercise",
        start_ts: ...,
        end_ts: ...,
        ...
      },
      metadata: ...
    }
  },
  ...
}
{
  ...
  "<tripId>": {
    TripConfirmSurvey: {
      _id: ...,
      data: {
        name: "TripConfirmSurvey",
        xmlResponse: "<user response>",
        start_ts: ...,
        end_ts: ...,
        ...
      },
      metadata: ...
    }
  },
  ...
}
JGreenlee added a commit to JGreenlee/e-mission-phone that referenced this issue Feb 2, 2024
Processed responses for user input surveys were not being matched because they were being looked up under "manual/trip_user_input", while it should have just been "trip_user_input".
This is because we were only invoking a function to trim off "manual/" for MULTILABEL user input matching, and it was neglected for ENKETO.

Revise the functions in confirmHelper (keeping 2 versions, `removeManualPrefix` which just trims the key, and `inputType2retKey` which looks up the key and then trims), and use `removeManualPrefix` in inputMatcher appropriately

Some day we can unify the data model (e-mission/e-mission-docs#1045) and not keep 2 versions of so many things
JGreenlee added a commit to JGreenlee/e-mission-phone that referenced this issue May 9, 2024
Part of the initiative described in e-mission/e-mission-docs#1045
This implements the "proposed" structure on the phone for Enketo user inputs.
When unprocessed user inputs are read and stored into unprocessedLabels in timelineHelper, responses will now be sorted by survey name instead of all being kept in one slot 'SURVEY'.

Also implement a new function, enketoHelper > resolveSurveyButtonConfig, which reads the config and determines what survey(s) are available for a button (like 'trip label', 'trip addition', 'place label', 'place addition').
Includes backwards compat so old configs (which don't have those fields) will just use the default 'TripConfirmSurvey'.
Including the translations for TripConfirmSurvey's 'not-filled-in-label' directly in the backwards compat to be consistent with new-style surveys where the translations are directly in the config.

This new function is used by <UserInputButton>, simplifying the code that was there previously. It now stores the returned SurveyButtonConfig object as 'survey' rather than keeping 'surveyName' and 'notFilledInLabel' separately.
This allows conditionalSurveys > getSurveyForTimelineEntry to be simplified too.
The new function is also used in timelineHelper > updateUnprocessedInputs. Instead of calling filterByNameAndVersion only for 'TripConfirmSurvey' and then storing those under the key of 'SURVEY', it first calls `resolveSurveyButtonConfig` to get *all* possible 'trip-label' surveys, iterates over those surveys calling filterByNameAndVersion for each, and stores unprocessed responses using the name of the survey as the key.

See types updated in LabelTabContext.ts.
appConfigTypes.ts updated to reflect that showsIf is optional (if not present, that survey shows unconditionally)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant