Build, test, and troubleshoot a client keyword change

Client keyword reference / Build, test, and troubleshoot a client keyword change

IFS Cloud 26R1 · Documentation-based examples · Not compiled or executed in IFS.

A website code block is not a compiled IFS model. These examples are documentation-based and use fictional names. Record the actual release, tool build, component, layer, and test results before reusing a change in a customer environment.

Apply one example end to end

Create a branch in an authorized development checkout. Save the unchanged model’s build result and a screenshot of the current page.
Open the existing client and matching projection in Developer Studio. Confirm the project release and generated model dependencies match the target environment.
List the example’s required entity sets, types, attributes, references, arrays, methods, and permission grants. Map each fictional name to a real contract. Do not copy the DEMO component name unchanged.
Add one declaration and its insertion point. Keep file headers and layering annotations consistent with the established project. Use the editor’s completion at that exact position to check the keyword is valid for that container.
Build/generate using the project’s supported workflow. Fix the first syntax or unresolved-reference error before interpreting the errors that follow it. Inspect the merged/generated model so an override has not accidentally removed base controls.
Deploy the approved projection and client artifacts to the training environment in the project’s normal dependency order. Use the delivery matrix to record artifact/version evidence.
Grant the test user’s required projection actions/entity operations through permission sets. Open the page with that user, not only an administrator.
Run the control-specific checks in the guide. Inspect network requests for source, key filters, result types, denied calls, and failed saves. Do not put tokens or personal data in screenshots/logs.
Reload and verify any intended server write persisted. Test Cancel and rejected operations to prove they did not write or show misleading success.
Remove training data through supported APIs, revert temporary grants, and retain build output plus expected/actual evidence. If validation fails, revert the source change and redeploy the previously approved artifact through your delivery workflow.

Troubleshoot by evidence

Symptom	Check first	Corrective action
Keyword rejected	Container, file type, release grammar	Move it to the supported scope; distinguish a declaration from a property or insertion
Attribute unresolved	Projection metadata and spelling/case	Expose the attribute on the actual bound type, regenerate, and deploy dependencies
Control never appears	Insertion point and visibility expression	Add the reference to the page; test true/false/null conditions
Wrong rows after selection	Type, `using`, array keys, `bind`	Repair the relationship and selection source; include composite keys
LOV displays a name but saves a wrong key	Reference mapping and lookup set type	Compare stored keys for two same-label records from different sites
Works only for admin	Permission and row-security evidence	Grant the intended minimum operations; do not solve it by disabling security
Success toast but no saved change	Action call and response, then reload	Implement/repair the server operation; display success only after completion
Old behavior after deployment	Artifact version, generated model, profile/cache	Confirm deployment first, then follow supported profile/cache refresh guidance
Chart total differs from list	Filter, aggregation grain, fetch limits, nulls	Reconcile the service dataset before changing chart styling
UI prevents edit but API accepts invalid input	Missing server business rule	Add validation/authorization at the service layer and repeat both routes

When escalating, retain the smallest model fragment, installed version, exact error, named source type, input fixture, and expected/actual behavior. An HTTP 200 returning an empty set needs different investigation from a 403 or failed generation.

Acceptance worksheet

Use the downloadable client acceptance checklist. Each example starts as Not run. At minimum record:

Valid data plus null/empty/boundary data.
Two different parent selections and composite keys where relevant.
Allowed and denied users, including direct API behavior.
OK, Cancel, server failure, and reload after a write.
Keyboard use, narrow viewport, labels, and empty/loading/error states.
Saved model version, build result, environment release, and reviewer.

For a first exercise, display RequestId and Title, make Title read-only only when Closed is true, and add a harmless Check command. Expected outcome: selection changes both fields, open requests permit editing, closed requests do not, and Check shows its server result without changing the record. Add server validation before calling this a complete business implementation.

Official syntax and next steps

Use the build and acceptance checklist before delivering a change.