Backend Modules

The backend of the OpenIMIS system consists of several essential modules that work together to provide comprehensive functionality. Each module serves a specific purpose and contributes to the overall operation of the system. Below is the list of backend modules:

1. openimis-be-individual_py

2. openimis-be-social_protection_py

   The openimis-be-social_protection_py module focuses on managing social protection-related information within the OpenIMIS system. It handles various aspects of social protection data, ensuring proper data management and processing.

3. openimis-be-tasks_management_py

   The openimis-be-tasks_management_py module is responsible for managing tasks and activities within the OpenIMIS system. It helps streamline workflow by handling task assignment, tracking, and completion.

4. openimis-be-opensearch_reports_py

   The openimis-be-opensearch_reports_py module provides functionalities for generating and accessing reports in the OpenIMIS system. It allows users to search and retrieve relevant reports based on specific criteria.

5. openimis-be-workflow_py

   The openimis-be-workflow_py module is dedicated to managing data upload.

6. openimis-be-payment_cycle_py

   The openimis-be-payment_cycle_py module is responsible for managing payment cycles within the OpenIMIS system. It handles payment-related processes, including scheduling, calculations, and disbursements.

7. openimis-be-calcrule_social_protection_py

   The openimis-be-calcrule_social_protection_py module is specialized in managing calculation rules for social protection data within the OpenIMIS system. It ensures accurate and consistent calculation of benefits and entitlements.

These modules work in tandem to create a robust backend infrastructure for the OpenIMIS system, enabling efficient data management, task handling, and reporting capabilities.

Please note that the list above provides an overview of the backend modules in the OpenIMIS system. Each module may have its own set of functionalities, services, and configurations, which can be further explored through specific documentation and resources.

OpenIMIS Backend Individual Reference Module Documentation

OpenIMIS Backend Social Protection Reference Module Documentation

Introduction

The OpenIMIS Backend Social Protection Reference Module is an integral part of the OpenIMIS system. This module is dedicated to handling social protection-related information, including benefit plans, beneficiaries, and group beneficiaries. It is designed to be deployed as a module of openimis-be_py, the OpenIMIS backend application.

This documentation aims to provide a comprehensive guide on how to utilize, configure, and interact with the Social Protection Reference Module effectively.

ORM Mapping

The module uses Object-Relational Mapping (ORM) to map data from the database to Python objects. The following ORM mappings are used:

• social_protection_benefitplan, social_protection_historicalbenefitplan -> BenefitPlan: Represents a social protection benefit plan entity.

• social_protection_beneficiary, social_protection_historicalbeneficiary -> Beneficiary: Represents a social protection beneficiary entity.

• social_protection_benefitplandatauploadsrecords, social_protection_historicalbenefitplandatauploadsrecords -> BenefitPlanDataUploadRecords: Represents data upload records associated with a benefit plan.

• social_protection_groupbeneficiary, social_protection_historicalgroupbeneficiary -> GroupBeneficiary: Represents a group beneficiary entity.

Developers can access and manipulate social protection data using these mapped objects, which abstract away the underlying database complexities.

GraphQL Queries

The module provides several GraphQL queries to retrieve social protection-related information:

• benefitPlan: Retrieves benefit plan data based on specified criteria.

• beneficiary: Retrieves beneficiary data based on specified criteria.

• groupBeneficiary: Retrieves group beneficiary data based on specified criteria.

• beneficiaryDataUploadHistory: Retrieves the data upload history of beneficiaries.

• bfCodeValidity: Validates the beneficiary code.

• bfNameValidity: Validates the beneficiary name.

• bfSchemaValidity: Validates the beneficiary schema.

• beneficiaryExport: Exports beneficiary data.

• groupBeneficiaryExport: Exports group beneficiary data.

These GraphQL queries provide a flexible and efficient way to retrieve relevant social protection data.

GraphQL Mutations

The Social Protection Reference Module offers GraphQL mutations to manage social protection data. Each mutation emits default signals and returns standard error lists following the conventions of openimis-be-core_py.

List of available mutations:

• createBenefitPlan: Creates a new benefit plan record.

• updateBenefitPlan: Updates an existing benefit plan record.

• deleteBenefitPlan: Deletes a benefit plan record.

• createBeneficiary: Creates a new beneficiary record.

• updateBeneficiary: Updates an existing beneficiary record.

• deleteBeneficiary: Deletes a beneficiary record.

• createGroupBeneficiary: Creates a new group beneficiary record.

