ehealthafrica / data-models-deprecated Goto Github PK

As a user, I'd love to be able to browse to https://schema.ehealthafrica.org and see a human-readable a list of each schema and their properties. Reading through a complex JSON doc such as Person is hard on the eyes.

For rollout of Sense in SL, we need wards. We should follow the precedent set by the SL call centre software.

Originally https://github.com/eHealthAfrica/data_model/issues/4 from @janl

… as set by http://www.django-rest-framework.org/api-guide/serializers/#hyperlinkedmodelserializer

Including the entire data-model build is quite heavy (~600K as of 1.12.0):

Being able to produce custom builds for example to only include a given set of schema(s) would be nice to have.

Spec is missing the deviceID property.

Following eHealth's procedure, two developers have to give me their 👍 for this repo to be published

{describe,it}.only should never be committed. Add a tool such as an ESLint plugin or Git pre-commit hook to check this.

uuid is a relic from a previous design choice and is a duplicate of _id (CouchDB's doc ID).

See https://github.com/eHealthAfrica/NutSurv-Mobile/issues/142

This is the list of known wards as we got it in some mail.

I created this issue to discuss whether we want to have this in our systems, And whether this is correct.

We might want to have it for validation if it is correct. About usability, i think that data entry will not be much faster using a select box based on the list, because a three-digit number can be entered quite conveniently with a numeric keyboard

https://github.com/eHealthAfrica/data-models/blob/master/schemas/Case.json#L66-L75
add age and gender as it is in patient

• Transform into JSON schema format
• Produce anonymised example

Originally https://github.com/eHealthAfrica/data_model/issues/58 from @emig

$ ./node_modules/.bin/data-model --model person --count 2

Fails for --count > 1

../node_modules/data-model/node_modules/json-schema-faker/node_modules/deref/lib/util/clone-obj.js:19
    Object.keys(obj).forEach(function(key) {
                     ^
RangeError: Maximum call stack size exceeded

Schema's should be available to download from schema.ehealthafrica.org.

Because of nginx wired / encoding issues :P we have to move to a different delimiter: :.

In order to make documents smaller, we'll split follow ups from contacts into their own document. We need a schema for that.

There is a tag reference, package version number mismatch.
current sl-call-center users 1.3.2 reference.

Refs #38

follwowing changes here https://github.com/eHealthAfrica/sl-ebola-call-admin/issues/861 the call schema should be updated

• team.memberID

• Synch package metadata
• Update changelog
• Update dist
• Tag
• Publish

According to @danse There are additional symptoms: ["jaundice","bruises","back_pain"]

See https://github.com/eHealthAfrica/sense-dashboard/issues/100

call.location.ward should have a numeric validation pattern.

Symptoms is missing as a property

I think that we had more troubles than expected with old-style versus new-style source cases. Let us try to plan and design more this time. I will write a small doc and we could keep it in this repo as a reference until the migration will be over. Both the document and this issue could be a reference for people stumbling upon that part of the code.

Goals:

• have a clear idea about how to adapt the code, for a better implementation
• anticipate possible problems
• have a single reference in dashboard, followup, search
• keep some doc for the poor people who might step into the adaptation logic

In the call centre, a deprecated property is used in order to show legacy locations, without allowing them to be used for new data. This allows to perform breaking changes smoothly, in two steps:

• deprecate old location, insert new, release
• migrate data in the database (optional)
• remove old location, release (optional)

This way, migrations do not need to be synchronised with new releases.

This property has to be added to the data model

Currently, if there's a validation error, the test runner (mocha) logs the error as minified JSON. Since this is meant to be human-readable, it should be pretty printed.

> mocha --watch                                                                                                                                                   [0/409]

child_process: customFds option is deprecated, use stdio instead.



  nutrition-survey
    1) validates the first example


  0 passing (109ms)
  1 failing

  1) nutrition-survey validates the first example:
     AssertionError: [{"code":"PARENT_SCHEMA_VALIDATION_FAILED","params":[],"message":"Schema failed to validate against its parent schema, see inner errors for details.
","path":"#/","inner":[{"code":"ANY_OF_MISSING","params":[],"message":"Data does not match any schemas from 'anyOf'","path":"#/definitions/team/properties/members/items"
...

MAC -> ANDROID_ID

This is currently all rights reserved. We need to consider which license is suitable given the repo's nature. Ref: http://choosealicense.com

IIRC, we implicitly version schemas by bumping the package version. If this is correct, it does not provide schema versioning on a granular level. Perhaps we ought to adopt a versioning scheme similar to that of the JSON schema spec itself, namely an id field and suffixing the version number to the schema's filename (e.g. draft-04.json).

… in order to generate more realistic examples

Add a human-readable reference for each property.

0.1.5 has been tagged upstream, which includes the commit we're currently pinned on (json-schema-faker/json-schema-faker@92ac981).

For speeds http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/

In YYYY.