Design entity row security and timestamp behavior

Development and modifications

26R1 reference · Documentation-based walkthrough · Sources reviewed 2026-09-28 · Not executed in IFS or Oracle. Match the database, build home, and tools to your installed release. Example names are fictional.

Design a fictional handover entity containing a site, reference, and scheduled timestamp. Two users should see only their permitted sites, while timestamp values retain their intended meaning across API and client displays.

Before you start

Use a customer-owned entity in a development project and two normal test identities with different site access. Record the actual stored timestamp meaning, configured server/site zones, and expected user display zones. Do not test only as the application owner or an administrator who bypasses normal restrictions.

1. Write the data-access contract

Identify whether access depends on company, site, owner, or another business relationship.
Create fictional records for sites A and B. Give one test user A only and another B only.
List each read path: base view, secondary view, projection, reporting view, and configuration/query tooling.
List each write path separately. Being unable to list a record is not proof that a write endpoint rejects its key.
Agree the expected allowed/denied cases before choosing a code-generation property.

2. Implement the restriction before marking it safe

Use an applicable predefined row-level filter or implement the approved restriction in the actual view. Inspect generated predicates and verify that they use the caller’s permitted scope.

The following entity fragment declares that a custom restriction has already been implemented:

codegenproperties {
   DbViewRowLevelSecurity "custom-implemented";
}

It does not add a filtering predicate by itself. Check the view and test the two identities before making this assertion. A not-required declaration is appropriate only after deciding that every authorized reader may see every row of that view. It is not a shortcut for making sensitive business data available to Query Designer.

For non-base views, follow the corresponding documented view annotation. Inspect dictionary metadata after generation/deployment and the supported cache refresh; a safe-looking label with an unrestricted query is a failed security design.

3. Classify the timestamp

Decide whether the value means an instant, a site’s scheduled local time, or a calendar date without a time. Record the storage and conversion contract; do not select UTC/server/site solely because it sounds more modern.

For an entity whose timestamps use server time, the documented model fragment is:

codegenproperties {
   TimestampTZRef "server";
}

A site-based entity instead needs the documented site(...) reference to its actual site attribute or supported expression. Confirm how the site is resolved for every row, including empty site values and keys containing timestamps. Do not paste a made-up site column name.

Choosing a default convention for future attributes is a team design decision. Changing time-zone annotations on an existing entity can reinterpret stored values; first plan and test legacy-data handling and any required migration.

4. Trace the complete API conversion path

Inspect the base entity annotation and any projection override.
For unbound actions/functions, check primitive timestamp inputs/returns and the operation’s time-zone reference.
Inspect structures and nested structures independently; a top-level operation annotation does not automatically configure timestamps inside every complex structure.
Compare actual serialized API values, stored values through approved diagnostics, and the client’s working-zone display.
Avoid converting the same value twice in middleware after the framework has already applied its documented conversion.

Use workflow time-zone guidance when a workflow consumes the same values.

5. Run security and time-zone cases

Test	Expected evidence
Site A user lists records	A records only
Site A user requests a B record directly	No unauthorized data or mutation
Same business instant sent with equivalent offsets	Same intended instant after the round trip
Two sites in different configured zones	Each follows its documented site-time contract
Date without a time component	No accidental day shift from an invented time zone
Missing site or ambiguous local time	Documented validation/disambiguation, not guessed conversion
Daylight-saving transition	Explicit handling of repeated/nonexistent local times
Existing stored data after annotation change	Agrees with the reviewed migration/legacy-data design

For an offset-equivalence fixture, 2026-09-28T08:00:00Z and 2026-09-28T13:30:00+05:30 represent the same instant. This does not prescribe your database’s storage zone.

Troubleshooting

Check generated security predicates when rows leak; check effective identity when an administrator’s result differs. For timestamp drift, compare each boundary rather than adjusting the displayed value until it looks right. Review inherited annotations, site resolution, nested structures, and legacy data.

Exercise and solution

Exercise: a view has custom-implemented metadata but both users see A and B records. Is the declaration sufficient?

Show the solution

No. Inspect and correct the actual restriction, then repeat list, direct-key, and write tests as the normal users. The metadata describes implemented security; it is not the implementation.

Cleanup and delivery evidence

Remove disposable records and temporary role assignments after recording results. Deliver the model, views, projections, grants, and migration decisions together. Keep sensitive business data out of exported evidence.