• updateGroupBeneficiary: Updates an existing group beneficiary record.

• deleteGroupBeneficiary: Deletes a group beneficiary record.

These mutations enable seamless management of social protection data within the OpenIMIS system.

Services

The module provides the following services:

• BenefitPlanService: Offers methods to create, update, and delete benefit plan records.

• BeneficiaryService: Provides methods to create, update, and delete beneficiary records.

• GroupBeneficiaryService: Offers methods to create, update, and delete group beneficiary records.

• BeneficiaryImportService: Provides methods to import beneficiaries.

Developers can interact with these services to perform CRUD (Create, Read, Update, Delete) operations and handle beneficiary imports.

Configuration Options

The behavior of the Social Protection Reference Module can be customized through configuration options, which can be modified via core.ModuleConfiguration. The available configuration options are:

• gql_benefit_plan_search_perms: Specifies the required rights to call the benefitPlan GraphQL query. (Default: ["160001"])

• gql_benefit_plan_create_perms: Specifies the required rights to call the createBenefitPlan GraphQL mutation. (Default: ["160002"])

• gql_benefit_plan_update_perms: Specifies the required rights to call the updateBenefitPlan GraphQL mutation. (Default: ["160003"])

• gql_benefit_plan_delete_perms: Specifies the required rights to call the deleteBenefitPlan GraphQL mutation. (Default: ["160004"])

• gql_beneficiary_search_perms: Specifies the required rights to call the beneficiary and groupBeneficiary GraphQL queries. (Default: ["170001"])

• gql_beneficiary_create_perms: Specifies the required rights to call the createBeneficiary and createGroupBeneficiary GraphQL mutations. (Default: ["160002"])

• gql_beneficiary_update_perms: Specifies the required rights to call the updateBeneficiary and updateGroupBeneficiary GraphQL mutations. (Default: ["160003"])

• gql_beneficiary_delete_perms: Specifies the required rights to call the deleteBeneficiary and deleteGroupBeneficiary GraphQL mutations. (Default: ["170004"])

• check_benefit_plan_update: Specifies whether the update of a Benefit Plan should be approved. (Default: True)

Developers can adjust these options to control access, permissions, and behavior related to social protection data.

OpenIMIS Modules Dependencies

The Social Protection Reference Module relies on the following modules:

• core: Provides core functionality and utilities for the OpenIMIS system.

• policyholder: Handles policyholder-related information.

• individual: Manages individual references within the OpenIMIS system.

Ensure that these modules are correctly installed and configured for the Social Protection Reference Module to function properly.

OpenIMIS Backend Task Management Reference Module Documentation

Introduction

The OpenIMIS Backend Task Management Reference Module is a crucial component of the OpenIMIS system. This module is dedicated to managing tasks and activities within the system. It provides services, functionalities, and GraphQL queries related to task handling. The Task Management Reference Module is designed to be deployed as a module of openimis-be_py, the OpenIMIS backend application.

This documentation aims to provide a comprehensive guide on how to utilize, configure, and interact with the Task Management Reference Module effectively.

ORM Mapping

The module uses Object-Relational Mapping (ORM) to map data from the database to Python objects. The following ORM mappings are used:

• task_management_task, task_management_historicaltask -> Task: Represents a task entity.

• task_management_taskgroup, task_management_historicaltaskgroup -> TaskGroup: Represents a group of tasks.

• task_management_taskexecutor, task_management_historicaltaskexecutor -> TaskExecutor: Represents a task executor.

Developers can access and manipulate task-related data using these mapped objects, which abstract away the underlying database complexities.

GraphQL Queries

The module provides several GraphQL queries to retrieve task-related information:

• task: Retrieves task data based on specified criteria.

• taskGroup: Retrieves task group data based on specified criteria.

• taskExecutor: Retrieves task executor data based on specified criteria.

These GraphQL queries provide a flexible and efficient way to retrieve relevant task data.

Services

The module provides the following services:

• TaskService: Offers methods to create, update, and delete tasks, execute tasks, and mark tasks as completed or resolved.

• TaskGroupService: Provides methods to create, update, and delete task groups.

• TaskExecutorService: Offers methods to create, update, and delete task executors.

Developers can interact with these services to perform various operations related to task management.

Configuration Options

The behavior of the Task Management Reference Module can be customized through configuration options, which can be modified via core.ModuleConfiguration. The available configuration options are:

