The CHT Core Framework makes it faster to build responsive, offline-first digital health apps that equip health workers to provide better care in their communities. It is a central resource of the Community Health Toolkit.
I will look into this later but wanted to file this for now. All static files in the nodeunit-testrunner package return 404 when the test page is rendered. http://cl.ly/2x2o0s1R2r300L3H2Q3h
if form is not in the db: send them a message that an invalid form was submitted.
if the form is in the db but data not complete: send them a message asking them to complete the data and resend.
if a blank message is received: reply that an invalid/empty message was received on the server, please try again.
if a freeform message was sent: may be nice to have to have the option to accept or reject free form message.
I imagine this can gets tricky when you want responses to be in a different language. Can we change the locale of the server so that the responses are localized?
In the Records view, clicking on a record displays the form fields. I often find myself clicking on the record again to try to close the form fields, but then have to search for the X on the right to remove the form fields. Having a toggle behaviour on the record to show/hide the fields may be more natural to users.
possibly move towards a set of files like tests/{lists.js, updates.js, views.js} if possible. referral_msbr.js is huge and should probably get refactored.
In many implementations servers with Kujua-Export need to be accessible within a LAN or Internet, opening access of a client's potentially confidential information to the general public. The current security is by obscurity in that it is very unlikely for someone to find the address/link to the server and its data. However, we should have a way to limit access to authorized users only.
basic session support, it would be nice if we could associate some settings with a user as well. namely a default locale value and allow them to change that. (issue #27)
later we also want to extend it to allow for filtering based on district (issue #48). so a user would belong to a district or if admin they could see everything.
Forms don't get loaded, possible jquery init issue. Some style leaves a border, this could be a bug in bootstrap since we are on bleeding edge. Also media queries and zooming needs fixing.
define a short name in the forms to use in messaging to the end user so it's easier to understand instead of the form key. but also make sure you stay within 160 chars. Truncate with '...'.
We need to set Kujua up to accept plain SMS messages via the TextForms parser. Once the parsers are pluggable, we should test the full pipeline using the CDC weekly report.
Often after testing or training we want to delete all the messages in the database. Currently the quickest way to do that is to delete the database and replicate again. There may also be a need for a database administrator to delete messages accidentally sent twice.
Would be useful to have a quicker way to delete individual or bulk messages. Right now to delete individual message you must do 3 clicks and 2 page reloads (click document you wish to delete, loads document's page, click delete document, click to confirm delete, loads page with all documents).
the csv file that gets downloaded shows up garbled in preview (osx) but works ok in excel and other programs that "import" these files. http://cl.ly/2r3k2S0x1A0b1K2y1P35
We should find a more effective means to replicate across an organization, such as registering nodes on startup, otherwise we will continuously battle with network admin issues which are difficult to monitor remotely (port forwarding, dynamic IPs, etc).
We are doing some inefficient parsing on initial load to determine what data is available. We should add a map/reduce function so we can quickly determine what form types are available.
Feels odd complaining about the delimiter in a Comma Separated Value file, but Excel on FR localized computers does not automatically separate values in comma delimited CSVs. Would be great if localization could be detected and handled automatically.
With FR localization the comma is used as the decimal value, whereas semi-colon is used as the delimiter.
would be nice to have ready for testing a list of messages to send to a gateway once it's setup. you can find this right now by grepping the tests but we should probably maintain a list of test messages in a specific module, possibly that can be require()'d and scripted to send to a gateway.