Loan API Version Updated to 48

  • Updated

Loan API Version Updated to 48

Overview

For a class that needs to use the latest features of Salesforce, the API version needs to be updated. To implement the Salesforce security recommendations, as part of the Oxygen release, the API version of the Apex classes in CL Loan is now updated to 48.0. After the update, you will be able to add the Field Level Security (FLS) to queries without changing it to a dynamic query. This requires that the CL Loan application uses Salesforce in the Lightning Experience mode. All the tabs and pages in CL Loan and all the dependent packages must be compatible with the Salesforce in Lightning Experience mode.

Salesforce Security Review

The Salesforce security team conducts rigorous reviews of all products before publicly listing them on AppExchange. Ensuring that all products go through security review means that customers can feel confident in knowing that any AppExchange offering provides the highest level of data protection.

Salesforce requires all AppExchange to pass a security review before listing on the AppExchange. The obvious aim is to develop a culture of trust, by ensuring that all apps meet a set of security standards and other best practices. Failure to pass the Salesforce security review could lead to major time delays and extra efforts to make the required changes before the app may be rolled out.

Upgrades Done by CL Loan

To pass these security reviews, the following upgrades have been done to the Oxygen release of CL Loan:

Field-Level Security (FLS) Added

Salesforce allows developers and administrators to control access to data at the field level. Field-level security (FLS) allows administrators to define the profiles that can see and write to most fields of standard and custom objects. As part of the security review, Salesforce has recommended adding field-level security to all the queries.

To ensure that field-level securities are added, CL Loan has added the WITH SECURITY_ENFORCED keyword to all the static queries. 

This keyword enables Salesforce to validate if fields and objects being queried are READ accessible by the user who is performing an action. If not accessible, then it displays the following error message: "Insufficient permissions and action is terminated." The action could be running an SOD/EOD job, rescheduling, or contract creation. It could be anything that involves a loan code.

For example, after adding the WITH SECURITY_ENFORCED keyword, when you run a process such as a job or an API, and if certain fields do not have the READ access granted to the profile in which these processes are running, then the process fails with the following error message getting displayed:  "Inaccessible field being queried."

Example

Let us say a user profile does not have the READ permission for the Next_Installment_Date__c field, and this user reschedules a loan contract and executes the following query:

Query

SELECT Id, Name, Next_Installment_Date__c from Loan_Account__c WITH SECURITY_ENFORCED

The system then displays an error message and the rescheduling fails.

Impact of this Upgrade

When you upgrade to Oxygen, the business processes may display a field inaccessible error if the given profile does not have read access to those fields.

Upgrade Steps

Add the required field permissions to the required profiles.

To add the READ permissions to the managed fields, perform the following steps:

  1. Run the following script by passing the profile ID with which the SOD/EOD job is run to give the field-level READ permission to that profile.

    Note:

    An administrator profile can run these scripts to give the Read permission to a profile.

    Script to add READ permissions
    loan.MarkFieldsAccessibleJob job = new loan.MarkFieldsAccessibleJob(profileId); //where profileId is of Id type
Database.executeBatch(job);

    Important Information Related to the Script

    • This script adds READ permissions to ALL THE MANAGED fields of loan, common, utility, and filegen packages if not already present.

    • This script does NOT add permissions to the following:

      • Custom fields and custom objects

      • Standard fields and standard objects

    • This adds permissions to the Account and the Contact objects if not present.

    • The job that marks the managed fields as accessible is a global job that is part of the CL Loan package. If you want to add the READ permissions to your custom fields, then you have to write your own code as you cannot make changes to this job.

  2. Check the other profiles. For example, a guest user profile, that runs the processes or the custom codes that use the Loan APIs or Jobs. Then either run the script for each of the required profiles. Or check each field, and then add permissions to the required fields. Alternatively, you can run the script for all the profile IDs, and then remove the access for the fields that do not require the permissions.

  3. Run thorough tests in the org.

    The test areas are EOD/SOD jobs and the business processes that invoke the CL Loan APIs and Jobs for all the profiles that are being used.

    Note:

    • Field permissions must be added to the profile that runs EOD/SOD jobs.

    • All business processes that invoke the CL Loan APIs such as the global APIs, REST APIs, and Webservices must be tested for all profiles that are being used. If an error is generated, then add the field permissions to that profile. 

    • Custom fields and custom objects will not cause to display any error even if the read permissions are not added to them because they are not referred to or used in the CL Loan product. 

    Important

    Running the above script for a given profile ID adds the READ permission to all the managed fields and objects. If the profile ID is not of an administrator, and if the data should not be visible to all the other user profile IDs, then add the sharing rules (Salesforce-related sharing settings) to not allow the records to be seen by the users.

    For example, if you do not want a loan officer to view the data, then you can add sharing rules to not allow the loan officer to view the records. If the sharing rules are not added for the loan officer, then on running the preceding script, the loan officer will be able to view all the data.