• gql_task_group_search_perms: Specifies the required rights to call the taskGroup GraphQL query. (Default: 190001)

• gql_task_group_create_perms: Specifies the required rights to call the createTaskGroup GraphQL mutation. (Default: 190002)

• gql_task_group_update_perms: Specifies the required rights to call the updateTaskGroup GraphQL mutation. (Default: 190003)

• gql_task_group_delete_perms: Specifies the required rights to call the deleteTaskGroup GraphQL mutation. (Default: 190004)

• gql_task_search_perms: Specifies the required rights to call the task GraphQL query. (Default: 191001)

• gql_task_create_perms: Specifies the required rights to call the createTask GraphQL mutation. (Default: 191002)

• gql_task_update_perms: Specifies the required rights to call the updateTask GraphQL mutation. (Default: 191003)

• gql_task_delete_perms: Specifies the required rights to call the deleteTask GraphQL mutation. (Default: 191004)

Developers can adjust these options to control access and permissions related to task management operations.

OpenIMIS Modules Dependencies

The Task Management Reference Module relies on the following modules:

• core: Provides core functionality and utilities for the OpenIMIS system.

Ensure that the core module is correctly installed and configured for the Task Management Reference Module to function properly.

Creating Execution Action Handlers and Business Event Handlers

The module allows the creation of execution action handlers and business event handlers for tasks. To implement custom handling of task execution or completion, developers need to bind to specific signals.

Binding to Task Execution Signal

To create an execution action handler, bind to the task_service.resolve_task signal using the handler_hook function. The handler should check the specific executor_action_event of the task.

Example:

Binding to Task Completion Signal

To create a business event handler for task completion, bind to the task_service.complete_task signal using the handler_hook function.

Example:

openIMIS Backend opensearch_reports reference module

OpenIMIS Backend Workflow Reference Module Documentation

Introduction

The OpenIMIS Backend Workflow Reference Module is a crucial component of the OpenIMIS system. This module is dedicated to managing workflows and integrating with various workflow systems. It provides services and functionalities to register workflow systems, query available workflows, and execute workflows. The Workflow Reference Module is designed to be deployed as a module of openimis-be_py, the OpenIMIS backend application.

This documentation aims to provide a comprehensive guide on how to utilize and interact with the Workflow Reference Module effectively.

Services

The Workflow Reference Module provides the following service:

• WorkflowService: Offers methods to register workflow systems, query available workflows, and execute workflows.

Developers can interact with this service to perform various operations related to workflows.

Registering Workflow Systems

The Workflow Service can be extended with custom adaptors to integrate with new workflow systems. Any adaptor must extend workflow.systems.base.WorkflowAdaptor and return triggers as implementations of workflow.systems.base.WorkflowHandler.

Example:

Querying Workflows

Querying available workflows can be done using the WorkflowService.get_workflows service. All registered workflow systems must implement filtering workflows by group and name.

Example:

Executing Workflows

Workflow handlers are self-contained triggers for a specific workflow in a given system. The WorkflowHandler.run method allows performing a workflow run with a given payload. Depending on the system, workflow runs can be synchronous and return the result of the workflow or asynchronous and return necessary information to check the workflow status in a given workflow system.

Example:

OpenIMIS Backend Payment Cycle Reference Module Documentation

Introduction

The OpenIMIS Backend Payment Cycle Reference Module is a crucial component of the OpenIMIS system. This module is designed to handle payment cycles and facilitate periodical payments for various business objects connected to payment plans. It offers services and functionalities to perform payment cycle calculations, including a specific service customized for Benefit Plan payment cycle calculation.

ORM Mapping

The Payment Cycle Reference Module utilizes ORM mapping to interact with the underlying database. The following mappings are used:

• payment_cycle_paymentcycle, payment_cycle_historicalpaymentcycle -> Individual: Represents the payment cycle entity.

Developers can use this mapping to access payment cycle data efficiently.

GraphQL Queries

The module provides a GraphQL query to retrieve payment cycle information:

• paymentCycle: Retrieves payment cycle data based on specified criteria.

GraphQL queries offer a flexible and efficient way to fetch relevant payment cycle information.

GraphQL Mutations

The module offers a GraphQL mutation to trigger the calculation of payment cycles:

• processBenefitPlanPaymentCycle: Initiates the calculation process for Benefit Plan payment cycles.

GraphQL mutations allow seamless execution of payment cycle calculations within the OpenIMIS system.

Services

The Payment Cycle Reference Module provides the following services:

