Three New Fields and One Comment Beside the Old category Label

A user reported that the screen for linking sites was offering the wrong organizations after an admin picked a child event from a dropdown. Nothing crashed. No red warning appeared. The page just made a confident suggestion that did not fit what the person had selected.

The wrong list only showed up after a particular sequence of clicks. The parent account could be one category, and the child event inside it could be another. If the two matched, everything looked normal. If they did not, the list was wrong.

The label the page had always trusted

The first thing I found in the code was a label called category. The filter used it to decide which organizations belonged in the list. For years that had been fine, because the account in the web address and the account whose information the page was using were always the same. One label was enough.

Then the new dropdown changed things. An admin could stay on the parent account but open a child event inside it. Now there were two answers to a simple question: whose category are we talking about?

The filter kept following the old label. That was not a wild guess. It was the label the page had always used, and it still correctly described the parent account. It just did not describe the child event the person had chosen. That first answer cost a user patience, and it cost us time, because the mistake stayed hidden unless the parent and child were different categories.

A shared note that two jobs were reading

This kind of problem has a technical name: a global variable. It is a shared, labeled note that a web page leaves where any part of the page can pick it up. Shared notes are convenient until two parts of the job need different facts. Then the label can be right for one job and wrong for another at the same moment.

The page was already receiving information from the server when it loaded. The server wrote a small bundle of details directly into the page for the browser to use, including the old category label, which always came from the parent account. The browser did exactly what it was told. The instruction just no longer matched what was on the screen.

We did not change the meaning of category everywhere. That would have traded one mistake for many others. Plenty of places still needed the parent account’s category, and changing the old label would have made those places unreliable too.

Instead, we added one new, plainly named bundle for the selected event. It carries three pieces of information: its username, its category, and its group name. The linking screen now looks for the selected event’s category first. Only when that bundle is missing does it fall back to the older parent-account label.

On paper that is a very small change. One new bundle, one place that reads it. The point was that the two different jobs finally had two different labels.

A note beside the old label

We also left a comment next to the new information. It says, in effect, that whenever the page needs the category of the selected event, it must use the new value and not the older category label. That comment matters because the old label is still sitting there, close at hand, with a name that looks perfectly reasonable.

Someone reading the code later could easily reach for category and feel sure they had found the answer. Without the note, they could put the same problem right back. With it, the trap is named at the spot where the next change will happen.

Words that quietly start meaning two things

This goes beyond web pages. A familiar word can hide a changed situation. “Current customer,” “today’s price,” “active job,” or “main contact” may have meant one thing for years. Then a new option, a new location, or a new way of looking deeper into a record makes it mean two things.

Often the system keeps moving and hands someone the wrong choice. That is harder to spot than a broken screen because it looks believable. A landscaping business might show the schedule for the main property after someone has picked a smaller job site. A school office might pull the parent record when the task is really about one student. The label makes sense. It is simply answering the wrong question.

The fix that shipped was three fields wide, a username, a category, and a group name, next to a comment that tells the next person which one to trust when a child event and its parent disagree. That comment is the only thing standing between this bug existing once and existing again under a different ticket number.

When a record can be viewed at two levels, such as an account and an event inside it, ask which level each label on the screen refers to. Give each level its own name, and leave a note beside the old label so the next change does not reuse it for the wrong job.

dxdev LESSON · paste into your AI coding agent
LESSON: A page-load global describes the account in the URL, not necessarily the record you're viewing
SOURCE: dxdev.com/everyday-ai/wrong-sport-was-quietly-deciding-the-list
WHAT HAPPENED: A site-linking admin screen filtered available organizations using a category value the server populated once at page load, always sourced from the parent account named in the URL. Once a new dropdown let admins select a child event of a different category under that same parent account, the filter kept using the parent's category and silently offered the wrong organizations, with no error. The fix added a second, explicitly-named data bundle carrying the selected event's own category, checked first, with the older parent-account category value used only as a fallback, plus an inline comment warning future readers to prefer the new value.
THE RULE: A page-scoped global populated once at load time answers "whose page is this," not "what's currently selected." Once a feature lets those two diverge, code that needs the current selection must read a distinctly-named value, and the old global needs a comment steering people away from it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any page-load-time global, such as category, region, or account type, used in a filter or decision without verifying it still matches the currently selected sub-record after a nested-selection feature was added.
  2. Any newly divergent "selected X" value that lacks its own explicitly named variable or bundle distinct from the original page-level global.
  3. Any reused, generically-named variable with no comment warning that a newer, more specific replacement value exists and should be preferred.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.