FINERACT-2067: (doc) fix some typos in fineract-doc module.

2024-03-19 13:42:45 +01:00
parent d955bc26cb
commit 6b94192ac6
19 changed files with 30 additions and 30 deletions
@@ -258,7 +258,7 @@ The business step configuration for jobs are tracked within the database in the
 == Inline Jobs

 Some jobs that work with business entities have a corresponding job that can trigger the job with a list of specified entities.
-When the Inline job gets triggered then then the corresponding existing job will run in real time with the given entities as a dataset.
+When the Inline job gets triggered then the corresponding existing job will run in real time with the given entities as a dataset.

 === List of Inline jobs

@@ -175,7 +175,7 @@ The - logical - date of the actual business day, eg: 2022-05-06

 The - logical - date of the business day for job execution, eg: 2022-05-05

-* It can be calculated based on the the business date
+* It can be calculated based on the business date

 ** COB date = business date - 1 day

@@ -295,4 +295,4 @@ We shall modify at all the relevant places where the tenant date was used:

 ** Storing DATETIME fields without Timezone is potential problem due to the daylight savings

-** Also  some external libs (like Quartz) are using system timezone and Fineract will using Tenant timezone for audit fields. To be able to distinct them in DB we shall use DATETIME with TIMESTAMP column types and use timezoned java time objects in the application
+** Also, some external libs (like Quartz) are using system timezone and Fineract will using Tenant timezone for audit fields. To be able to distinct them in DB we shall use DATETIME with TIMESTAMP column types and use timezoned java time objects in the application
@@ -11,7 +11,7 @@ Taking into account example shown above for the *users* resource.
 * HTTPS API: retrieveAll method on *org.apache.fineract.useradministration.api.UsersApiResource* invoked
 * UsersApiResource.retrieveAll: Check user has permission to access this resources data.
 * UsersApiResource.retrieveAll: Use 'read service' to fetch all users data ('read services' execute simple SQL queries against Database using JDBC)
-* UsersApiResource.retrieveAll: Data returned to coverted into JSON response
+* UsersApiResource.retrieveAll: Data returned to converted into JSON response
 * Command: POST /users (Note: data passed in request body)
 * HTTPS API: create method on org.apache.fineract.useradministration.api.UsersApiResource invoked

@@ -21,7 +21,7 @@ Taking into account example shown above for the *users* resource.
 include::{rootdir}/fineract-provider/src/main/java/org/apache/fineract/useradministration/api/UsersApiResource.java[lines=168..188]
 ----

-.Create a CommandWrapper object that represents this create user command and JSON request body. Pass off responsiblity for processing to PortfolioCommandSourceWritePlatformService.logCommandSource
+.Create a CommandWrapper object that represents this create user command and JSON request body. Pass off responsibility for processing to PortfolioCommandSourceWritePlatformService.logCommandSource
 [source,java]
 ----
 include::{rootdir}/fineract-core/src/main/java/org/apache/fineract/commands/service/PortfolioCommandSourceWritePlatformServiceImpl.java[lines=69..129]
@@ -36,7 +36,7 @@ include::{rootdir}/fineract-core/src/main/java/org/apache/fineract/commands/serv
 NOTE: if a RollbackTransactionAsCommandIsNotApprovedByCheckerException occurs at this point. The original transaction will of been aborted and we only log an entry for the command in the audit table setting its status as 'Pending'.

 * Check that if maker-checker configuration enabled for this action. If yes and this is not a 'checker' approving the command - rollback at the end. We rollback at the end in order to test if the command will pass 'domain validation' which requires commit to database for full check.
-* findCommandHandler - Find the correct Hanlder to process this command.
+* findCommandHandler - Find the correct Handler to process this command.
 * Process command using handler (In transactional scope).
 * CommandSource object created/updated with all details for logging to 'm_portfolio_command_source' table.
 * In update scenario, we check to see if there where really any changes/updates. If so only JSON for changes is stored in audit log.
@@ -11,7 +11,7 @@ Fineract was an idea born out of a wish to create and deploy technology that all

 == Timeline