• PaymentCycleService: A generic service containing the workflow for payment cycle calculation.

• BenefitPlanPaymentCycleService: A service customized for Benefit Plan payment cycle calculation.

Developers can utilize these services to perform payment cycle calculations and retrieve the results efficiently.

Configuration Options

The behavior of the Payment Cycle Reference Module can be customized through configuration options, which can be modified via core.ModuleConfiguration. The available configuration options are:

• gql_query_payment_cycle_perms: Specifies the required rights to query PaymentCycle. (Default: ["200001"])

• gql_create_payment_cycle_perms: Specifies the required rights to create PaymentCycle. (Default: ["200002"])

• gql_update_payment_cycle_perms: Specifies the required rights to update PaymentCycle. (Default: ["200003"])

• gql_delete_payment_cycle_perms: Specifies the required rights to delete PaymentCycle. (Default: ["200004"])

• gql_mutation_process_payment_cycle_perms: Specifies the required rights to call the processBenefitPlanPaymentCycle GraphQL Mutation. (Default: ["200005"])

These options allow administrators to control access and permissions related to payment cycle data and calculations.

Dependencies

The Payment Cycle Reference Module relies on the following modules:

• core: Provides core functionality and utilities for the OpenIMIS system.

• social_protection: Manages social protection-related information within the OpenIMIS system.

• contribution_plan: Handles contribution plan data.

• calculation: Facilitates calculation-related functionalities within the OpenIMIS system.

Ensure that these modules are correctly installed and configured for the Payment Cycle Reference Module to function correctly.

Payment Cycle Service

The Payment Cycle Service specifies a generic workflow for performing payment cycle calculations for various business objects connected to payment plans. It includes a specialized service for Benefit Plan objects. To trigger a calculation, the service requires a user reference, year, and month. Additional keyword arguments can be passed to the process() method to be used in calculations.

Example usage:

The result is a dictionary containing the status of the operation, indicating whether it completed successfully or encountered errors. It also includes messages and details of any errors that occurred during the calculation. Additional data returned from specific implementations of services and calculation rules are grouped by the ID of the main queryset entry (BenefitPlan ID in this case).

Please note that this documentation provides an overview of the features and components of the Payment Cycle Reference Module. For detailed information on how to set up, configure, and use the module, refer to the specific documentation and guidelines provided in the codebase and related resources. Additionally, the documentation is subject to updates and improvements as the module evolves, so make sure to keep it up-to-date with any changes you make.

OpenIMIS Backend Calcrule_Social_Protection Reference Module Documentation

Introduction

The OpenIMIS Backend Calcrule_Social_Protection Reference Module is a critical component of the OpenIMIS system. This module is responsible for performing calculations to determine the amount of payment for beneficiaries based on specific criteria specified in custom filters of payment plans. It allows for flexible and customized payment calculations tailored to the needs of social protection programs.

Calculation Process

The calculation process in the Calcrule_Social_Protection module is crucial in determining the payment amount for beneficiaries. The calculation is performed based on the specific criteria defined in the custom filters associated with the payment plan.

Custom Filters

Custom filters play a pivotal role in the calculation process. They are user-defined criteria that determine how the payment amount is calculated for each beneficiary. The custom filters are configured within the payment plan and are tailored to the requirements of the social protection program.

Frontend Modules

This documentation provides a brief overview of the JavaScript modules/packages found in the OpenIMIS Frontend (openimis-fe) project. These modules are integral components of the user interface and handle various functionalities related to managing social health insurance and social protection schemes.

1. openimis-fe-individual_js

   • Short Description: This module is responsible for managing individual member data in the OpenIMIS system. It facilitates tasks such as adding, editing, and deleting beneficiary information, ensuring accurate and up-to-date records.

2. openimis-fe-social_protection_js

   • Short Description: Focused on social protection features, this module handles functionalities related to social protection programs in the OpenIMIS frontend. It enables administrators to manage programs, assess eligibility, and associate beneficiaries with relevant social protection initiatives.

3. openimis-fe-tasks_management_js

   • Short Description: The tasks management module allows users to manage tasks within the OpenIMIS system. It provides functionality for task assignment, tracking, and completion, streamlining administrative processes.

4. openimis-fe-opensearch_reports_js

   • Short Description: This module enables the generation and display of comprehensive reports based on the data stored in the OpenIMIS system. Reports may cover aspects such as the health insurance scheme's performance, financial status, and member statistics, aiding decision-making processes.

