Fix for Guarantors approval workflow and Internal localhost hooks requests

[PareekshithPalat]

Resolved Internal localhost hooks requests intermediate errors

Fixes

Previously, TemplateMergeService relied on the credentials of the currently authenticated user. During asynchronous execution (such as SMS template processing), the required authentication context was unavailable, causing the internal API requests to fail and resulting in empty template variables.

Example:

Before

Hello

After

Hello user12 main

TemplateMergeService performs internal REST API calls to retrieve entity data required for Mustache template rendering.

Previously, these requests depended on the active user's authentication context.

During background execution, the required authentication headers were not available, causing the internal API call to fail and preventing template variables from being populated.

A dedicated internal service account has been introduced exclusively for TemplateMergeService.

Instead of using the currently logged-in user's credentials, all internal localhost API requests are now authenticated using this dedicated account.

This ensures that mapper resolution works consistently regardless of the user initiating the request.

Changes Made

1. Added Dedicated Internal Service User

" template_system "

2. Added Liquibase Migration:

Created a new Liquibase changeset to provision the dedicated service account.
File :

0136_add_template_system_user.xml

3. Password Storage:

The service account password is not hardcoded inside the Java source code.
The password is configured through application configuration.
The password stored in the database is generated using Spring Security's DelegatingPasswordEncoder, which currently produces a BCrypt hash.

4. Added Internal User Configuration

Added new configuration under FineractProperties.

template:
    internal-user:
        username:
        password:

Fixed SMS Notifications for Guarantor Approval and Rejection

Fixes

Previously, SMS notifications were not generated when a guarantor was approved or rejected.

The event generated during the guarantor approval/rejection workflow did not include the associated clientId. Since the SMS notification framework requires the client identifier to resolve the recipient and populate template data, the notification pipeline could not proceed.

This change includes the associated clientId in the generated event, allowing SMS notifications to be created successfully for both approval and rejection events.

APIs

Approve Guarantor

POST https://localhost:8443/fineract-provider/api/v1/loans/{loanId}/guarantors/{guarantorId}?command=approve

Result

Reject Guarantor

POST https://localhost:8443/fineract-provider/api/v1/loans/{loanId}/guarantors/{guarantorId}?command=reject

Result

Changes Made

Included the associated clientId in the event payload generated during guarantor approval.
Included the associated clientId in the event payload generated during guarantor rejection.
Enabled the SMS notification framework to correctly resolve the client and generate outbound SMS notifications for both workflows.
Validation

Verified that both APIs now generate events containing the associated clientId, allowing the SMS notification pipeline to execute successfully.

Event Payload

[fynmanoj]

we dont need to create these