FINERACT-1598: Remove unsupported recurringDepositFrequency fields from API docs

[Dhanno98]

Description

Implements FINERACT-1598: This PR fixes an inconsistency between the API documentation and backend validation for Recurring Deposit Product creation.

The fields recurringDepositFrequency and recurringDepositFrequencyTypeId are documented as supported request parameters in RecurringDepositProductsApiResource and RecurringDepositProductsApiResourceSwagger. But supplying these parameters results in validation errors.

This occurs because:

1. These fields are not present in DepositsApiConstants class which defines the valid JSON keys used for request parameter validation. The keys that we pass in the request JSON are compared against the set of valid keys from this class to check them for presence of any unsupported fields. Since these fields are not present as valid keys, we get validation errors.
2. These fields are not part of the domain model (RecurringDepositProduct), assembler (DepositProductAssembler), or any supported parameters used to construct a Recurring Deposit Product.

As a result these parameters are not used in building a RecurringDepositProduct and should not be documented as supported.

Changes

Remove both unsupported fields from:

1. OpenAPI @Operation documentation in RecurringDepositProductsApiResource.
2. Request Schema in RecurringDepositProductsApiResourceSwagger.

This aligns the API docs with the actual backend behavior.

Further Scope

The field charts is documented under Optional Fields in the OpenAPI @Operation documentation for the same POST body in RecurringDepositProductsApiResource. However, it is required for successful creation of a Recurring Deposit Product, and its absence results in a runtime validation error.
This may need a separate discussion.

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.

Your assigned reviewer(s) will follow our guidelines for code reviews.

[Dhanno98]

I checked the Liquibase Backward Compatibility failure in liquibase-backward-compatibility-check logs.

The error seems to occur during migration in 0072_add_result_and_status_to_command_source.xml where the column processing_result_enum does not exist when upgrading from base branch schema.

This PR only updates OpenAPI or Swagger documentation and does not modify any database or Liquibase files. The failure seems to be unrelated to the changes in the PR.

I also searched JIRA for related issues but could not find an existing ticket. I have initiated the self-serve process for my JIRA account which is pending activation. Please let me know if you'd like me to create a JIRA once access is available or if there is an existing issue I should reference.

[adamsaghy]

@Dhanno98 Can you please rebase this PR with latest develop branch?

[Dhanno98]

@adamsaghy Yeah sure!

[Dhanno98]

After rebasing the PR, the liquibase-backward-compatibility-check job that failed earlier is now successful. But there are 3 CI jobs that are failing. I went through the logs of these CI failures and wanted to share my observations:

1. MariaDB / test(test-core-3): The failure occurs in the task integration-tests during the Gradle test phase while executing test_progressive_interest_noRecalculation_prepay test. It appears to be due to SocketTimeoutException while executing LOAN_COB job. This PR only updates the OpenAPI documentation and does not touch COB, loan processing or integration test logic.

2. MySQL / test(test-core-5): This job fails while Initializing the mysql:9.1 container before any Gradle tasks or tests are run. It seems the job didn't reach any application code or tests and failed during initialization.

3. Smoke Test with Kafka: It fails during the gradle build for the task fineract-client-feign:buildJavaSdk with a Java heap space error. No messaging or Kafka related changes are part of this PR.

Form my analysis these failures seem unrelated to the PR changes and look like CI or infrastructure related issues.
Please let me know if I might be missing something and how would you like me to proceed from here.

[adamsaghy]

Kindly review https://github.com/apache/fineract/pull/5385/changes and merge these together... i dont think from Kapil's PR we need the mapper, but it can be double checked!

[Dhanno98]

Hi Adam,
I went through Kapil's PR: https://github.com/apache/fineract/pull/5385/files.

Yes you are correct, we don't need any new mappers. GLAccountTypeMapper is a new interface that was created and changes were made to an existing interface TaxComponentMapper. But these are not required for Recurring Deposit Product creation anywhere in the entire flow. The mapping during product creation is handled via ProductToGLAccountMappingWritePlatformServiceImpl.createSavingProductToGLAccountMapping() method based on the accountingRule that we give in the request JSON. The newly added mappers are not part of this execution flow.

I also went through the Swagger changes. My PR intentionally limits the fix to the POST schema as the issue was caused by unsupported fields being documented in the POST request. I felt extra or legacy fields in the GET schema are generally non blocking and can be left untouched. Also, Kapil's PR removes a @Schema(example = "false") annotation on line number 529 in GET which is there for public Boolean preClosurePenalApplicable on line 530 and shall not be removed.

Based on this I think of keeping the solution limited to the POST OpenAPI changes already present in this PR, without introducing additional mappers that are not required or modifying the GET schema. Please let me know your thoughts and how would you like me to proceed.

[Dhanno98]

Hi @adamsaghy,
Just a gentle follow-up on my earlier comment. When you have time, could you please confirm whether I should also update the GET Swagger or keep it unchanged, in case legacy fields are expected to remain untouched?

Thanks!