5. openimis-fe-payment_cycle_js

   • Short Description: Responsible for managing payment cycles, this module handles payment calculations, processing payments to healthcare providers, beneficiaries, and maintaining a payment history. It ensures smooth financial transactions within the OpenIMIS ecosystem.

6. openimis-fe-coremis_language_pack_js

   • Short Description: The language pack module provides essential translations and localization support for the coreMIS naming in OpenIMIS frontend.

OpenIMIS Frontend Individual Module - Documentation

This documentation provides a comprehensive overview of the OpenIMIS Frontend Individual module. The Individual module is deployable module for managing individuals in the OpenIMIS system. Below, you will find information on building, deploying, contributions, Redux actions, state bindings, and configuration options.

1. Building and Deploying

• The Individual module is built using Rollup, a JavaScript module bundler.

• For building and deploying, refer to the openimis-fe_js repository and follow the instructions for development or server modes.

2. License

• The Individual module is licensed under the AGPL v3 (GNU Affero General Public License, version 3).

• Ensure compliance with the AGPL v3 license when using or modifying the module.

3. Main Menu Contributions

• The module contributes to the OpenIMIS main menu with the following options:

  • "Beneficiaries and Households" (individual.mainMenu translation key)

  • "Individuals" (individual.menu.individuals key): Displayed if the user has the right 159001

  • "Groups" (individual.menu.groups key): Displayed if the user has the right 159001

4. Other Contributions

• The Individual module interacts with the core.Router in the OpenIMIS client-side router by registering individuals and individual routes.

• It provides contribution points for tab panel labels and panels displaying Individuals.

5. Available Contribution Points
a. Dispatched Redux Actions:

• INDIVIDUAL_MUTATION_{REQ|ERR}: Sent when applying a mutation for an Individual.

• INDIVIDUAL_DELETE_INDIVIDUAL_RESP: Received as a result of the delete Individual mutation.

• INDIVIDUAL_UPDATE_INDIVIDUAL_RESP: Received as a result of the update Individual mutation.

• GROUP_DELETE_GROUP_RESP: Received as a result of the delete Group mutation.

• GROUP_UPDATE_GROUP_RESP: Received as a result of the update Group mutation.

• GROUP_INDIVIDUAL_DELETE_GROUP_INDIVIDUAL_RESP: Received as a result of the delete GroupIndividual mutation.

• GROUP_INDIVIDUAL_UPDATE_GROUP_INDIVIDUAL_RESP: Received as a result of the update GroupIndividual mutation.

• INDIVIDUAL_INDIVIDUALS_{REQ|RESP|ERR}: Triggered when fetching Individuals through the searcher.

• INDIVIDUAL_INDIVIDUAL_{REQ|RESP|ERR}: Triggered when fetching a chosen Individual.

• GROUP_GROUPS_{REQ|RESP|ERR}: Triggered when fetching Groups through the searcher.

• GROUP_GROUP_{REQ|RESP|ERR}: Triggered when fetching a chosen Group.

• GROUP_INDIVIDUAL_GROUP_INDIVIDUALS_{REQ|RESP|ERR}: Triggered when fetching GroupIndividuals through the searcher.

• INDIVIDUAL_EXPORT_{REQ|RESP|ERR}: Triggered during the export of Individuals.

• GROUP_EXPORT_{REQ|RESP|ERR}: Triggered during the export of Groups.

• GROUP_INDIVIDUAL_EXPORT_{REQ|RESP|ERR}: Triggered during the export of GroupIndividuals.

b. Other Modules Listened Redux Actions:

• None: The Individual module does not listen to Redux actions from other modules.

6. Other Modules Redux State Bindings

• The module binds to state.core.user to access user information, including rights and other relevant data.

7. Configuration Options

• The Individual module does not offer specific configuration options.

Please note that the Individual module is intended to manage individual beneficiaries within the OpenIMIS system. For detailed implementation details, code examples, and usage guidelines, refer to the actual code files in the module's repository. Additionally, ensure compliance with the AGPL v3 license when using or distributing this module.

OpenIMIS Frontend Social Protection Module - Documentation

This documentation provides a comprehensive guide to the OpenIMIS Frontend Social Protection module. The Social Protection module is offering deployable module to manage social protection-related functionalities within the OpenIMIS system. Below, you will find information on building, deploying, contributions, Redux actions, state bindings, and configuration options.

1. Building and Deploying

