openspp / openspp-program Goto Github PK

It creates a big performance issue to do it that way. defining a criteria for this would be more efficient.

Create a new module that auto-enrols a group or an individual to a program.

• Add a new config in the program management:
  ** Auto-enroll eligible beneficiaries to the program
  ** Status: Draft or Enrolled
• Add a cron that does the following:
  ** record the current datetime and subtract 5 min -> future_last_updated_date
  ** List all the programs that have auto-enrol active
  ** For each program, check if any updated registrant (since the last updated date but not updated in the last 5min) matches the program enrollment criteria. If any, add them as Draft or Enrolled as configured
  ** update the last_updated_date with future_last_updated_date

Run this cron every hour.

Change UI Labels

The main issue we aim to address is the undesired loading of demo items in the Odoo stock management module, company, accounting, users, and others, which we aim to achieve without modifying the core code of Odoo.

To achive this, we need to disable the creation of demo data during database initialization.

How to use:

1. Clone spp docker repo.

• Open your terminal then go to your selected directory to clone spp docker
• Enter this command to clone: "git clone https://github.com/OpenSPP/openspp-docker.git"
• Check if openspp-docker directory is now showing in your current directory

2. Invoke Commands

• Open your terminal then go to openspp-docker directory
• Enter these commands in order:
  -- invoke develop
  -- invoke img-pull
  -- invoke img-build --pull
  -- invoke git-aggregate
  -- invoke resetdb
  -- invoke start
• In "invoke resetdb" command, the initialized database is configured without demo data. To include demo data in add "--demo" in the command.
  -- invoke resetdb --demo

3. Accessing application

• Odoo: http://localhost:15069/
• Mailhog: http://localhost:15025/
• wdb: http://localhost:15984/
• pgweb: http://localhost:15081/

In the entitlement manager, add a selection of card types. This will be used in recording the card number of the registrants when the entitlements are generated.

• We should put the specified SQL query in a subquery; that way, we can enforce the type of registrant (group, individual)
• Add a way to test the query and return the number of matching beneficiaries
• Make it work when we re-calculate the eligibility or import new beneficiaries

Change Logs:

1. Do not allow DMLs in the user-defined SQL query.
2. Fix error in the title bar of the wizard. It is no longer resetting to "Odoo" on any button click action.

How to use:

1. Define the SQL eligibility criteria during program creation:

• Go to Programs menu then click the "Create Program" button.
• In the "Set Program Settings" popup window specify the "Program Name" and select the "Target Type" (Group or Individual)
• In the "Configure Default Eligibility Criteria" tab select the "SQL-base Eligibility".
• Specify the SQL query in the "SQL Query" text box.
• Click the "Validate Query" button.
  • The query validation must return "Valid" for the program to be created. The total number of beneficiaries will also be presented in the UI.
• Proceed with the creation of the new program.

2. Modify the SQL eligibility criteria:

• Go to Programs menu.
• Open the program that will be modified from the list.
• In the program interface click the "Configuration" tab.
• Click the green button in the left of the "SQL Query" eligibility managers.
• In the popup window click the "Edit" button.
• All editable fields can be modified.
• If the "SQL Query" field was modified the "Validate Query" button must be clicked.
  • The query validation must return "Valid", otherwise the beneficiary enrollment will fail. The total number of beneficiaries will also be presented in the UI.
• Click the "Save" button.

After defining or modifying the SQL eligibility criteria, the beneficiaries must be re-validated.

• Click the "Import Eligible Registrants" button if you think that there are additional beneficiaries that needs to be added to the program based on the SQL Query defined.
• Click the "Enroll Eligible Registrants" button to run the SQL eligibility criteria checking with the existing registrants. All registrants that are not qualified will be marked us "Not Eligible"

How to Use:

1. Go to Program
2. Check a record or list of records
3. Click "Program Approval Receipt" button under the "Print" Action Menu then a PDF will be downloaded.
4. Open the PDF.

1. An error occurred when the in-kind entitlements are sent for approval.

Error log:

