Content

Schedule

Main event: 2024-01-22 - 2024-01-26 openIMIS/CORE-MIS Developers Workshop

Relevant Resources

• 2024-01-22 - 2024-01-26 openIMIS/CORE-MIS Developers Workshop

• 2023-05-08 - 2023-05-12 openIMIS/CORE-MIS Developers Workshop

• Project: 2023.T3 CORE-MIS Merger

• Project: 2022.T3 CORE-MIS Merger

• coremis

Minutes

1. Individuals module.

a) Individuals - Keep historical tags of recipient (primary/alternate).

• changes in the historical data needs to have a proper timestamp

• we need to adjust the Date form/date to (to display in proper way - mostly in user friendly way). It must be displayed in a format which user from certain localization is using.

• we should think also about deduplications

• How should we handle changing name/surname if there is requirement to not change this basic data and freeze some updates (TBC and review ??). BusinessChanges, RegistrationChanges. Differences between History and HistoryBusinessModel - history business model added timestamps to search objects within particular period of time. In some cases we cannot change historical data. This rework/redesign for those cases and deduplication might need be necessary to avoid confusions while searching into the past (for example: who receive money)

• 2 concerns:

  • time correlation

  • being able to keep historical data “frozen” in time (i.e for a past payment purposes)

  • being able to look for individuals based on the past data

• more detailed info about the historical models designs: Update of the core module + Replace, delete, deactivate, filter

b) Visualize programs benefited

• For the individual > program details > payment list, we should configure the search bar to be in context of the current individual (removing the first name, last name and other “individual” filters).

• For the individual > program details > payment list, We should add additional filters regarding the payment details: amount, …

• For the individual > program details > payment list, we have to make sure that the payments are filtered for the current benefit plan (Seweryn’s note: it’s not working at this time, need to be added and need to be adjusted to show benefits, not payments)

• Proposition how it can look on frontend level (we should consider adding 'Download' button to export all benefits). In this view we should also add the benefit plan/ programme:, select multiple for benefit type and for status, quantity, unit (for example amount, currency, quantity of things - in order to aggregate invoices and goods for particular individual/programme). We have to add this view here - https://coremis.s1.openimis.org/front/benefitPlans/benefitPlan/c46a99f9-d73f-45c1-bb8c-d7fce92b214e/benefitPackage/individual/8eaefae6-ba75-4514-95b9-d4be26292876 (benefit plan summary from individual page) (amount need to be displayed)

Open

The order shown in that view should be displayed from the most recent benefit received

Benefit status - multichoice

Total sum of received cash/payment benefits

c) Visualize list of historical groups - covered with Damian’s user stories (to paste the link)

2. Groups

   1. Create a group of individuals

      1. there must be a possibility to move a certain individual from one group to another

      2. changes group for many individuals should happen with a imported file → then the task as for data update shall be created

      3. option to create a new group from UI on the “Change group” modal (it’s displayed once you want to change a group for a particular individual)

      4. bulk upload - once user will be uploading data of individuals and indicated group will not exists system must create a new one with the name inidacted in the uploaded file

   2. Edit groups via UI

      1. no criteria at this point; any individual may belong to any group

   3. Modify group head and other data parameters

   4. photo

      1. for MVP purpose we can proceed with only 1 foto attached to Individual

      2. ability to add photos of individual through the bulk upload - that’s the priority

3. Programs

   1. View beneficiaries that belong to a program, under POTENTIAL, ACTIVE, SUSPENDED and GRADUATED

      1. There needs to be a link to a task for easier identification

      2. We need to make the process of identifing tasks easier as currently it’s too complicated

      3. Keep the search critieria detailes once we route back (search criteria on core-mis related modules)

   2. Update beneficiaries between statuses, also require a reason the update happened

      1. We need to keep the change log for beneficiary data update. It shall be visible on beneficiary detailed page. The goal is to visualize all the changes made for beneficiary on benefit plan level

   3. Everything that was deleted has to be read only.

   4. Include maker-checker logic on benefit plan deletion

4. Data updates

   1. Add a label to distinguish what data is old and what is new

   2. Dash cannot indicate that there is no change in the data since it’s confusing. Instead we need to repeat the previous data (not changed one) and those which are requested to be updated are changed to new one and highlighed

   3. Have a timestamp of that change (new column) and order it from the most recent one

   4. We need to change the way of how the tasks are currently assign for a tast executioner group. it has to be set in a config to have a specific execution group assign to task group by default. We can choose any other suitable way to handle that. Ideally, we can create a right that will be assign to a task group on the UI and once user has a particular right assign, it will be automatically granted the permission to approve/reject task

Program Graduation

• Mark a program as closed and mark all beneficiaries as graduated

Topics for hackathon:

WIP Modules

• Kamil: Allows the upload of CSV/Excel files which detail which invoice has been paid

• Severin: fixing openSearch real-time indexing once there is upload of individuals/beneficiaries

• rejected: upload of individuals with / without validation - to be done once Workshop is done, the change will allow smoother development but it won’t be tackle during the Workshop

•  

Backlog Modules

• targeting (upload individual and select based on the criteria)

• KOBO toolbox

• GRM

  • use case 1 (record an issue in the system):

    • User (with right privilege) navigates to grievance menu

    • Click on “new grievance”

    • enter data in Mask (one option is anonymous)

      • Basic info:

        • complainant

        • issue description

        • optional fields that can be filled optionally (later)

          • date

          • location

      • Unless anonymous, you have option to search for individual (reporter)

•  

open topics / questions