API Version updated to 48.0

Each Apex class has a corresponding metadata file that contains the information about the API version that is used by that class. If a class needs to use the latest features of Salesforce, then this API version needs to be updated.

To implement the Salesforce security recommendations, and so to be able to add the WITH SECURITY_ENFORCED keyword, the API version of the apex classes in CL Loan are updated to 48.0. This change has resulted in certain behavioral changes in the apex code which is explained in the example given further.

Impact of this Upgrade

After you upgrade to Oxygen, while using the following loan APIs, you may get an error indicating that the field is not queried.

Affected Global Classes

The API classes that are affected by this update include both the public and the global classes.

The global classes that are affected by this update are listed as follows:

Global Class

Methods

AbstractInvestorPayout
  • setPriorityForIO
  • splitPrincipal
  • splitInterest
  • splitFees
  • splitInterestComponent
  • updateLoanInvestor
AbstractLoanActions
  • addNewCollateralLiens
  • changeAppraisedValueOfCollateral
  • reverseRescheduleAction
AccrualMaintainenceUtil
  • stopAccrual
  • stopAccrualForLoans
BalanceSnapshotUnit
  • retrieveLoanAccountFromDisbursal
  • retrieveLoanAccountFromSnapshot
  • retrieveLoanAccountFromSnapshotWithMaturity
  • retrieveLoanAccountFromOTxnSnapshot
BrokerCommissionHierarchyUtil
  • calculateCommissionForBrokerHierarchy
  • getBrokerAccountHierarchy
  • getBrokerAccountHierarchyWithCommission
  • getBrokerAcctHierarchyWithCommByProduct
  • getCommissionPlanHierarchy
  • getCommissionPlanHierarchyByProduct
FeeUtil
  • computeFee
  • calcTotalFeeForASet
  • splitPaidAmountAmongFees
GlobalLoanUtilFacade
  • calculateRepaymentSchedule
GlobalProcessFacade
  • moveDayAheadByNDaysStartedToStarted
  • moveDayAheadEndedToEnded
  • moveDayAheadStartedToStarted
  • moveDayBackByNDaysStartedToStarted
  • runEndOfDay
  • runStartOfDay
  • setUsersDateAndBranch
InterestCalc
  • calcSI
  • calcSIWithRounding
  • calcUnpaidSIAmzBasedLoan
LoanDisbursalActionAPI
  • disburseLoanAccount
  • LoanDisbursalActionAPI(Loan_Disbursal_Transaction__c loanDisbTxn)
  • LoanDisbursalActionAPI(Loan_Disbursal_Transaction__c loanDisbTxn, List<Disbursal_Txn_Distribution__c> dtds)
LoanRefinanceAction
  • createRefinanceTransactions
  • settleAllRefinanceTransaction
  • validateRefinanceTxn
LoanTransactionUtil
  • getAccrualBaseMethodCode
  • getInterestTillDate
  • getRoundedAmount
  • getTotalOutstandingBalance
  • interestBearingDelinquencyLogic
  • postInterestTillDate
  • updateFeesRemaining
PayoffQuote
  • addPayOffCharges
  • getPayoffAmount
  • getPayoffAmount
  • getPayoffAmountExcludeCharges
  • postPayoffQuote
