FINERACT-2481: Remove Pentaho reports from initial sample data

[AshharAhmadKhan]

Remove deprecated Pentaho reports from initial sample data

Description

This PR removes all deprecated Pentaho report and permission entries from the initial sample data SQL files used by new Apache Fineract installations.

Pentaho is being phased out in favor of newer reporting mechanisms. Keeping these entries in sample data provides no value and introduces legacy artifacts into fresh deployments.

This change is intentionally limited to initial data only and does not affect runtime behavior or existing installations.

Changes

• Removed 27 Pentaho-related permission entries from the m_permission table
• Removed 43 Pentaho report entries from the stretchy_report table
• Applied changes consistently to:
  • barebones_db.sql
  • load_sample_data.sql

Impact & Risk Analysis

• No impact on existing installations
  • No schema changes
  • No database migrations
  • No deletions on live databases
• No foreign key violations
  • Verified that m_report_mailing_job contains zero rows referencing stretchy_report
• Scope strictly limited to initial data for new deployments

Verification

# Confirmed no remaining Pentaho references
grep -c "Pentaho" barebones_db.sql        # 0
grep -c "Pentaho" load_sample_data.sql   # 0

Checklist

• Commit message follows project guidelines
• Build passes (no code or runtime changes)
• Tests N/A – static SQL sample data only
• API/Swagger updates N/A – no API or behavior changes
• PR size within project limits

Addresses FINERACT-2481

[IOhacker]

@AshharAhmadKhan I think that it is better to add a new liquibase migration file, so then we can track the historical changes

[IOhacker]

Kindly see my comments

[AshharAhmadKhan]

@IOhacker Thank you for the feedback! I've updated the PR to include a Liquibase migration file as requested.

Changes made:

• ✅ Added migration file: 0210_remove_pentaho_reports.xml
• ✅ Included in changelog-tenant.xml
• ✅ Deletes 26 Pentaho permission entries from m_permission table
• ✅ Deletes 44 Pentaho report entries from stretchy_report table
• ✅ Kept the sample data changes for new installations

The Liquibase migration ensures existing installations are cleaned up, while the sample data changes prevent new installations from including these legacy Pentaho entries.

Ready for re-review!

[IOhacker]

@AshharAhmadKhan run ./gradlew :spotlessApply and squash and commit your changes (only 1 commit per PR)

[IOhacker]

Exclude the sample_data sql files from this PR

[AshharAhmadKhan]

@IOhacker Updated as requested!

Changes made:
✅ Removed sample_data SQL files (barebones_db.sql and load_sample_data.sql)
✅ Kept only Liquibase migration approach
✅ Single commit with GPG signature
✅ Spotless applied successfully
✅ Used explicit report names in migration (26 permissions + 44 reports)

The migration now handles:

• Child table deletion first (stretchy_report_parameter)
• Explicit listing of all 26 Pentaho permission codes
• Explicit listing of all 44 Pentaho report names
• PreConditions for idempotent execution
• Cross-database compatibility with LOWER() functions

Ready for review!

[AshharAhmadKhan]

@IOhacker Rebased onto latest develop and renamed migration to 0211_remove_pentaho_reports.xml to avoid conflict with the recently merged 0210. Ready for re-review!

[adamsaghy]

@AshharAhmadKhan Please rebase the PR.

[adamsaghy]

@AshharAhmadKhan @IOhacker I am having concerns here...

I dont think we should remove blindly the permissions, the role permissions and the reports as well.

I think the story is rather aiming to not add the stretchy_reports and the permissions and role permissions in the 1st place (remove them from the liquibase scripts).

Creating new liquibase scripts which explicitly deletes them would harm any installations who is in fact using pentaho reports... we should not do that.

@IOhacker What do you think?

[AshharAhmadKhan]

Thanks for the clarification.
I see your point about avoiding destructive migrations that could impact existing deployments.
I’m happy to adjust the approach accordingly, please share your preferred direction.

[IOhacker]

Hello @adamsaghy we are going to stop the maintenance of Pentaho reports. This is because over two years the access to the Pentaho libraries have been restricted. The Pentaho Plugin will be in maintenance mode for the rest of the year (I have been updating the Fineract libraries - the reason that I have set the Github actions in another repository --- ) but it is not possible to continue to support them. Instead of that we will use Eclipse BIRT. But we are not going to to touch this data. If this change is not possible to be done here then it will be done in the Plugin repository. But seems contradictory to keep Pentaho reports if the Apache Fineract doesn't support them.

[adamsaghy]

Hello @adamsaghy we are going to stop the maintenance of Pentaho reports. This is because over two years the access to the Pentaho libraries have been restricted. The Pentaho Plugin will be in maintenance mode for the rest of the year (I have been updating the Fineract libraries - the reason that I have set the Github actions in another repository --- ) but it is not possible to continue to support them. Instead of that we will use Eclipse BIRT. But we are not going to to touch this data. If this change is not possible to be done here then it will be done in the Plugin repository. But seems contradictory to keep Pentaho reports if the Apache Fineract doesn't support them.

I am not saying to keep them. I am merely recommending to remove them from the initial (existing) liquibase scripts, instead of creating new liquibase scripts which deletes them.

The difference is with the 1st option, anyone who is using them, not bothered, but new deployments will not have it.
The 2nd option is explicitly removing for existing deployments too, which i dont find necessary.

The end result for both of them is the same, but less destructive.

What do you think?

[AshharAhmadKhan]

@adamsaghy @IOhacker —thank you both for the feedback.
I've updated the PR to follow @adamsaghy's approach: removing the Pentaho entries directly from the existing initial data scripts (0002_initial_data.xml and 0003_postgresql_specific_initial_data.xml) rather than creating a new deletion migration. I prefer this approach since it avoids any risk of harming existing installations that may still rely on these reports.

[adamsaghy]

You need to set a "new" valid checksum since existing changesets were changed.

Also since you are touching these files, please fix the "falsee" value to "false" ;)

[AshharAhmadKhan]

@adamsaghy @IOhacker Updated! Changes made:

✅ Removed all 121 Pentaho references from initial data (0002 & 0003 files)
✅ Fixed 52 instances of "falsee" → "false" typo
✅ Added validCheckSum="ANY" to modified changeSets (id=24, 41-mysql, 1-postgresql)

Total changes: -1,359 lines, +95 lines
Impact: New deployments get clean data, existing deployments unaffected

Ready for review!

[adamsaghy]

@AshharAhmadKhan Please rebase with latest develop branch. Hopefully the failed checks goes away after!

[AshharAhmadKhan]

@adamsaghy Rebased with latest develop! ✅

Picked up 10 new upstream commits.
Branch is now up-to-date and ready for CI approval.