Fix: add cancelled at

[CrochetFeve0251]

Description

This PR adds support for distinguishing between canceled and active subscriptions for Rocket Insights (Performance Monitoring Addon). When a subscription is canceled but still active until the end of the billing period, the interface will now show "Expires at" instead of "Next Billing Date" to avoid confusion for users.

Type of change

• Bug fix (non-breaking change which fixes an issue).

Detailed scenario

What was tested

• Tested with an account that has an active Rocket Insights subscription
• Tested with an account that has a canceled Rocket Insights subscription that is still valid until the end of the billing period

How to test

1. Create a test account with an active Rocket Insights subscription
   • Verify that the label shows "Next Billing Date" with the appropriate date
2. Create a test account with a canceled Rocket Insights subscription
   • Verify that the label shows "Expires at" with the appropriate date
3. Verify the display is consistent in the dashboard addon status section

Technical description

Documentation

This PR utilizes the cancelled_at field from the Performance Monitoring Addon (PMA) data to display appropriate labels in the dashboard. The conditional logic checks if the subscription has been canceled:

$label = $cancelled_at ? __( 'Expires at', 'rocket' ) : __( 'Next Billing Date', 'rocket' );

This change:

1. When cancelled_at is populated (subscription is canceled): Display "Expires at"
2. When cancelled_at is not set (subscription is active): Display "Next Billing Date"

This provides clearer information to users about the status of their subscription.

New dependencies

No new dependencies were added for this change.

Risks

No performance or security risks identified. This change only affects the display of text labels based on existing data.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Unticked items justification

All mandatory items are relevant and have been checked.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 0e978c81	✅ 50.73% (target: 50.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (0e978c8)	Report Missing	Report Missing	Report Missing
Head commit (2947f74)	41295	18384	44.52%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#7736)	1376	698	50.73%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