Teams Buttons Did Nothing

System → Teams: the buttons did nothing

Fixed in 3.9.0 · Reported in #186 by @Dr4inder · Present in 3.7.0 to 3.8.1 · Module: System → Teams

---

The short version

On System → Teams, the list of teams never loaded - it said Loading… for ever - and pressing Add did nothing. The browser's console said:

SyntaxError: Unexpected identifier 'ticket'
ReferenceError: openTeamModal is not defined

It was reported with the interface in German, but it was broken in every language, English included, on every install from 3.7.0 onwards. Nothing was ever saved wrongly and no data was affected: the page simply could not do anything, so no team could be created or changed.

One apostrophe did it. It is fixed, and the wording around it now comes from the translation files, where an apostrophe can no longer reach the code.

---

What you saw

• The heading, the Add button and the table's column headings appeared as usual - the server draws those.
• The table itself said Loading… and never changed. The list of teams is fetched by the same script, so it never ran either.
• Add did nothing. No dialog, no message.
• The console showed the two errors above - the first one as the page loaded, before anything was clicked.

The reporter's own diagnosis was exactly right: "The initial parse error may explain why the handler is unavailable." It does, completely.

What was wrong, in plain English

A web page's buttons are wired up by a script - a program the browser reads from top to bottom before running any of it. If the browser finds a single sentence it cannot understand anywhere in that script, it refuses to run any of it. Every function the page defines, including openTeamModal, the one behind Add, simply never comes into existence. That is the second error: the button asks for a function that was never made.

The sentence the browser could not understand was a piece of English text inside the script.

In 3.7.0, Teams gained a small Check badge on any team with members but no departments (A team with no departments showed 0 tickets). Its tooltip read:

Members' ticket folders only count tickets with no department, plus their own

and it was written inside a JavaScript string that was itself wrapped in apostrophes. JavaScript uses ' to mean "text starts here" and "text ends here". So it read:

' <span class="status-badge" ... title="Members'

as a complete piece of text ending after Members, and then met the word ticket sitting loose in the code where a + or a , should have been - "Unexpected identifier 'ticket'".

The line, before and after

Before (system/teams/index.php, 3.7.0):

<td>${team.deptCount} department(s)${team.deptCount === 0 && team.analystCount > 0 ? ' <span class="status-badge" style="..." title="Members' ticket folders only count tickets with no department, plus their own">Check</span>' : ''}</td>

After (3.9.0):

<td>${escapeHtml(t('tickets.settings.team_counts.departments', { count: team.deptCount }))}${team.deptCount === 0 && team.analystCount > 0 ? ` <span class="status-badge" style="..." title="${escapeHtml(t('tickets.settings.team_counts.check_title'))}">${escapeHtml(t('tickets.settings.team_counts.check'))}</span>` : ''}</td>

Two changes, and each one alone would have fixed the crash:

1. The words came out of the code. The tooltip, the word Check, and the "N department(s)" and "N analyst(s)" counts are now in lang/en/tickets.php under team_counts, read with t(). A translation file is a PHP string, not code the browser parses, so its apostrophes are just apostrophes.
2. The wrapper became a backtick. The inner piece is now a template string (`), like the line around it - so even if somebody puts English back in, an apostrophe inside it is just a character.

escapeHtml() on each piece means a translation containing " or < can no longer break the HTML either.

🎓 The wrong turn that looked right

The same commit added another piece of English to the same function - the warning banner above the table - and that one was written correctly:

+ 'Someone in a team only gets ticket folders and counts for that team\'s departments, so these members\' folders only count tickets with no department, plus their own. '

Every apostrophe there is escaped with a backslash (\'). The badge, written a few lines further down, was not. So the commit looked careful - the long, obviously risky sentence had been handled - and the short tooltip, which nobody thought of as risky, was the one that broke the page.

The lesson is not "remember the backslash". It is don't put words in the code at all. A translation key cannot contain the bug, and it was needed anyway: the banner and the badge were English on every install, including German ones, so the fix moved the banner's text into the translation files too.

Why nobody noticed for two releases

The 3.7.0 fix was verified carefully - but where the change was: the ticket counts were compared byte for byte before and after, and against an independent database count. What was never done was open System → Teams in a browser and press a button. The page still returned HTTP 200, PHP's own syntax check (php -l) passed, and the HTML it produced was perfectly valid. All of that is true of a page whose script will not run, because the broken thing is JavaScript, and nothing in that list reads JavaScript.

This is the gap the project's notes call rendered markup is not working JavaScript: the only check that catches it is a real browser loading the page and reporting what its console says.

Was it only this page?

Yes - and that was checked rather than assumed, because the earlier write-ups in this list (#70, #78) both turned out to be several places, not one.

• Every page, in a real browser. All 84 analyst pages that a module or System opens on - every System area, and each module's main page and settings page - were loaded in headless Chrome after the fix, and the console was read for SyntaxError and ReferenceError. None had one. (Knowledge hung the test browser during the sweep and was stopped, so its clean result comes from the same check run earlier the same day.)
• The same pattern in the code. A search for an apostrophe inside a title="…" that is built inside a script found two other candidates (Projects' budget table, the Forms list); both build the text from translations through an escaping function, so neither can break this way.

Why only English was swept: the translation files reach a page's script as JSON (window.translations), which is encoded safely whatever the language. Words written straight into the script are the same in every language - so a page that parses in English parses in German.

📁 Files changed

	File	Change
🟦	system/teams/index.php	The badge, the warning banner and the counts read their words with t(), escaped; the badge is a template string
🟩	lang/en/tickets.php	New settings.team_counts block - the counts, the badge and its tooltip, and the warning's sentences

Other languages fall back to the English wording until they are translated, which is how every new string arrives.

How it was verified

• Reproduced first, on the dev install, in German and in English: the console showed Unexpected identifier 'ticket' on page load. The German run used an administrator with no saved language and the browser set to German, so the page really rendered in German.
• After the fix, in a real browser (headless Chrome), as an English administrator and a German one: no console error, openTeamModal exists, and Add opens the team dialog.
• The warning text was built from the new strings with a hostile team name - O'Brien <b>Team</b> - and the name came out as plain text, with the link still a link.
• Control: the same console check reports a deliberate ReferenceError on a test page, so a clean result means the page really is clean.

What this means for you

• Upgrade to 3.9.0 and System → Teams works again.
• On 3.7.0 to 3.8.1 there is no workaround: teams are only managed on this page, and the REST API has no teams resource.
• Nothing needs repairing afterwards: no team was ever saved wrongly.

Related pages

• A team with no departments showed 0 tickets - the 3.7.0 fix whose warning badge caused this
• Bugs resolved
• Internationalisation - why words belong in lang/, not in the code