@xrmforge/devkit 0.7.26 → 0.7.28

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -123,6 +123,31 @@ form.$unsafe('estimatedclosedate')?.setValue(closeDate);
123
123
  Always use optional chaining (`?.`). The Entity-level Fields Enum ensures the field
124
124
  name is valid even though it's not on the form.
125
125
 
126
+ **Exception - genuinely cross-entity / cross-form scripts (no single FormTypeInfo fits):**
127
+
128
+ A script bound to several entities (e.g. a GDPR helper on account/contact/lead) or to several
129
+ forms of one entity where no single form interface carries all the fields cannot use one
130
+ `typedForm<...>`. Then use the RAW `Xrm.FormContext` plus **named constants** (blank logical
131
+ names) for field/control access - this is an accepted pattern, not a workaround:
132
+
133
+ ```typescript
134
+ // constants.ts: named constants with blank logical names (NOT raw inline strings)
135
+ export const ROLE_FIELDS = { Role: 'markant_roleid', Product: 'markant_productid' } as const;
136
+
137
+ function onChange(ctx: Xrm.Events.EventContext): void {
138
+ const fc = ctx.getFormContext(); // raw FormContext, no cast
139
+ fc.getControl(ROLE_FIELDS.Role)?.setDisabled(true); // blank name; a runtime variable is fine here
140
+ }
141
+ ```
142
+
143
+ The validate-form gate counts a named constant as compliant (the violation is the raw inline
144
+ string, not the FormContext itself). Use `typedForm` whenever one form interface fits; fall back to
145
+ raw FormContext + named constants for any multi-form script - across entities, or across several
146
+ forms of one entity. For both cases this is the deliberate, supported pattern, not a stopgap. (A
147
+ generated per-entity union FormTypeInfo was considered and deliberately rejected: it would type
148
+ fields the active form may not carry as non-nullable - the false compile-time safety this framework
149
+ exists to prevent. Use named constants + `$unsafe` for nullable access instead.)
150
+
126
151
  ### 2. Fields Enum for ALL getAttribute/getControl AND select() calls
127
152
 
128
153
  Two types of Fields enums exist:
@@ -344,6 +369,10 @@ form.$context.ui.tabs.get(Tabs.SUMMARYTAB).sections.get(SummarySections.General)
344
369
  (form.$context.getControl(Subgrids.Orders) as Xrm.Controls.GridControl).refresh();
345
370
  ```
346
371
 
372
+ To show/hide a WHOLE section, toggle the section itself via `.sections.get(name).setVisible()`
373
+ (typed through the Sections enum), not each control individually - that is the right tool for
374
+ section-level visibility (F-LMA7-10 typed sections).
375
+
347
376
  ### 12. Notification IDs from NOTIFICATION_IDS
348
377
 
349
378
  All notification unique IDs must be in `constants.ts`, never inline raw strings:
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@xrmforge/devkit",
3
- "version": "0.7.26",
3
+ "version": "0.7.28",
4
4
  "description": "Build orchestration and project tooling for Dynamics 365 WebResources",
5
5
  "keywords": [
6
6
  "dynamics-365",