You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Tofunmi Oguntibeju <pa...@gmail.com> on 2026/09/11 22:16:00 UTC
[Fineract] Three Postgres-only defects blocking GLIM, GSIM, and centre collection sheet in fineract-backoffice-ui
Hi all,
While closing out functional gaps for the Fineract backoffice UI (#375
<https://github.com/apache/fineract-backoffice-ui/issues/375>), I probed
three group-lending/savings operations against apache/fineract:latest (
1.15.0-303-gf4f927e, built 2026-08-15) on a fresh PostgreSQL-backed
instance, as the default superuser with ALL_FUNCTIONS. All three failed.
Full write-up with request/response bodies is in #376
<https://github.com/apache/fineract-backoffice-ui/issues/376>; summary
below.
*1. GLIM (group loan individual monitoring)* — POST /v1/loans with loanType:
"glim" passes validation but fails at insert time: ERROR: null value in
column "principal_amount" of relation "glim_accounts" violates not-null
constraint. The API surfaces this as 403
error.msg.unknown.data.integrity.issue. The alternate clientMembers payload
shape is rejected outright as unsupported, so there's no working request
shape currently.
*2. GSIM (group savings individual monitoring)* — POST
/v1/savingsaccounts/gsim returns 200 with gsimId: 0. Individual savings
accounts get created for the named clients, but no parent GSIM record
forms, and GET /v1/groups/{id}/gsimaccounts stays empty afterward.
*3. Centre collection sheet* — POST
/v1/centers/{id}?command=generateCollectionSheet returns a 500: operator
does not exist: boolean = integer, from what looks like an
unconditional ls.completed_derived
= 0 comparison — valid on MySQL, not on Postgres. This fails for every
tenant/dataset on Postgres, regardless of data. The existing *individual*
collection sheet endpoint is unaffected.
Before I file JIRA tickets for these (and before we build any UI on top,
since none of the three are currently usable), I wanted to check: are any
of these already known or fixed on a newer build than the one I tested a
few weeks ago? Happy to re-verify against a specific tag/commit if there's
a more current one to test, and to file JIRA + link back to #376
<https://github.com/apache/fineract-backoffice-ui/issues/376> once
confirmed.
Thanks,
Tofunmi
Re: [Fineract] Three Postgres-only defects blocking GLIM, GSIM, and centre collection sheet in fineract-backoffice-ui
Posted by James Dailey <ja...@gmail.com>.
+1 for your efforts
To my knowledge no one has worked on this
On Fri, Sep 11, 2026 at 3:16 PM Tofunmi Oguntibeju <pa...@gmail.com>
wrote:
> Hi all,
>
> While closing out functional gaps for the Fineract backoffice UI (#375
> <https://github.com/apache/fineract-backoffice-ui/issues/375>), I probed
> three group-lending/savings operations against apache/fineract:latest (
> 1.15.0-303-gf4f927e, built 2026-08-15) on a fresh PostgreSQL-backed
> instance, as the default superuser with ALL_FUNCTIONS. All three failed.
> Full write-up with request/response bodies is in #376
> <https://github.com/apache/fineract-backoffice-ui/issues/376>; summary
> below.
>
> *1. GLIM (group loan individual monitoring)* — POST /v1/loans with loanType:
> "glim" passes validation but fails at insert time: ERROR: null value in
> column "principal_amount" of relation "glim_accounts" violates not-null
> constraint. The API surfaces this as 403
> error.msg.unknown.data.integrity.issue. The alternate clientMembers
> payload shape is rejected outright as unsupported, so there's no working
> request shape currently.
>
> *2. GSIM (group savings individual monitoring)* — POST
> /v1/savingsaccounts/gsim returns 200 with gsimId: 0. Individual savings
> accounts get created for the named clients, but no parent GSIM record
> forms, and GET /v1/groups/{id}/gsimaccounts stays empty afterward.
>
> *3. Centre collection sheet* — POST
> /v1/centers/{id}?command=generateCollectionSheet returns a 500: operator
> does not exist: boolean = integer, from what looks like an unconditional ls.completed_derived
> = 0 comparison — valid on MySQL, not on Postgres. This fails for every
> tenant/dataset on Postgres, regardless of data. The existing *individual*
> collection sheet endpoint is unaffected.
>
> Before I file JIRA tickets for these (and before we build any UI on top,
> since none of the three are currently usable), I wanted to check: are any
> of these already known or fixed on a newer build than the one I tested a
> few weeks ago? Happy to re-verify against a specific tag/commit if there's
> a more current one to test, and to file JIRA + link back to #376
> <https://github.com/apache/fineract-backoffice-ui/issues/376> once
> confirmed.
>
> Thanks,
> Tofunmi
>