Class RemoteBrowserActionResolver

Applies an inbound RestoreContext___ blob to a server-side BaseEntity. Mirrors the OldValues___ pattern — the client-side BaseEntity's _restoreContext doesn't traverse the network, so the server must reconstruct it from the mutation input before calling Save().

Returns true when context was applied; false when no context was on the input.

Filters encrypted fields for an array of data objects. fieldKey is as for FilterEncryptedFieldsForAPI.

Array form of MapFieldNamesToCodeNames. Returns a NEW array of NEW objects; neither the input array nor its rows are modified. Both matter: a reference-sharing cache hands back the stored array itself, not a copy of it, so collecting the mapped copies (rather than mapping in place and returning the original) is what makes this safe on cache-served input.

SECURITY — GraphQL-boundary screen for one client-supplied SQL clause fragment.

ValidateUserProvidedSQLClause still blocks stacked statements, DML, comments, UNION and WAITFOR, and still permits SELECT (server-internal engines pass richer filters). A keyword ban on SELECT/EXISTS at this boundary (#4253) broke first-party clients that use IN (SELECT … FROM <entity base view>) — that is a legitimate ExtraFilter.

This screen uses @memberjunction/sql-parser (same wrap as EDS assertReadOnlyClause): wrap the fragment as a single SELECT, fail closed if it does not parse as a read, then allow a FROM only when it is an entity BaseView. Base tables (Meeting, __mj.User) and catalogs are rejected. Server-internal RunView callers get only the provider's statement-separator check, which cannot refuse a legitimate filter.

The screen is ClientClauseScreen in @memberjunction/generic-database-provider, shared with the REST view routes, ad-hoc list sources, and the provider's saved-view checks.

Before that parse, the fragment must be balanced on its own (IsBalancedSQLFragment). The provider and the tenant hook splice it inside parentheses and AND their own filters after it, so a fragment that closes those parentheses (1=1) OR (1=1) would leave row-level security and tenant scope on one side of an OR the caller controls. The parse wraps the fragment in parentheses too, which is why it cannot catch this alone. A backslash inside a quoted string or identifier is refused as well: the parser reads \' inside a plain literal as an escaped quote, but SQL Server and PostgreSQL end the literal there, so the text after it could be code that the parse-based checks never saw.

RLS is applied by RunView as an outer WHERE around the entity being queried, not compiled into the view, and RunView removes denied fields from its own result only. A subquery reads a base view directly with neither, so the screen refuses one over any entity the user reads under a row filter or with denied fields (ClientClauseScreen.AssertUnscopedRead), the queried entity included.

SECURITY — screen for a FULL client-supplied SQL statement (ad-hoc query path). In addition to the SELECT-only validation the caller performs, every table reference must resolve to an entity BaseView the acting user can read UNSCOPED. A reference is excluded only when it reads a CTE that is in scope there (StatementRelation.IsCTEReference): unqualified, declared by its own SELECT or an enclosing one, and matched by the dialect's identifier rules. A name reserved for the SQL parser is refused before parsing (ClientClauseScreen.AssertNoIdentifierAliasNames). Fails closed: no user, or an unresolvable reference, refuses.

The references come from a walk of the whole parse tree (ClientClauseScreen.CollectStatementReads). The statement is refused when that walk does not account for every SELECT in the text, or when a FROM item names no table (a table function or a row list).

Entity CanRead is not unscoped base-view read authority: RunView narrows a granted read with row-level security, and raw SQL does not apply it. Rather than try to rewrite arbitrary SQL (joins, CTEs) to compose that policy, this refuses any entity that carries a row filter for the caller — those reads belong on RunView. For the remaining entities CanRead genuinely means "every row and field of the view".

Checks API key scope authorization. Only performs check if request was authenticated via API key (apiKeyHash present in userPayload). For OAuth/JWT auth, this is a no-op.

Filters encrypted field values before sending to the API client.

For each encrypted field in the entity:

• If AllowDecryptInAPI is true: value passes through unchanged (already decrypted by data provider)
• If AllowDecryptInAPI is false and SendEncryptedValue is true: re-encrypt and send ciphertext
• If AllowDecryptInAPI is false and SendEncryptedValue is false: replace with sentinel value

Loads a single external-data-source-backed entity record by primary key and returns it in GraphQL field-name (CodeName) shape, or null if not found.

External entities (Entity.ExternalDataSourceID set) have no MJ base view or sproc — their data is proxied live from a remote system — so the generated single-record resolver cannot run SELECT * FROM <baseView>. Instead it loads through a BaseEntity object, whose InnerLoad the data provider dispatches to the external read router's LoadExternalRecord (a composite-key aware, quoted, parameter-bound single-record lookup), applying the same RLS gate and field post-processing (decryption / datetime normalization) as the MJ-DB path. The caller is responsible for the CheckUserReadPermissions gate beforehand.

Maps field names to their GraphQL-safe CodeNames and handles encryption for API responses.

For encrypted fields coming from raw SQL queries (not entity objects):

• AllowDecryptInAPI=true: Decrypt the value before sending to client
• AllowDecryptInAPI=false + SendEncryptedValue=true: Keep encrypted ciphertext
• AllowDecryptInAPI=false + SendEncryptedValue=false: Replace with sentinel

Returns a COPY — dataObject is never written to. Callers routinely pass rows straight from findBy/RunView, which are the server cache's own objects held by reference under a reference-sharing storage provider. Renaming in place therefore rewrote the cached row's keys, so later readers were served transport-shaped rows that BaseEntity.SetMany rejects — and because that cache is process-wide, one response corrupted every subsequent request across all workers. It bit every UserByEmail / UserByID / UserByEmployeeID call and every generated single-record resolver whose entity has caching enabled. Copying here fixes every call site at once and makes the hazard unreachable for future ones.

Publishes a CACHE_INVALIDATION event to connected browser clients after a successful entity save or delete. Includes the originSessionId so the originating browser can skip redundant re-fetches (it already handled the event locally).

The row itself rides along ONLY for entities opted in via cacheSettings.recordDataBroadcastEntities — this event reaches every connected client unfiltered, so the row would otherwise be readable by sessions that could not read the record.

Publishes a push-status update to the client on PUSH_STATUS_UPDATES_TOPIC, stamping the authenticated owner's user ID from userPayload so the subscription filter can bind delivery to identity (see B49 / statusUpdatesFilter). The ergonomic wrapper every resolver should use instead of calling pubSub.publish on the topic directly — it makes omitting identity impossible. Non-resolver publishers (services, the liveness heartbeat) call the shared publishStatusUpdate() function directly with an explicit ownerUserId.

Reverse-maps GraphQL-safe field names back to entity CodeNames in a mutation input object. For example, _mj__integration_SyncStatus is mapped back to __mj_integration_SyncStatus. Also reverse-maps keys inside the OldValues___ array if present. This is the inverse of MapFieldNamesToCodeNames and must be called before passing GraphQL input to entity SetMany() or field lookups.

Optimized RunViewGenericInternal implementation with:

• Field filtering at source (Fix #7)
• Improved error handling (Fix #9)

Optimized implementation that:

1. Fetches user info only once (fixes N+1 query)
2. Processes views in parallel for independent operations
3. Implements structured error logging

Applies assertClientClauseUsesEntityBaseViews to every client-supplied clause a view request can carry that is actually a SQL fragment. GraphQL entry points (RunViewByName, RunViewByID, RunDynamicView, RunViews) funnel through RunViewGenericInternal / RunViewsGenericInternal.

🚨 UserSearchString is deliberately NOT screened here (#4392). It is not a clause — it is the free text a person typed into a search box, and it never reaches SQL as a fragment. GenericDatabaseProvider.createViewUserSearchSQL builds the predicate itself from IncludeInUserSearchAPI metadata and lands the text only as a literal, doubling single quotes and escaping LIKE metacharacters with an explicit ESCAPE. Running it through a screen that parses its argument as SQL and fails closed rejected every term that is not coincidentally valid SQL: Marcus Chen parses as nothing, O'Leary as an unterminated literal — so essentially every real name search returned 0 rows.

The provider-level denylist does NOT back this up — it was removed from UserSearchString in the same change, for the same reason (it refused Union Pacific). What protects the value is that it is never SQL: it reaches the database only as a quoted, quote-doubled literal. The single place that is not true is a field carrying UserSearchParamFormatAPI, whose admin-authored format may splice the term in unquoted; createViewUserSearchSQL re-applies ValidateUserProvidedSQLClause for exactly those entities.

Each Aggregates[].expression gets the same screen, except that text the parser cannot read goes on to the provider, which refuses it per aggregate. The provider never runs the caller's aggregate text: it runs the SQL that CheckAggregateExpression rebuilds from a single aggregate call over the entity's columns, and refuses everything else per aggregate.

This routine compares the OldValues property in the input object to the values in the DB that we just loaded. If there are differences, we need to check to see if the client is trying to update any of those fields (e.g. overlap). If there is overlap, we throw an error. If there is no overlap, we can proceed with the update even if the DB Values and the ClientOldValues are not 100% the same, so long as there is no overlap in the specific FIELDS that are different.

ASSUMES: input object has an OldValues___ property that is an array of Key/Value pairs that represent the old values of the record that the client is trying to update.