-* 2006: Project intiated by Grameen Foundation
+* 2006: Project initiated by Grameen Foundation
 * Late 2011: Grameen Foundation handed over full responsibility to open source community.
 * 2012: Mifos X platform started. Previous members of project come together under the name of Community for Open Source Microfinance (COSM / OpenMF)
 * 2013: COSM / OpenMF officially rebranded to Mifos Initiative and receive US 501c3 status.
@@ -63,7 +63,7 @@ Fineract has been developed for 10+ years by the community and unfortunately the

 As for every system, the database structure will and need to evolve over time. Fineract is no different. Originally for Fineract, Flyway was used until Fineract 1.6.x.

-After 1.6.x, PostgreSQL support was added to the platform hence there was a need to make the data-access layer and the schema migration as database independent as possible. Becuase of that, from Fineract 1.7.0, Flyway is not used anymore but Liquibase is.
+After 1.6.x, PostgreSQL support was added to the platform hence there was a need to make the data-access layer and the schema migration as database independent as possible. Because of that, from Fineract 1.7.0, Flyway is not used anymore but Liquibase is.

 Some of the changesets in the Liquibase changelogs have database specifics into it but they only run for the relevant databases. This is controller by Liquibase contexts.

@@ -86,13 +86,13 @@ The switch from Flyway (1.6.x) to Liquibase (1.7.x) was planned to be as smooth

 1. During upgrade from Fineract 1.5.0 to 1.6.0, Liquibase fails

-After dropping the flyway migrations table (schema_version), Liquibase runs it's
-own migrations which fails (in recreating tables which already exisit) because
+After dropping the flyway migrations table (schema_version), Liquibase runs its
+own migrations which fails (in recreating tables which already exist) because
 we are aiming to re-use DB with existing data from Fineract 1.5.0.

 Solution: The latest release version (1.6.0) doesn't have Liquibase at all, it
 still runs Flyway migrations. Only the develop branch (later to be 1.7.0) got
-sqitched to Liquibase. Do not pull the develop before upgrading your instance.
+switched to Liquibase. Do not pull the develop before upgrading your instance.

 Make sure first you upgrade your instance (aka database schema with Fineract 1.6.0).
 Then upgrade with the current develop branch. Check if some migration scripts
@@ -21,15 +21,15 @@ The platform uses an approach that isolates an FIs data per database/schema (See

 Whilst each tenant will have a set of core tables, the platform tables can be extended in different ways for each tenant through the use of Data tables functionality.

-== Command Query Seperation
+== Command Query Separation

-We seperate *commands* (that change data) from *queries* (that read data).
+We separate *commands* (that change data) from *queries* (that read data).

 Why? There are numerous reasons for choosing this approach which at present is not an attempt at full blown CQRS. The main advantages at present are:

 * State changing commands are persisted providing an audit of all state changes.
 * Used to support a general approach to *maker-checker*.
-* State changing commands use the Object-Oriented paradign (and hence ORM) whilst querys can stay in the data paradigm.
+* State changing commands use the Object-Oriented paradigm (and hence ORM) whilst querys can stay in the data paradigm.

 == Maker-Checker

@@ -14,5 +14,5 @@ Financial institutions deliver their services to customers through a variety of

 As illustrated in the above diagram, the various stakeholders leverage business apps to perform specific customer or FI related actions. The functionality contained in these business apps can be bundled up and packaged in any way. In the diagram, several of the apps may be combined into one app or any one of the blocks representing an app could be further broken up as needed.

-The platform is the core engine of the MIS. It hides alot of the complexity that exists in the business and technical domains needed for an MIS in FIs behind a relatively simple API. It is this API that frees up app developers to innovate and produce apps that can be as general or as bespoke as FIs need them to be.
+The platform is the core engine of the MIS. It hides a lot of the complexity that exists in the business and technical domains needed for an MIS in FIs behind a relatively simple API. It is this API that frees up app developers to innovate and produce apps that can be as general or as bespoke as FIs need them to be.