Site Restriction Leak After Security Group Consolidation
After a merger, an administrator consolidated 14 legacy security groups into one group called OPS_TECH to cut administration effort. The 60 technicians in OPS_TECH have BEDFORD as their default insert site. The group has a WORKORDER data restriction of SITE = 'BEDFORD'. The administrator also left the old group REPORTING active because three technicians still need cross-site reporting; REPORTING grants WORKORDER read access with no site restriction. Within a week, technicians report seeing SPRINGFIELD work orders in the Work Order Tracking list and can open them. The administrator confirms the OPS_TECH restriction is active and that most users are not in REPORTING. A custom automation script copies ASSET.SITE to WORKORDER.SITE at creation, and a few legacy work orders have a null SITE. The business wants a fix that does not remove reporting access for the three analysts.
1. Before changing the OPS_TECH data restriction, what access paths must you enumerate, and why is tightening that one group unlikely to solve the whole symptom?
Read the worked answer
Start by treating Maximo authorization as cumulative, not exclusive. A user gets the union of access from every security group, including EVERYONE, plus any site or organization authorization on the user record. Tightening OPS_TECH does nothing for a user who also belongs to REPORTING or another group with unrestricted WORKORDER read. That likely explains the three analysts, but not every technician, so keep enumerating.
Next, separate authorization from data shape. Run a query or list view as a test user who belongs only to OPS_TECH. If SPRINGFIELD records still appear, inspect their SITE values. A null or blank SITE can behave differently depending on how the restriction and any custom query are written. Then inspect the automation script: if it copies a SPRINGFIELD asset site onto a work order created by a BEDFORD technician, the record is legitimately SPRINGFIELD and the visibility is an authorization or business-process issue, not a scripting bug. Also check saved queries and application access, because a user who can open another application that reads WORKORDER may bypass the list you are testing.
2. How would you test the data restriction independently of the desktop list, and what would you look for in the automation script?
Read the worked answer
Create a disposable test user with only OPS_TECH and no other groups, then log in and query Work Order Tracking. Compare the visible records with a direct SQL count by SITE for BEDFORD, SPRINGFIELD, and null. If the UI count differs from SQL, inspect the application query, saved query, and any custom control. Repeat by adding REPORTING to the test user; if the SPRINGFIELD records appear only at that step, the group overlap is confirmed.
For the automation script, identify the launch point, the script variable used for SITE, and whether it runs before save or after save. Verify whether it overwrites an explicitly entered site, and whether it handles a null ASSET.SITE. Check a sample of SPRINGFIELD records to see whether their asset truly belongs to SPRINGFIELD. If the asset does, the record is correctly classified and the fix belongs in security or process design. If the script writes BEDFORD but the record shows SPRINGFIELD, investigate script order and any other automation that changes SITE.
3. Recommend a sustainable group model and an audit control so a future consolidation does not reopen the gap.
Read the worked answer
Separate site-operator groups from cross-site read groups. OPS_TECH should carry the BEDFORD restriction; REPORTING should be a small, named exception with a business owner and a review date. Avoid granting unrestricted read through EVERYONE or through broad application groups. When consolidating groups, compare the union of data restrictions, object authorizations, and site authorizations rather than only the group names.
Add a recurring audit that lists each user, every group, and every data restriction on WORKORDER, plus site and organization access. Test high-risk groups with a disposable user and a standard query set. Require a change ticket and a test result before any group consolidation. For the three analysts, consider a separate read-only cross-site group rather than a broad reporting group that also grants other application options. This keeps the exception visible and prevents a routine cleanup from turning into an invisible cross-site grant.