A job assigned to a field user never appeared on the board

A supervisor opens the tasks screen to hand a job to one of the field team: the end-of-month check on a board. They fill in the form and press Create. The screen says it worked. They look at the board of tasks, and the job is not there.

Before that, it was worse. Creating a task from the portal failed on every single submit, from the day the screen shipped. Nobody could assign work from the office screen at all.

What was actually going on

There were two faults, and the second was hidden behind the first.

The first: the server requires every task to have a type, and neither the office screen nor the phone sent one. The request shape said the type was optional, so the compiler had nothing to complain about. On the test copy, every attempt was refused until somebody added a type by hand.

The second appeared once creation worked. The task was created; the log shows the row sitting in the database with the right assignee. The list simply never asked for it. The list endpoint reads a missing assignee filter as “my own tasks”. That is correct for the phone, where a field user must only ever see their own. But the office board’s filter is labelled “Everyone” and, by default, sent nothing. So a supervisor who assigned a job to a field user was shown only the jobs assigned to themselves.

There was a third problem behind the vocabulary. The list of task types was written into the code, but the client hands out kinds of work of its own: start-of-month, end-of-month, start-of-campaign and end-of-campaign checks, with more to follow. Each new kind would have meant a code change and a release for what is only business vocabulary.

What we changed

Task types now live in a table per organisation, nine seeded for each, and can be edited without a release. The server accepts only the types that organisation has active and lists them in the error if one is refused. Type is required on both the phone and the portal, and the portal’s create form offers the list the server supplies.

The office board now asks for what its own label promises. When the filter says “Everyone”, the portal sends the server’s own word for all tasks, but only for a user who is allowed to assign work, since anyone else would get a refusal. We changed the portal and not the server, because the server’s default is deliberate, tested, and relied on by the phone apps already installed. Flipping it would have shown every user on a phone the whole organisation’s work under a heading that says it is theirs.

The tests changed too. The browser tests had stubbed a success for any request, which cannot tell a valid form from an invalid one, and that is how a form that failed on every real submit sat behind a green suite. They now check what is actually sent.

What it did not fix

The Type filter in the portal’s toolbar still does nothing, because the server does not read it. We left it, and recorded it.

Also, the screen for managing task types was built and then removed on instruction when the work was handed to someone else. The server side exists and is tested; the settings screen does not.

The pattern, for anyone assigning work through a system

Watch what a request says, not just whether it succeeded. A test that accepts any answer will pass a screen that has never worked.

And when a list can be filtered, check what it shows when nobody has chosen a filter. Its default is a decision, and a label that says “Everyone” should mean everyone.

Where this ends up

Assigning a job to the field team, and seeing it land on their phone, is part of AdBoard, the system that runs for Gold Sign Media, an outdoor media operator. A supervisor who assigns a job now sees it on the board.