EML Part 3: IN LOCAL MODE — What It Bypasses and When It Is Safe

📌 KEY POINTS
✅ IN LOCAL MODE skips authorization and feature control.
✅ It does NOT skip determinations, validations, locks or draft.
✅ Allowed only for the BO of the behavior pool.
⚠️ Never use it (or direct writes) to bypass another BO's checks.

▶ WHERE WE ARE
Parts 1–2 used EML from outside the BO. Inside a behavior implementation you almost always write READ/MODIFY ENTITIES … IN LOCAL MODE. This part explains why.

━━━━━━━━━━━━━━━━━━━━
▶ THE PROBLEM IN LOCAL MODE SOLVES
The BO itself must sometimes do things its consumers are not allowed to do:

• An approve action sets Status — but Status is "field ( readonly )".
• A determination sets TotalAmount — also read-only.
• An action changes an approved request's status to closed — but feature control disables update for approved requests.
• Internal operations ("internal action recalcTotal") are only callable by the BO itself.

Without local mode, RAP would apply the same checks as for an external caller and reject these changes.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT IN LOCAL MODE SKIPS

• Authorization checks (global and instance) for this EML statement.
• Feature control (static and instance) — including read-only fields and disabled operations.
• It also allows calling internal operations.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT IN LOCAL MODE DOES NOT SKIP

• Determinations and validations still run as triggered — your own business rules still apply.
• Locks and ETag handling of the framework.
• Draft handling: %tky decides draft or active.
• The save sequence: the change is still only in the buffer until commit.

So local mode means "the BO trusts itself", not "anything goes".

━━━━━━━━━━━━━━━━━━━━
▶ WHERE IT MAY BE USED

• Only inside the behavior pool of the same BO (the syntax check enforces this).
• For reads inside the BO as well: READ ENTITIES … IN LOCAL MODE avoids needless authorization checks on data the BO already works with.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT IT MUST NOT BE USED FOR

• Bypassing authorization for the user's own request. If a user triggers an action, the action itself is checked by RAP before your code runs; inside it, local mode is fine. But do not create "helper" actions that let users change fields they are not authorized to change.
• Calling other BOs. You cannot use IN LOCAL MODE for another BO. When your BO changes another BO (e.g. creating a follow-up document), the call goes through that BO's normal checks for the current user. If the other BO explicitly allows it, it can offer a "privileged" access path (declared with "with privileged mode" in its BDEF) that your code uses with the PRIVILEGED addition — a controlled, documented exception, not a workaround.

━━━━━━━━━━━━━━━━━━━━
▶ PRIVILEGED VS LOCAL — SHORT COMPARISON

• IN LOCAL MODE — own BO only, skips authorization and feature control.
• PRIVILEGED — another BO that declared privileged mode; skips the authorization checks that BO defines as skippable (typically related to access from other trusted BOs).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Search your behavior pool: every READ/MODIFY on the own BO should have IN LOCAL MODE.
2. Check that no local-mode code changes data the user should not be able to change through that action.
3. For calls to other BOs, remove any attempt to bypass their checks; use their public or interface operations.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 3
Correct use of local mode. Part 4 covers calling other BOs and controlling commits.

A developer needed a purchase request action to create a budget reservation in a finance BO owned by another team. Because the user lacked the finance authorization, the call failed, and the developer tried to use IN LOCAL MODE on the finance BO. The syntax check rejected it, so he created a helper function that wrote the reservation table directly.
In the review, the direct write was removed: it bypassed all finance validations. The finance team offered a privileged path for exactly this reservation case, documented who may use it, and the purchase request action called it with PRIVILEGED. Everything else in the finance BO kept its normal authorization checks.

• Forgetting IN LOCAL MODE inside the behavior pool, so the BO blocks its own changes.
• Thinking local mode skips validations and determinations.
• Using local-mode actions to let users change fields they are not authorized to change.
• Trying to use local mode on another BO, or bypassing it with direct table writes.
• Using PRIVILEGED without the owning team's agreement and documentation.

• Use IN LOCAL MODE for all READ/MODIFY of your own BO inside the behavior pool.
• Keep authorization at the entry point: the action or operation the user calls is checked.
• Call other BOs through their normal or interface EML API and map their responses.
• Use privileged access only when explicitly provided and documented.
• Review local-mode code for unintended permission escalation.

Questions: "What does IN LOCAL MODE do?", "What does it not skip?", "Can you use it for other BOs?", "What is privileged mode?"
Strong answer: local mode lets the BO bypass its own authorization and feature control (e.g. changing read-only Status in an action, calling internal actions); determinations, validations, locks and the save sequence still apply. It is only allowed for the own BO. Other BOs are called with normal checks; a BO can explicitly offer privileged access for trusted callers. Pointing out the permission-escalation risk shows maturity.