DOCSEARCHbyAlgolia
Submit Docs

CommCare HQ

repository·master·Indexed 19 days ago

https://github.com/dimagi/commcare-hq

A multi-tenant web application platform for building and managing frontline worker solutions, focusing on data collection, case management, and reporting. The documentation covers technical implementation details including privilege management in the accounting app, analytics integration (Google Analytics, HubSpot, GTM), Case Tile Template configuration, and the Auditcare system for security and support investigations.

Tokens
258.7K
Snippets
712
Records
1.1K
Agent score
68%

What's inside commcare-hq

  2. Overview of CommCare APIs

    master

    CommCare APIs allow for integration with various system functionalities, including data retrieval, case and form submissions, and user management. The APIs are categorized into four main types:

    1. Data APIs: Used for building project-specific applications (e.g., custom end-user apps) or integrating with external back-end systems (e.g., electronic patient record systems).
    2. User APIs: Used for managing mobile and web users, including creation, editing, deletion, authentication, group management, Single Sign-On (SSO), and identity verification.
    3. Form Submission API: Implements the OpenRosa standard for submitting XForms over HTTP/S.
    4. SMS APIs: Enable sending and receiving SMS messages for automated messaging, notifications, and two-way data collection.

    Requirement: Access to these APIs requires a CommCare Software Plan (Standard Plan or above).

  4. Overview of the Dimagi JavaScript Guide

    master
    The Dimagi JavaScript Guide provides the internal standards and guidelines for writing JavaScript within the CommCare HQ project. All JavaScript code must be functional in all current major browsers and must adhere to the ECMAScript 2015 (ES6) standards.

  5. Overview of Messaging capabilities in CommCare HQ

    master

    Messaging in CommCare HQ is a collection of frameworks designed to handle various communication use cases between the platform and contacts. These capabilities include:

    • SMS Communication: Sending SMS to contacts, receiving SMS from contacts to trigger pre-configured actions, and collecting data via SMS surveys.
    • Voice Communication: Sending outbound calls and initiating Interactive Voice Response (IVR) sessions.
    • Automated Messaging: Sending messages based on time-based or rule-based schedules.
    • Alerting: Creating alerts based on configurable criteria and sending email alerts to contacts.

  6. Overview of CommCare HQ

    master

    CommCare HQ is a web application designed for building complex, customizable solutions for frontline workers. It provides a multi-tenant platform that includes application building, user management, data collection, and reporting capabilities.

    CommCare HQ is designed to work in conjunction with:

    • CommCare mobile: The mobile application for data collection.
    • Formplayer: The bundled web application platform.

  7. Overview of CommCare HQ core functionality

    master

    CommCare HQ is organized into several functional areas within the corehq directory. Key components include:

    • apps: The primary location for most system functionality.
    • blobs: A blob database for storing large binary data such as form XML, multimedia, exports, and temporary files.
    • form_processor: Handles the reception, processing, and storage of form submissions from CommCare mobile and Web Apps.
    • messaging: Manages direct-to-user messaging (SMS, email, WhatsApp) via the messaging app and related sms and smsforms apps.
    • motech: The integration layer used to forward data to remote APIs, import data, and manage complex workflows with systems like OpenMRS and DHIS2.
    • preindex: Manages the updating of CouchDB views and ElasticSearch indices; can be run during deployment or ad hoc.
    • extensions: A framework for extending HQ functionality in a fork-like manner (e.g., for specific implementations like ICDS-CAS).
    • project_limits: A framework for throttling actions (like form submissions) on a domain-specific basis.
    • privileges: A system to limit functionality based on the software plan.
    • toggles: A system to limit functionality based on specific users or domains.

  9. Overview of Auditcare and the User Audit Report

    master

    Auditcare (corehq.apps.auditcare) is a system that records HTTP requests and authentication events for security and support investigations. It stores data in two primary database tables:

    • NavigationEventAudit: Captures HTTP requests (timestamp, username, domain, IP, URL path, HTTP method, status code, and headers).
    • AccessAudit: Captures login/logout events (timestamp, username, domain, IP, and access type).

    Users can access a filterable view of these records via the User Audit Report at /hq/admin/user_audit_report/.

  10. Overview of the CommCare platform

    master

    CommCare is a multi-tier platform designed for building and configuring content and user interfaces, deploying them to Android devices or web interfaces for data entry, and receiving data in real time.

    Key capabilities include:

    • Application Deployment: Deploying to Android devices or end-user-facing web interfaces.
    • Messaging: Leveraging bi-directional messaging via API interfaces to SMS gateways, e-mail systems, or other messaging services.
    • Security:
      • Mobile Data: Stored using symmetric AES256 encryption-at-rest. Keys are secured by the mobile user's password and held only in memory. Data is locally irretrievable if the device is powered off or the user logs out without the password.
      • Data Transmission: All data transmitted between the phone and the server (and vice-versa) occurs over secure, encrypted HTTPS channels.

  11. Overview of Ex-Submodules in CommCare HQ

    master

    The corehq/ex-submodules directory contains code that was previously maintained in separate repositories but has been integrated into the main commcare-hq codebase. Many of these modules are related to CouchDB functionality, which is being phased out in favor of PostgreSQL. However, several modules remain actively used for core operations.

    Key active modules include:

    • casexml: For working with CaseXML.
    • pillowtop: A framework for change listening and processing.
    • soil: For scheduling and retrieving long-running tasks.
    • toggle: For managing feature flags.