FINERACT-2481: Remove Pentaho reports from initial data

[Kenzy-Ragab]

Description

This PR removes 44 legacy Pentaho report entries from the initial system data to clean up the reporting metadata.

Changes Proposed

• New Migration: Added 0210_remove_pentaho_legacy_data.xml.
• Surgical Cleanup: Explicitly listed 44 reports in m_report_parameter and stretchy_report for targeted removal.
• Permission Cleanup: Removed associated permissions in m_permission using pattern matching.
• Integrity: Deletion order follows (Child -> Parent) to respect Foreign Key constraints.

Impact

• Database: Cleaner initial state without obsolete metadata.
• UI: Removed deprecated Pentaho reports and permissions from management screens.

Checklist

• Migration ID follows sequential order (0210).
• Deletion order respects Foreign Key constraints.
• Explicit naming used for reports for maximum safety.

[IOhacker]

Hello, the PR is only about the data. Please remove the non required java class and don't include any sample_data sql file. #5491

The PR must be signed and the title must folllow the convention.

[Kenzy-Ragab]

Hi @IOhacker, thank you for the feedback. I understand the requirement now. I will revert the Java changes and the sample data SQL files, keeping only the Liquibase migration for the data cleanup. I will also ensure the commit is signed and the PR title follows the convention. I'll push the updates shortly.

[IOhacker]

All committers already have PGP/GPG keys, so just make sure you're also signing commits. You can add this to your ~/.gitconfig (or equivalent) to do it automatically: [commit] gpgSign = true Upload your public key to github <https://github.com/settings/keys> to make the verified badges green. More info: FINERACT-2177 <https://issues.apache.org/jira/browse/FINERACT-2177>, PR #5431 <#5431>. Hints: 1) try it locally before pushing. 2) have git run it for you: Create .git/hooks/pre-push with: #!/bin/sh scripts/verify-signed-commits.sh --strict Be sure to make that script executable. El dom, 15 feb 2026 a las 13:25, Kenzy Ragab ***@***.***>) escribió:

…

*Kenzy-Ragab* left a comment (apache/fineract#5501) <#5501 (comment)> Hi @IOhacker <https://github.com/IOhacker>, thank you for the feedback. I understand the requirement now. I will revert the Java changes and the sample data SQL files, keeping only the Liquibase migration for the data cleanup. I will also ensure the commit is signed and the PR title follows the convention. I'll push the updates shortly. — Reply to this email directly, view it on GitHub <#5501 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALD2ZAQONZN7W4QLJFJVNFL4MDB3RAVCNFSM6AAAAACVGA6F72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMBVGA2DIMJVGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Kenzy-Ragab]

Hi @IOhacker, I have updated the PR according to your feedback.
Reverted Java changes and sample data SQL files (kept only Liquibase migration).
Updated the commit message to follow the convention.
Signed the commit with GPG (it should show as Verified now).
Ready for your review!

[IOhacker]

@Kenzy-Ragab I suggest to update the PR description. The SQL I think that could be more explicit about the report names.

[Kenzy-Ragab]

Hi @IOhacker,

Thank you for the guidance. I'm currently refining the SQL to be more explicit as requested. However, I have a quick architectural question before I push the final list:

Given that we have over 40+ Pentaho-related entries (between reports and permissions), listing them all explicitly in the IN clause will make the Liquibase script quite lengthy and harder to maintain if any similar legacy data is found later.

What do you think of this balanced approach?

• Use the Pattern for permissions: LIKE 'READ_%_PENTAHO' (since they all follow this unique naming convention).
• Use the Category for reports: report_category = 'Pentaho'.
• I will add a detailed XML comment above the changeSet listing the major reports being removed as a reference for future developers.

This keeps the code clean and DRY while remaining explicit about the target group. Or would you prefer every single report name to be hardcoded in the script for maximum safety?

[IOhacker]

@Kenzy-Ragab my request about explicit setting the name of the Pentaho report is because the DB could have another custom reports with PENTAHO in its name.

[Kenzy-Ragab]

@IOhacker Got it! That makes total sense to avoid accidental deletion of custom reports. I have compiled the explicit list of the 44 core reports and updated the migration accordingly. Pushing the changes now.

[Kenzy-Ragab]

Hi @IOhacker, I have updated the migration with the explicit list of 44 reports and handled the permissions as discussed. I see some CI failures; could you please check if these are related to existing tests depending on this legacy data, or if it's an environment issue? Thank you for your patience!

[Kenzy-Ragab]

Hi @IOhacker, I've closed this PR to provide a fresh, cleaner version that consolidates all the discussed changes into a single, well-structured commit. I’ll link the new PR shortly. Thank you for the great feedback so far!

[adamsaghy]

You can do that with a simple rebase