A new field user with no boards assigned saw every board
Two new field staff were given no boards and could see all 101. A week later a user with 51 boards was shown 123 due out of 128. Two causes, one fix.
You take on two field staff and, as far as you are concerned, they start with nothing. No boards allocated, so no boards visible. You add them, they log in, and each of them sees all 101 boards in the company: every site, in every part of the city, including the ones they will never be sent to.
That was the opposite of what had been asked for. A week later it happened again in a different way. A field user with 51 boards allocated opened the app and was told that 123 boards were due for a check, out of 128 in the whole organisation. He was entitled to 51.
Nothing in the log says anyone misused what they saw. The exposure was still real: a field phone is the device most likely to be lent, lost or glanced at by a stranger, and it was showing the whole inventory.
What was actually going on
The first cause was a rule somebody chose on purpose. When allocations were introduced, the system treated a user with zero allocations as unrestricted, so that switching the feature on would not lock anyone out. It was a sensible way to ship. It also meant that a brand-new field user, who by definition has no allocations, got the widest view in the building.
A second thing made it worse. The mobile app decides which version of itself to show by permission. The supervisor who was meant to oversee the two new staff held the Field User role, so he was given the cut-down app with two tabs and could not browse a single board. The people who should have seen little saw everything, and the person who needed to see more could see nothing.
The second exposure, a week later, came from a different place. The rule that works out what a user may see was correct. But it read the role’s settings inside a block that, on any failure at all, gave up and returned “unrestricted”. It had been written for installations that predated the change, and it caught every kind of failure, not only that one.
The real trigger was a quiet one. If the server starts while the database is briefly unreachable, it carries on without part of its setup, and from then on every field user is unrestricted for as long as that process lives. The health check answers that everything is fine throughout. It was found from a screenshot, not from a report.
What we changed
Roles now carry two explicit settings, see all sites and see all campaigns, instead of the system guessing from an empty list. Owner, administrator, operations, sales, finance and viewer were set to yes and the field role to no, so nobody’s reach changed on the day. What a user sees is now their role’s setting or their allocations, and no allocations means nothing.
The broad failure handler now gives way only when the database genuinely predates the change, a missing column or table. Any other failure narrows what the user sees and is logged. Reproduced both ways against a copy of the data, a degraded server now shows a user less than they are entitled to, which is the direction to be wrong in.
Because one piece of logic decides what a user may see, sites, tasks, campaigns, encroachment reports, search and reports were all exposed and all fixed by the same change. On the copy used for checking, the supervisor was moved off the Field User role so he gets the full app, and the two staff were given their boards. Through the live interface they saw 52 and 51 boards, the supervisor 104, and the owner all 128.
What it did not fix
The log does not say how long the new staff could see everything in production, or whether either of them looked. The second fix was proved against the sandbox copy and the QA environment; the log does not show a production reading of who could see what.
The change also exposed a fault that had been hidden by the old rule. With an empty allowed list, the global search query broke and took search down. It could not happen before, because nobody ever had an empty list. It was fixed alongside.
The pattern, for anyone running a field team
Ask what a user sees when nothing has been configured for them. If the answer is everything, you have a default that favours the newest and least-vetted person in the company.
Then ask what happens when the thing that looks up a user’s access fails. A system that shows more when it cannot check is failing in the direction that costs you. The simple test takes five minutes: create a user with no access and see what their screen shows.
Where this ends up
The entitlement rule is one of the things AdBoard has to get right for a media owner with field crews: a user sees what their role and allocations say, and nothing more when something goes wrong.