@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.
- package/dist/templates/AGENT.md +29 -0
- package/package.json +1 -1
package/dist/templates/AGENT.md
CHANGED
|
@@ -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:
|