• The Social Protection module is built using Rollup, a JavaScript module bundler.

• For building and deploying, refer to the openimis-fe_js repository and follow the instructions for development or server modes.

2. License

• The Social Protection module is licensed under the AGPL v3 (GNU Affero General Public License, version 3).

• Ensure compliance with the AGPL v3 license when using or modifying the module.

3. Main Menu Contributions

• The module contributes to the OpenIMIS main menu with the "Benefit Plans" option (benefitPlan.menu.benefitPlans key).

• This option is displayed if the user has the right 160001.

4. Other Contributions

• The Social Protection module interacts with the core.Router in the OpenIMIS client-side router by registering benefitPlans and benefitPlan routes.

• It provides contribution points for tab panel labels and panels displayed under Benefit Plan and Benefit Package detail views.

5. Available Contribution Points
a. Dispatched Redux Actions:

• BENEFIT_PLAN_BENEFIT_PLANS_{REQ|RESP|ERR}: Triggered when fetching BenefitPlans through the searcher.

• BENEFIT_PLAN_BENEFIT_PLAN_{REQ|RESP|ERR}: Triggered when fetching a chosen BenefitPlan.

• BENEFIT_PLAN_MUTATION_{REQ|ERR}: Sent when applying a mutation for a BenefitPlan.

• BENEFIT_PLAN_DELETE_BENEFIT_PLAN_RESP: Received as a result of the delete BenefitPlan mutation.

• BENEFIT_PLAN_UPDATE_BENEFIT_PLAN_RESP: Received as a result of the update BenefitPlan mutation.

• GROUP_BENEFICIARY_UPDATE_GROUP_BENEFICIARY_RESP: Received as a result of the update GroupBeneficiary mutation.

• BENEFICIARY_UPDATE_BENEFICIARY_RESP: Received as a result of the update Beneficiary mutation.

• BENEFIT_PLAN_CODE_FIELDS_VALIDATION_{REQ|RESP|ERR}: Received as a result of BenefitPlan code validation.

• BENEFIT_PLAN_NAME_FIELDS_VALIDATION_{REQ|RESP|ERR}: Received as a result of BenefitPlan name validation.

• BENEFIT_PLAN_SCHEMA_FIELDS_VALIDATION_{REQ|RESP|ERR}: Received as a result of BenefitPlan schema validation.

• BENEFIT_PLAN_CODE_SET_VALID: Sets the validity of BenefitPlan code in Redux state.

• BENEFIT_PLAN_NAME_SET_VALID: Sets the validity of BenefitPlan name in Redux state.

• BENEFIT_PLAN_SCHEMA_SET_VALID: Sets the validity of BenefitPlan schema in Redux state.

• BENEFICIARY_BENEFICIARIES_{REQ|RESP|ERR}: Triggered when fetching Beneficiaries through the searcher.

• GROUP_BENEFICIARY_GROUP_BENEFICIARIES_{REQ|RESP|ERR}: Triggered when fetching GroupBeneficiaries through the searcher.

• BENEFICIARY_BENEFICIARY_{REQ|RESP|ERR}: Triggered when fetching a chosen Beneficiary.

• GROUP_BENEFICIARY_GET_GROUP_{REQ|RESP|ERR}: Triggered when fetching a chosen GroupBeneficiary.

• BENEFICIARY_EXPORT_{REQ|RESP|ERR}: Triggered during the export of a list of Beneficiaries.

• GROUP_BENEFICIARY_EXPORT_{REQ|RESP|ERR}: Triggered during the export of a list of GroupBeneficiaries.

• GET_WORKFLOWS_{REQ|RESP|ERR}: Triggered when fetching a list of Workflows.

• GET_BENEFIT_PLAN_UPLOAD_HISTORY_{REQ|RESP|ERR}: Triggered when fetching a list of historical workflow actions related to BenefitPlan.

• SEARCH_BENEFIT_PLAN_TASKS_{REQ|RESP|ERR}: Triggered when fetching a list of tasks related to BenefitPlan.

b. Other Modules Listened Redux Actions:

• None: The Social Protection module does not listen to Redux actions from other modules.

6. Other Modules Redux State Bindings

• The module binds to state.core.user to access user information, including rights and other relevant data.

• It also binds to state.policyHolder to retrieve Policy Holders for their respective pickers.

7. Configuration Options

• The Social Protection module does not provide specific configuration options.

