Hi Adam,
Thank you for clarifying the expected behavior!
I have investigated the backend workflow and identified exactly why the API is
crashing when hitting the report endpoint without parameters. I will pick this
up, work on implementing the fallback to the current user's office ID as
requested, and provide the fix.
I will update the ticket (FINERACT-1556) shortly with the full details of my
investigation and the proposed fix.
Best regards,
Akhilesh Chekare
On 2026/06/29 13:33:21 Ádám Sághy wrote:
> Hi
>
> Thank you for raising this issue. What should have happened: ${officeId}
> resolved to current user’s office id.
>
> Can you debug and fix this issue?
>
> Regards
> Adam
>
> > On Jun 28, 2026, at 8:05 AM, akhilesh chekare <[email protected]> wrote:
> >
> > Hi Team,
> >
> > I've been investigating the backend workflow triggered by the
> > /runreports/{reportName} GET API to determine the root cause of the
> > org.postgresql.util.PSQLException: ERROR: syntax error at or near "$" error.
> >
> > I found that the issue occurs when the API evaluates the report's SQL
> > template but the user request is missing required parameters (e.g.,
> > ?R_officeId=1). Because Fineract's query builder wasn't failing fast on
> > missing parameters, it simply left the un-substituted placeholder (like
> > ${officeId}) as a literal string in the SQL and sent it directly to
> > PostgreSQL. Postgres cannot parse the raw $ character in a standard query,
> > causing it to throw the syntax error, which Fineract then unfortunately
> > wraps in a confusing 403 Data Integrity Error.
> > Additionally, the same crash occurs when the UI calls the endpoint with
> > ?template=true to fetch the report metadata, because the API ignores this
> > flag and attempts to execute the report without parameters anyway.
> >
> > Proposed Fix: I have a fix ready for this. It involves updating the query
> > preparation logic in ReadReportingServiceImpl to properly validate missing
> > parameters and immediately return a standard HTTP 400 Bad Request before
> > the query ever hits the database. I've also added a short-circuit for the
> > template=true flag so it safely extracts and returns the parameter metadata
> > JSON as the UI expects, bypassing database execution entirely.
> > I have briefly commented on the ticket (FINERACT-1556) as well. Please let
> > me know whether I should go ahead and pick this up and submit the PR! Any
> > further advice would be a great help.
> >
> > Thank you,
> > Akhilesh Chekare
>
>
