[Bug 641000] Add the CLEAN29 preprocessor for the document report experience - #11074
[Bug 641000] Add the CLEAN29 preprocessor for the document report experience#11074Morten Rasmussen (v-mortenr) wants to merge 1 commit into
Conversation
…erience The Document Report Experience feature key gates the composite layout feature - the layout subtype, the header/footer and theme parts, and the pages that configure them. The feature is GA in 29, so every piece of that gating is now wrapped in #if not CLEAN29: 29 keeps the feature key exactly as it behaves today, and 30 compiles without the flag, leaving the feature unconditional. This is the first of the two steps the MCP feature flag went through. Compare the EnableMcpAccess gating, which was wrapped the same way at GA and then deleted wholesale once CLEAN28 came due (commit 3ffea8e). Nothing is removed here; that is the follow-up change when 29 is cleaned up. Feature Key Management keeps IsDocumentReportExperienceEnabled reading the feature key, with the procedure and its DocumentReportExperienceTxt label both inside the guard. No Obsolete attribute: the accessor still has live callers in 29, and the MCP precedent did not mark its equivalent either. At the call sites: - 19 country Company Information pages: the Reporting group's Visible property, the FeatureKeyManagement declaration, the resolve-on-open block and the DocumentReportExperienceEnabled variable. - 7 W1 Reporting pages: the Subtype field, the composite layout groups and actions, the header/footer and theme part fields, the two OnOpenPage gates that raise FeatureNotEnabledErr, and the three labels behind them. #else branches appear only where a term has to survive into 30: the company default displays call, ReportLayouts' Visible = ... and BodyLayoutSelected plus its OnOpenPage condition, and ReportLayoutNewDialog's two subtype visibility assignments. Where FeatureKeyManagement was the only local of a trigger, the var keyword is inside the guard too, so 30 does not end up with an empty var section. Verified statically: every #if is balanced by an #endif in all 27 files, and no reference to the flag, the accessor or FeatureNotEnabledErr remains outside a guard. Insertions only, no deletions.
| exit(FeatureManagementFacade.IsEnabled(GetSIEAuditFileExportFeatureKeyId())); | ||
| end; | ||
|
|
||
| #if not CLEAN29 |
There was a problem hiding this comment.
Feature Key Management schedules IsDocumentReportExperienceEnabled(), the backing DocumentReportExperienceTxt label, and the DocumentReportExperienceEnabled fields for removal via #if not CLEAN29, but none of these symbols carry [Obsolete(reason, tag)] metadata before the CLEAN guard — unlike the existing CLEAN27 precedent in the same codeunit, which marks its retiring procedure [Obsolete(...)] ahead of the #if not CLEAN27 guard. Per BC upgrade conventions, retiring a public procedure should go through an obsolete-pending stage with a documented reason and version tag so extensions calling it get a deprecation warning, rather than the symbol silently disappearing the moment CLEAN29 is defined. Add [Obsolete('...', '29.0')] to IsDocumentReportExperienceEnabled (and any other still-public members being retired) ahead of the CLEAN29 guard.
Knowledge:
- microsoft/knowledge/upgrade/obsoletion-requires-reason-and-tag.md
- microsoft/knowledge/upgrade/obsolete-pending-to-removed-staging.md
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.38.6
Good Sense Reviewer - Round 1Recommendation: AcceptProblem-solution fit: Strong What this PR doesThis PR removes the runtime feature-key gate for the document report experience when the CLEAN29 build flag is active. Older builds keep the existing feature management checks, while CLEAN29 builds always expose the composite layout fields, actions, and lookup behavior. The preprocessor wrapping is consistent across the changed pages, subscribers, and tests. I did not find a behavior path where older builds lose the feature flag or CLEAN29 builds keep a stale hidden control. SuggestionsNone. Risk assessment and necessityRisk: Low to moderate. The change is broad, but it is mechanical and limited to feature visibility and report layout selection. It does not change posting, ledger data, or amount calculation. Necessity: The change is needed because the feature is no longer optional in CLEAN29. Keeping the old feature-key checks there would leave GA functionality behind a removed toggle.
|
What & why
The
DocumentReportExperiencefeature key gates the composite layout feature — the layout subtype,the header/footer and theme parts, and the pages that configure them. The feature is GA in 29, so
every piece of that gating is now wrapped in
#if not CLEAN29: 29 keeps the feature key exactly asit behaves today
At the call sites:
Visibleproperty, theFeatureKeyManagementdeclaration, the resolve-on-open block, and theDocumentReportExperienceEnabledvariable.header/footer and theme part fields, the two
OnOpenPagegates that raiseFeatureNotEnabledErr,and the three labels behind them.
27 files, 266 insertions, 0 deletions.
Linked work
AB#641000 — tracked in ADO (Dynamics SMB); internal cleanup with no public issue.
How I validated this
What I tested and the outcome
Static verification only, and I want to be plain about that. Every
#ifis balanced by an#endifacross all 27 files, and no reference toDocumentReportExperienceEnabled,IsDocumentReportExperienceEnabledorFeatureNotEnabledErrremains outside a guard — checked bywalking each file and tracking guard depth line by line. Insertions only, no deletions, and no BOM
or end-of-file newline drift.
No tests added or needed. 29 behaviour is unchanged — the gating is byte-for-byte what it was,
just inside a guard. In later version the flag is gone and the feature is always on, which is what the tests
already exercise: every relevant test in codeunit 134619 calls
EnableDocumentReportExperience()in its setup, so they were already running with the feature enabled.
Risk & compatibility
29 is unaffected by design — same feature key, same behaviour, same code paths. The only behavioural
change lands when features goes GA, where the feature becomes unconditional, which is the intent of the GA.