Portal Settings Were Not Kept - edmozley/freeitsm GitHub Wiki

The portal settings screen forgot what you saved

Reported in #151 · Fixed in #1981 · Ships in 2.7.0

What you saw

On System → Self-service portal:

The Background section was empty - no pattern swatches at all - until you pressed Save, and then they appeared.
Changing a colour or a pattern, saving, and refreshing put everything back to the defaults.
Saving again from there overwrote your real settings with those defaults.

That last point is what made it worse than it looked. It was not only that the screen forgot: if you pressed Save on the forgetful screen, it also switched off Let people close their own ticket and Show people the equipment assigned to them if you had them on.

It affected 2.5.0 and 2.6.0.

What was actually wrong

Nothing was wrong with saving. The settings were stored correctly every time. The screen simply never read them back.

The page runs a short start-up routine when it opens. It wires up the two colour boxes, then loads the saved settings:

document.addEventListener('DOMContentLoaded', function () {
    sspBindColour('sspHeaderColour', 'sspHeaderColourPick');
    sspBindColour('sspTableColour', 'sspTableColourPick');
    document.getElementById('sspLogo').addEventListener('input', sspPaintPreview);
    sspLoad();
});

sspLogo was a text box where you typed the path to a portal logo. In 2.5.0 it was replaced by a proper file upload button, because nobody could answer "type the path to a file only the server can create". The box went. This one line that listened to it stayed.

document.getElementById('sspLogo') now finds nothing and returns null. Asking null to addEventListener is an error, and an error stops the rest of the routine. So sspLoad(), the line that fetches your saved settings, never ran.

Every symptom follows from that one line:

Symptom	Why
No pattern swatches	They are drawn by the same code that fills in the loaded settings, so they were never drawn
Swatches appear after Save	Save's reply carries the stored settings, and painting them draws the swatches
Settings "revert" on refresh	They had not reverted. The form was showing its built-in defaults, not what was stored
Saving again loses your settings	Save sends whatever the form shows, which was the defaults

🔑 Removing an element from a page is a two-sided change. The HTML went; the script that referred to it did not, and nothing complains until the page is opened in a browser. PHP's syntax check passes, and the server returns a perfectly good page. The error only exists in the browser's console.

A second, smaller one on the same screen

The Remove button beside the logo was visible even when there was no portal logo to remove. The page correctly marks it hidden, but buttons here are styled display: inline-flex, and a display rule in a stylesheet beats the hidden attribute. It is a known trap in this codebase and has turned up before.

How it was fixed

The stale line is gone, with a comment where it stood explaining what happened. Nothing that can throw now sits between the colour set-up and sspLoad().
[hidden] wins inside the logo row, so Remove only shows when there is a logo.

Was it anywhere else?

Checked rather than assumed. Every getElementById('...') in every PHP page was compared against the ids that page, or something it includes, actually defines. There were eleven hits:

One was this bug.
Ten were harmless: already guarded with an if (el) check, defined in an included file, or defined inside a translated sentence. For the last kind, all 23 languages were checked to make sure none had dropped the id while translating.

Files changed

File	What changed
`system/self-service/index.php`	the stale `sspLogo` listener removed; `[hidden]` forced inside the logo row

How it was proved

The broken version first. On a test install, non-default settings were stored (an orange header colour and the Dots pattern) and the page was opened in Chrome. It showed the default colour and no swatches - the bug, reproduced exactly.
Then the fix, same install and same stored values: the orange header, and Dots selected among six swatches.
The Remove button was checked in the same screenshots, visible before and gone after.

What this means for you

If you pressed Save on this screen in 2.5.0 or 2.6.0, your portal may now be running on defaults. After updating, open System → Self-service portal, check that it shows what you expect, and put back anything that was lost, particularly those two switches.