[Bug]: Critical bug: When staff roles can manage locations those outside their restrictions

[YogeshwarDBarai]

What happened?

When a staff role is given permission to manage locations then that role is able to manage/view those locations which he doesnt have access to. This is a critical flaw as per restaurant POV.

What did you expect to happen?

staff role with that permission should be manage that locations which the staff has access to

Version

4.x

What browser are you seeing the problem on?

No response

Relevant log output

[pradhankukiran]

I dug into the current 4.x code and the issue looks real, but narrower than originally described.

What I could not confirm:

• I do not see an unrestricted list/edit path for locations in the normal admin screens.
• The Locations controller scopes both list and form queries to the staff member’s allowed locations via AdminLocation::getAll() in controllers/Locations.php.

What I could confirm:

• The default-location action is not scoped the same way.
• index_onSetDefault() in controllers/Locations.php accepts the posted default location id and passes it to Locations_model::updateDefault().
• updateDefault() in models/Locations_model.php uses an unrestricted find($locationId) before calling makeDefault().

That means a staff user with the Admin.Locations permission may be able to set the global default location to a location outside their assigned location set, if they can submit or tamper with the request.

So this looks like a real authorization bug, but more specifically around the “set default location” path rather than unrestricted access to all location records in the standard list/edit flow.

[pradhankukiran]

Follow-up: I confirmed the fixable bug is in the admin module code path, but that code appears to live in the read-only subtree split tastyigniter/ti-module-admin.