Please note that the Social Protection module is designed to manage social protection-related functionalities within the OpenIMIS system. For detailed implementation details, code examples, and usage guidelines, refer to the actual code files in the module's repository. Additionally, ensure compliance with the AGPL v3 license when using or distributing this module.

OpenIMIS Frontend Tasks Management Module - Documentation

This documentation provides a comprehensive guide to the OpenIMIS Frontend Tasks Management module. The Tasks Management is a deployable module for managing tasks within the OpenIMIS system. Below, you will find information on building, deploying, contributions, Redux actions, state bindings, and configuration options.

1. Building and Deploying

• The Tasks Management module is built using Rollup, a JavaScript module bundler.

• To build and deploy the module, refer to the openimis-fe_js repository and follow the instructions for development or server modes.

2. License

• The Tasks Management module is licensed under the AGPL v3 (GNU Affero General Public License, version 3).

• Ensure compliance with the AGPL v3 license when using or modifying the module.

3. Main Menu Contributions

• The module contributes to the OpenIMIS main menu with the following options:

  • "Tasks" (tasksManagement.menu.tasksMainMenu key): Displayed to all users.

  • "Task Executioner Groups" (tasksManagement.menu.taskExecutionerGroups): Displayed if the user has the right 191001. Visible under Admin menu.

4. Other Contributions

• The Tasks Management module interacts with the core.Router in the OpenIMIS client-side router by registering tasks, task, taskGroups, and taskGroup routes.

• It provides a contribution point called tasksManagement.taskPreview, allowing the addition of tables suitable for displaying task entity subjects.

5. Available Contribution Points
a. Dispatched Redux Actions:

• MUTATION: Sent when applying a mutation for task management.

b. Fetching Task Groups:

• SEARCH_TASK_GROUPS: Triggered when searching for task groups.

c. Fetching Individual Task Group:

• GET_TASK_GROUP: Triggered when fetching a specific task group.

d. Creating Task Group:

• CREATE_TASK_GROUP: Triggered when creating a task group.

e. Updating Task Group:

• UPDATE_TASK_GROUP: Received as a response when updating a task group.

f. Deleting Task Group:

• DELETE_TASK_GROUP: Received as a response when deleting a task group.

g. Fetching Individual Task:

• GET_TASK: Triggered when fetching a specific task.

h. Updating Task:

• UPDATE_TASK: Received as a response when updating a task.

i. Resolving Task:

• RESOLVE_TASK: Received as a response when resolving a task.

6. Other Modules Listened Redux Actions

• The module listens to state.core.user to access user information, including rights and other relevant data.

7. Other Modules Redux State Bindings

• The Tasks Management module does not provide specific configuration options.

Please note that the Tasks Management module is designed to manage tasks within the OpenIMIS system. For detailed implementation details, code examples, and usage guidelines, refer to the actual code files in the module's repository. Additionally, ensure compliance with the AGPL v3 license when using or distributing this module.

OpenIMIS Frontend OpenSearch Reports Module - Documentation

This documentation provides a comprehensive guide to the OpenIMIS Frontend OpenSearch Reports module. The OpenSearch Reports is a deployable module for generating and managing reports using OpenSearch Dashboards. Below, you will find information on building, deploying, OpenSearch Dashboards setup, contributions, Redux actions, state bindings, and configuration options.

1. Building and Deploying

• The OpenSearch Reports module is built using Rollup, a JavaScript module bundler.

• To build and deploy the module, refer to the openimis-fe_js repository and follow the instructions for development or server modes.

2. License

• The OpenSearch Reports module is licensed under the AGPL v3 (GNU Affero General Public License, version 3).

• Ensure compliance with the AGPL v3 license when using or modifying the module.

3. OpenSearch Dashboards Setup

• To run the module on a dockerized instance, follow these steps:

  • Add the OPENSEARCH_BASIC_TOKEN environment variable to the environment file in openimis-dist_dkr. This variable should be based on admin and password credentials to OpenSearch.

  • Use the OPENSEARCH_PROXY_ROOT environment variable in the .env file in openimis-fe_js, set to "opensearch."

  • Run the backend and frontend services with opensearch and opensearch-dashboards services.

4. Main Menu Contributions

• The module contributes to the OpenIMIS main menu with the "Open Search Reports" option (openSearchReports.openSearch key).

5. Other Contributions

• The OpenSearch Reports module interacts with the core.Router in the OpenIMIS client-side router by registering openSearchReports routes.

6. Available Contribution Points

• The module does not specify any specific contribution points.

