Aman-Mittal commented on issue #302: URL: https://github.com/apache/fineract-backoffice-ui/issues/302#issuecomment-5227767216
> Hi [@Aman-Mittal](https://github.com/Aman-Mittal) , AI suggested this , does it look plausible ? or worth trying ? > > Step-by-Step Implementation Guide Locate the Target File > > Open src/app/features/reporting/run-report.component.ts. > > Find where reportType is retrieved from the query parameters (around line 250) and where output rendering occurs (around line 308). > > Implement Type Dispatching > > Refactor the execution handler to check the report type instead of hardcoding HTML rendering: > > Table / SMS: Retain the current tabular HTML rendering logic. > > Chart: Pass the dataset/series to the reusable chart components located in src/app/shared/components/charts. > > Pentaho / BIRT: Trigger the file export request. > > Integrate the Download Adapter > > Import and use the dedicated DOWNLOAD adapter from src/app/core/adapters (per architectural decision record ADR-0003). > > Rule: Do not use window.open or create dynamic tags in the DOM directly, as this will fail linting. > > Map Pentaho Parameters > > Check parameter formatting for Pentaho-style reports. Verify parameter keys against a running backend instance or API specification, as parameter names often differ from tabular reports. > > Add Failure Notifications > > Ensure any download or rendering error displays a visible error toast or message to the user rather than failing silently. Yes, this looks like a reasonable implementation approach and is aligned with the scope of #302. A couple of things I'd suggest verifying before implementation: Confirm the actual reportType values returned by the backend rather than assuming the strings in the issue. Check the actual response shape for Chart reports and map it to the existing chart components under shared/components/charts. For Pentaho/BIRT, verify the expected output type/content type and parameter naming against a running Fineract instance. Parameter discovery itself is part of #300 and should remain out of scope here; #302 should consume the parameter infrastructure from #300 and only handle any report-type-specific mapping required for execution. Keep the existing CSV flow unchanged apart from regression coverage. The DOWNLOAD adapter approach is definitely the right direction, since the issue explicitly calls for that boundary. I'd suggest starting with the existing run-report.component.ts, inspecting the API response for each report type, and then implementing the dispatch + tests incrementally. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
