Flow
What an import does now
1Find the company
From the request, or from the token when it covers only one.
2Check it
No company gets a 400; a company the token does not cover gets a 403.
3Build the list
Only that company's staff, with admins left out.
4Match names
Names not on that list come back unmatched instead of borrowing someone else's ID.
Matching pasted names, the shift-scheduling app searched every staff member in the database. Not just my company's people. Everyone on the install.
The import reads a pasted schedule, or a PDF turned into text. For each name it finds, it looks up the real staff record, so each shift lands on a real person. To do that, it first builds a list keyed by first name.
That list came from the whole staff table. Every company shares that table, and the parser was never told which company was importing. The table also holds admins, who I had banned from schedules that same morning. The lookup didn't know about that either.
The PDF endpoint made it worse to look at. It checked the company and store against your login token, and turned you away if they were missing or not yours. Then it handed the text to a parser that ignored all of it. The text endpoint checked your token but never asked about the company.
So a name in one company's paste could match someone at another company, and the result would carry that person's ID. I can't point to a time that actually happened. But nothing in the code stopped it.
The parser now has to be told the company. There's no default, so every caller had to change.
The lookup now considers only that company's staff, minus the admins.
The text endpoint now checks the company the way the PDF one does. If there's no company, it says so with a 400. If your token doesn't cover it, you get a 403. Debug mode skips this, but it needs its own permission.
The new test pastes one schedule with three people. One is regular staff in my test company. One is an admin in that company. One works for a second company. All three show up, but only the first gets an ID. The other two come back unmatched. That's what I want, since a person can see an unmatched name and fix it.
Later that day I added a store filter, then pulled it back out about an hour later. The commits don't say why. Likely that store was too narrow for people who work at two locations. The store setting is still in the parser, and it does nothing now.