7. Dispatched Redux Actions

• The module does not specify any specific dispatched Redux actions.

8. Other Modules Listened Redux Actions

• The module listens to state.core.user to access user information, including rights and other relevant data.

9. Other Modules Redux State Bindings

• The module does not specify any specific Redux state bindings.

10. Configuration Options

• The OpenSearch Reports module does not provide specific configuration options.

Please note that the OpenSearch Reports module is designed to integrate with OpenSearch Dashboards for generating and managing reports. For detailed implementation details, code examples, and usage guidelines, refer to the actual code files in the module's repository. Additionally, ensure compliance with the AGPL v3 license when using or distributing this module.

OpenIMIS Frontend Coremis Language Pack Module - Documentation

This documentation provides a comprehensive guide to the OpenIMIS Frontend Coremis Language Pack module. The Coremis Language Pack is a deployable module with the purpose of changing default translations to ones suitable for CoreMIS. Below, you will find information on building, deploying, contributions, Redux actions, state bindings, and configuration options.

1. Building and Deploying

• The Coremis Language Pack module is built using Rollup, a JavaScript module bundler.

• To build and deploy the module, refer to the openimis-fe_js repository and follow the instructions for development or server modes.

2. License

• The Coremis Language Pack module is licensed under the AGPL v3 (GNU Affero General Public License, version 3).

• Ensure compliance with the AGPL v3 license when using or modifying the module.

3. Main Menu Contributions

• The module does not specify any specific main menu contributions.

4. Other Contributions

• The Coremis Language Pack module provides translations suitable for CoreMIS, altering the default translations used in OpenIMIS Frontend.

5. Available Contribution Points

• The module does not specify any specific contribution points.

6. Dispatched Redux Actions

• The module does not specify any specific dispatched Redux actions.

7. Other Modules Listened Redux Actions

• The module does not specify any specific listened Redux actions from other modules.

8. Other Modules Redux State Bindings

• The module does not specify any specific Redux state bindings from other modules.

9. Configuration Options

• The Coremis Language Pack module does not provide specific configuration options.

Please note that the Coremis Language Pack module is designed to change default translations to ones suitable for CoreMIS. For detailed implementation details, code examples, and usage guidelines, refer to the actual code files in the module's repository. Additionally, ensure compliance with the AGPL v3 license when using or distributing this module.

OpenIMIS Frontend Payment Cycle Module - Documentation

This documentation provides a comprehensive guide to the OpenIMIS Frontend Payment Cycle module. The Payment Cycle module is a deployable module for managing payment cycles within the OpenIMIS system. Below, you will find information on building, deploying, contributions, Redux actions, state bindings, and configuration options.

1. Building and Deploying

• The Payment Cycle module is built using Rollup, a JavaScript module bundler.

• To build and deploy the module, refer to the openimis-fe_js repository and follow the instructions for development or server modes.

2. License

• The Payment Cycle module is licensed under the AGPL v3 (GNU Affero General Public License, version 3).

• Ensure compliance with the AGPL v3 license when using or modifying the module.

3. Main Menu Contributions

• The module contributes to the OpenIMIS main menu with the "Payment Cycles" option (paymentCycle.paymentCycles.page.title key) under Payments.

4. Other Contributions

• The Payment Cycle module interacts with the core.Router in the OpenIMIS client-side router by registering paymentCycles and paymentCycle routes.

5. Available Contribution Points

• Dispatched Redux Actions:

  • PAYMENT_CYCLE_PAYMENT_CYCLES_{REQ|RESP|ERR}: Triggered when fetching PaymentCycles through the searcher.

  • PAYMENT_CYCLE_PAYMENT_CYCLE_{REQ|RESP|ERR}: Triggered when fetching a chosen PaymentCycle.

  • PAYMENT_CYCLE_MUTATION_{REQ|ERR}: Sent when applying a mutation for a PaymentCycle.

6. Other Modules Listened Redux Actions

• The Payment Cycle module does not listen to Redux actions from other modules.

7. Other Modules Redux State Bindings

• The module binds to state.core.user to access user information, including rights and other relevant data.

8. Configuration Options

• The Payment Cycle module does not provide specific configuration options.

Please note that the Payment Cycle module is designed to manage payment cycles within the OpenIMIS system. For detailed implementation details, code examples, and usage guidelines, refer to the actual code files in the module's repository. Additionally, ensure compliance with the AGPL v3 license when using or distributing this module.