A checklist for when a tech can see storerooms that are not theirs and the data restriction looks correct. Work it in order and find the group that is OR-ing past your scope. Applies to MAS 8.x, 9.0, and 9.1.
A tech sees storerooms that are not theirs even though the restriction looks right. Usually the restriction is not the problem. A user's effective profile is the combination of all their security groups, the highest privilege prevails, and data restriction conditions OR together, so a broader group with no condition on the object is OR-ing right past your scope. This checklist works the problem in order.
List every security group the user is in, that full set is the effective profile. Mark which groups grant the inventory objects in question. Find any group that opens those objects with no condition, that is the likely offender. Check MAXEVERYONE, the everyone group, which always combines even when marked independent. Confirm the ownership attribute is populated, and confirm the condition family covers every object and view the user can reach.
No email, no signup. This checklist fixes the leak. If the cause turns out to be a missing object, a gap in the condition family, or an application path the restriction never covered, that is a full build review, not a quick fix.
This checklist fixes the leak. Building per-user storeroom scoping correctly, the whole solve end to end, is the AppPoints and Security Groups Workshop and Playbook.