Traceback (most recent call last):
  File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_http.py", line 237, in _dispatch
    result = request.dispatch()
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 687, in dispatch
    result = self._call_function(**self.params)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 359, in _call_function
    return checked_call(self.db, *args, **kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/service/model.py", line 94, in wrapper
    return f(dbname, *args, **kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 348, in checked_call
    result = self.endpoint(*a, **kw)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 916, in __call__
    return self.method(*args, **kw)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 535, in response_wrap
    response = f(*args, **kw)
  File "/opt/odoo/auto/addons/web/controllers/main.py", line 1346, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "/opt/odoo/auto/addons/web/controllers/main.py", line 1334, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/api.py", line 464, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/api.py", line 451, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "/opt/odoo/auto/addons/g2p_programs/models/cycle.py", line 184, in to_approve
    self.program_id.get_manager(
  File "/opt/odoo/auto/addons/spp_entitlement_in_kind/models/entitlement_manager.py", line 170, in set_pending_validation_entitlements
    self._set_pending_validation_entitlements_async(cycle, entitlements_count)
  File "/opt/odoo/auto/addons/g2p_programs/models/managers/entitlement_manager.py", line 67, in _set_pending_validation_entitlements_async
    entitlements_count = len(entitlements)
Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 643, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 301, in _handle_exception
    raise exception.with_traceback(None) from new_cause
TypeError: object of type 'int' has no len()

2. Creation of cycles is not enrolling eligible registrants to the new cycle.
3. Registrants are not enrolled to cycle when the "Verify Eligibility" is clicked.

Increase test coverage for openspp_program

Hello :) Really nice Initiative!

I tried testing the OpenSPP packages on my Odoo15 test installation, but it looks like they have still a lot of dependencies on the OpenG2P repos.

Are you planning to port all these G2P addons over or is it intended to stay an external dependency?

To move to job queue:

• cyclemanager.check_eligibility
• entitlementmanager.approve_entitlement
• entitlementmanager.cancel_entitlements

UI fixes:

• Remove one2many fields in registry UI tree views
• Remove record count fields in the registry UI tree views

Description:

We are introducing a new feature to our OpenSPP program management system: Compliance Criteria. This is conceptually similar to Enrollment Criteria, yet with operational differences.

Requirements:

1. Compliance Criteria are ongoing conditions that enrolled participants must continue to meet in order to stay active in a program and receive its benefits. Compliance checks would occur regularly at each program cycle.

2. Just like with the enrollment criteria, the compliance criteria should be flexible and customizable for each program, as different programs may have different compliance rules.

3. Technically, the compliance criteria check should be similar to that of the enrollment criteria check, but with a crucial difference: while enrollment criteria are evaluated once, compliance criteria need to be evaluated at each defined cycle or period.

Example:

In the 'cash for work' program, the enrollment criteria could be based on the unemployment status and income level, but the compliance criteria would look at whether the individual has worked the required number of days in a month.

Tasks:

1. Develop a mechanism for defining compliance criteria for each program, similar to enrollment criteria.
2. Implement regular checks for compliance at each program cycle.
3. Provide a UI to visualize the compliance or not at a given cycle for a person.

Outcome:

Fully functional compliance criteria feature that provides regular checks and validation against defined program rules.

The cron job will check the eligibility.

Payment related transactions

Change Logs:

1. Make the transactions UI readonly.

How To Use:

This requires the data populated by the API

1. Monitor the Cash Entitlement Transactions

• Go to "Programs -> Accounting -> Entitlement Transactions".
• This will display a list of all the cash entitlement transactions populated by the API.

2. Monitor the In-kind Entitlement Transactions

• Go to "Programs -> In-Kind -> Entitlement Transactions".
• This will display a list of all the in-kind entitlement transactions populated by the API.

• Add an option in the cycle manager for checking the eligibility of beneficiaries before approval.
• Validate the eligibility of the beneficiaries before approving the cycle.
• The entitlements of the beneficiaries that are no longer eligible will not be approved.

• The program will consist of only 1 cycle and once the program is created it will allow generating entitlements for disbursement.

Overview

Each program within the OpenSPP system needs to have a unique identification. This will be represented by the program_id field.

• program_id is a string and should be auto-generated by the system.
• The format of program_id should be PROG_{SEQ}.
  • PROG_ is a static prefix.
  • {SEQ} is a dynamically generated unique sequence number.
• The sequence number {SEQ} should increment for each new program.

Program Referencing

• Each program should be easily identifiable and searchable through its unique program_id. This implies that program_id should be indexed in the database to allow efficient searching and sorting.
• The program_id should also serve as the XML ID of the record, facilitating easy referencing of the program in XML files and throughout the system.

Constraints

• program_id should be unique. The system should not allow the creation of two programs with the same program_id.
• program_id should not be editable by users once the program is created. This is to maintain the integrity of the program_id.

This detailed specification aims to improve the handling and identification of programs within the OpenSPP system. The unique program_id not only ensures the uniqueness of each program but also enhances the search and sorting capabilities, providing a better user experience.

1. A document connecting transactions with service points(more like a proforma invoice).

• Famoco will post the transaction via the API provided by us
• We will utilize the Odoo bookkeeping module across process.
• We are going to move money between accounts using the Odoo bookkeeping module which will allow us to manage finances. i.e: can the funds be an negative value?

2. Approval of the document.

• This can happen via a workflow within OpenSPP
  (optional) - sent to the service point for verification of the document.

3. Settlement of the payment - will be sent to Famoco for settlement

• Will be an API for them to fetch document(s).

4. Famoco will inform us via an API about the settlement after settlement.

While it can be done now, it could become complex to manage when the criteria list grows. We can add another field where we can define the domain of the excluding criteria.
We then merge the inclusion and exclusion domains this way:
INCLUSION AND NOT EXCLUSION
in the query

When a program is created, we need to be able to define how an entitlement is associated with a service point, if necessary.

For clarifications:

• Link service points to registrants - add a field in the registrant model to identify the assigned service point.
• Copy the service point assigned to the registrant when generating entitlements

The program will implement a new eligibility manager named TagBasedEligibilityManager. It will inherit from BaseEligibilityManager and will determine eligibility based on a registrant's tag and their association with a specific area, including all of its child areas. The system will prevent any infinite recursion within the area hierarchy. If both tag and area criteria are specified, a registrant must meet both to be considered eligible.

The new manager will be responsible for enrolling and importing registrants, ensuring the new eligibility criteria are upheld during both processes. To optimize performance with potentially large datasets, the manager will utilize pagination or batching techniques during these operations.

How to Use:

1. Define the Tag eligibility criteria during program creation:

• Go to Programs menu then click the "Create Program" button.
• In the "Set Program Settings" popup window specify the "Program Name" and select the "Target Type" (Group or Individual)
• In the "Configure Default Eligibility Criteria" tab select the "Tag-based Eligibility".
• Specify the Tag and Area. Tag is required while Area is optional.
• You can check in Domain the records that matched with the selected Target Type, Tags, and Area.
• Proceed with the creation of the new program.

2. Modify the Tag-based eligibility criteria

• Go to Programs menu.
• Open the program that will be modified from the list.
• In the program interface click the "Configuration" tab.
• Click the green button in the left of the "Tags Manager" eligibility managers.
• In the popup window click the "Edit" button.
• All editable fields can be modified.
• Click the "Save" button.

After defining or modifying the Tag-based eligibility criteria, the beneficiaries must be re-validated.

• Click the "Import Eligible Registrants" button if you think that there are additional beneficiaries that needs to be added to the program based on the Tag-based eligibility defined.
• Click the "Enroll Eligible Registrants" button to run the Tag-based eligibility criteria checking with the existing registrants. All registrants that are not qualified will be marked us "Not Eligible"

If the target type is "Individual", the entitlement manager is "default", and there are no filters defined, the function that imports eligible registrants is getting all records from res.partner.

This includes records with the following:

• is_registrant is null
• is_registrant is set to False

In OpenG2P Program, make validate_entitlements async the same way as we did for prepare_entitlements ( https://github.com/OpenG2P/openg2p-program/pull/6/files )

Payment error codes representation for API specification

We need to define the process for QA. This should cover:

• how to work with individual tickets
• how to perform regression testing
• how to document test scripts
• how to document test executions
• how to report on tested tickets
• how to report identified issues
• what is required from the tickets/environment to start testing

Now we do days:
https://github.com/OpenG2P/openg2p-program/blob/15.0/g2p_programs/models/managers/cycle_manager.py#L115

We should have the option to set the recurrence. Check other odoo modules, they use rrule.
See if we can reuse the code used in the calendar module:
https://github.com/odoo/odoo/blob/fa58938b3e2477f0db22cc31d4f5e6b5024f478b/addons/calendar/models/calendar_recurrence.py#L92

Since we don't yet have a description of the included functionality for ACF we will start of with updating the existing test repository of generic OpenSPP test cases. The aim of this is to onboard Adrian in the OpenSPP functionality as well as to provide a possible outline of test suites and test cases to be reused once the ACF expected functionality is available.

The areas to cover are as below:

• program
• entitlement cash
• entitlement inkind
• registry

For each program, instead of defining a set of criteria, we can define a formula to calculate a score that is then used to enrol the X top registrants.