RepaymentScheduleUtil
  • getRepaymentSchedule
  • getRepaymentScheduleSummary
  • getRepaymentScheduleSummary
Note:
  • The impact is only on the preceding CL Loan global APIs listed, and not all the APIs.
  • APIs such aswaiveAdditionalInterestwhereIdis passed as a parameter are not impacted, but APIs such asgetPayoffAmount whereLoan_Account__cis passed as an object are impacted if the required fields of Loan_Account__care not queried.
Example
Let us consider a field in the CL Loan code, such as Next_Installment_Date__c, that is not queried, and is referenced in a logical function such as in the following if condition:
if(loan.Next_Installment_Date__c == ‘2013-01-01’)
Without the update to 48.0, the system considers this field as having a null value. But with the update to 48.0, the same logic now displays an error message indicating that the field is not queried. This helps in identifying the fields that are not queried and hence adding them.
Upgrade Steps
To add the fields that are not queried, perform the following steps:
  1. Review all the CL Loan global APIs in your code.
  2. Test the APIs by running the code.
  3. If the system displays an error message that the fields are not queried, then add those fields in the queries, and then test the API again.
Note:
If you are using any of the preceding classes and methods listed, then test the part of the code that is calling this global API.
Inherit Sharing Added to all the Classes
In Salesforce, you can control access to data at many different levels. For example, you can control the access your users have to objects with object permissions. Within objects, you can control the access users have to fields using field-level security. To control access to data at the record level, use sharing settings.
There are three sharing attributes applied to a class to control whether all or some records are accessible to the user who is performing an action:
  • With sharing: Indicates that the security sharing setting is enforced for the current user of the class. 
  • Without sharing: Indicates that the security sharing setting is not enforced for the current user to the accessing class. 
  • Inherited sharing: Indicates that the security settings of the class inherit the sharing setting of the caller class.
As part of the security review, Salesforce has suggested the addition of theinherited sharingkeyword to the CL Loan classes.
Using with sharing, limits you to a few or no actions. For example, let us say that a non-administrator user has to perform a rescheduling action for a contract. This action depends on certain configuration details such as the lending product information, floating rate indices, and more. These configurations are not visible to a non-administrator user as per the business requirement. Adding the with sharing to the rescheduling action class applies the user’s security sharing setting to the code, and so the code will not be able to access the configuration data. Thus the rescheduling action will not function properly. To fix this, we may have to give the non-administrator users unprivileged access to the configuration data.
Using the inherited sharing attribute enables you to pass the AppExchange Security Review and ensure that your privileged Apex code is not used in unexpected or insecure ways.
To pass the security review and to avoid unprivileged access to the code, CL Loan has added the inherited sharing to its Apex classes, and to avoid any unexpected results, the CL Loan APIs must derive its security sharing settings from the custom class. This means that you have to add the without sharing to all the custom classes that use the CL Loan APIs.
Thus, the following upgrades have been made by CL Loan:
  • Addedwithout sharing to all the loan jobs, including dynamic and non-dynamic jobs.
  • Added inherited sharing to all the classes except the jobs. These classes include job handlers, trigger handlers, global APIs, web services, and more.
Note:
To set up the sharing policies, use the sharing settings at the org level
Impact of this Upgrade
Business processes may give unexpected results because all the records are not retrieved.
Upgrade Steps
To avoid any unexpected results due to this upgrade, perform the following steps:
  1. Add the without sharing keyword to all the custom classes that use the CL Loan APIs.
  2. For all the profiles, test the jobs, workflows, and all the guest user actions that are to be performed.
Note:
If you do not add any sharing attribute to a custom class, then the system, by default, considers it as with sharing for the CL Loan API that inherits the security sharing setting of this custom class. And so when you do not add without sharing, then if the API is using the configuration data, the API would fail to process the data because that data would not be accessible to the code.

 
          
        

      

 
      
 
      

        
          

        
        
      

 
    

  
    
    

      
      

                
In This Article