xds caching errors on HcmWorker and related HR tables are caused by three specific issues — here is how to implement the policy correctly and avoid each one:
Root causes of caching errors:
HcmWorker has aggressive kernel caching (CacheLookup = Found or EntireTable) — when XDS filters the initial result the AOS caches that filtered set and serves stale records as the user navigates across operating unit contexts
Heavy SQL operations inside the xds() method cause kernel timeout exceptions on every row fetch
Unindexed joins in the XDS query predicate break kernel query caching plans
Correct implementation:
Create a secure mapping table (e.g. MyUserOperatingUnitSecurity) with UserId and OperatingUnitId. Use this as your XDS primary table, linked to HcmWorker via standard department or position relations.
Implement the context method cleanly:
public static server str findUserOperatingUnitXDS()
{
MyUserOperatingUnitSecurity userUnitSecurity;
str filterString;
while select userUnitSecurity
where userUnitSecurity.UserId == curUserId()
{
if (filterString)
filterString += ',';
filterString += int642Str(userUnitSecurity.OperatingUnitId);
}
if (!filterString)
filterString = '-1'; // deny unassigned access safely
return filterString;
}
three rules to prevent caching errors:
never use aggressive static caching on tables constrained by XDS — forms depending on those tables must not cache filtered result sets across operating unit context changes
Always run full database synchronization and clear server cache after modifying any XDS policy
During troubleshooting assign the built-in XDSDataAccessPolicyBypassRole to isolate whether missing data is an XDS caching issue or a standard security privilege gap — this tells you immediately which layer the problem is in
If it helps,Mark answered.
Share
Report
6
All responses (
Answers (
