So the only workaround, at least for this one setting, is that the API does not enforce these settings, only the UI.  I was able to create a quick script to make an API call to update the specific feature for "Collect Clients' History Data": https://github.com/mbentley/docker-omada-controller/issues/217#issuecomment-1184864183

And copied here for simplicy sake:

#!/bin/bash

# set variables
OMADA_URL="https://localhost:443"
USERNAME="admin"
PASSWORD="password"

# get controller id from the API
CONTROLLER_ID="$(curl -sk "${OMADA_URL}/api/info" | jq -r .result.omadacId)"

# login, get token, set & use cookies
TOKEN="$(curl -sk -X POST -c "/tmp/omada-cookies.txt" -b "/tmp/omada-cookies.txt" -H "Content-Type: application/json" "${OMADA_URL}/${CONTROLLER_ID}/api/v2/login" -d '{"username": "'"${USERNAME}"'", "password": "'"${PASSWORD}"'"}' | jq -r .result.token)"

# set data retention (180 = 6mo)
curl -sk -X PATCH -b "/tmp/omada-cookies.txt" -H "Content-Type: application/json" -H "Csrf-Token: ${TOKEN}" "${OMADA_URL}/${CONTROLLER_ID}/api/v2/controller/history?token=${TOKEN}" -d '{"retention":180,"clientsDataEnable":true}'

  @Fae - That's true except for when you allow users to bind to ports below 1024 with something like:

sysctl net.ipv4.ip_unprivileged_port_start=0

Beside setting that directly in Linux, tools like Docker can also allow users to run containers like that with the sysctl modifying the behavior.  I, for one, have been using 443 for some time now with my controller and the change in this behavior in the UI is blocking from changing settings which seems like a poor experience.  Reading the value of ip_unprivileged_port_start would tell if the port can be set safely or not and at least let users, such as myself, continue to use port 443.

I know many people have requested and use the port mapping config to map to 443 as I've added the feature to change the port on first setup by modifying the properties file based on the value set by an environment variable before the app initially starts which it will allow 443 to be used then.

  @Fae - Awesome, much appreciated!  Thanks for taking the use case into consideration!

Unfortunately in version 5.5.6, the user interface also introduced showing the "HTTP Port for Controller Management" setting option.  This field has the same issue as port 443 did previously.  Could we have an exception added for allowing port 80 with a similar same warning in a future release?

@Fae - bumping this up to see if we can do something similar for port 80 as that was also added and is now blocking the same settings page from being updated.

It looks like the UI has been updated as of 5.7.4 to now include port 80 but it looks like the backend API might not have been updated to reflect the change as it still throws an error when trying to save saying that the port is out of range.

Confirmed Matt's findings.

While the help message to the right of the text entry field indicates that "80" is a valid field value for the HTTP the backend API returns the following response when "80" is sent for the value of webPort.manageHttpPort

{"errorCode":-30033,"msg":"The HTTP or HTTPS port is out of range."}

443 is accepted and persists through reboots for the HTTPS port, so at least that works.

@Fae is it possible to fix this issue?

Even in the latest 5.9.9 this is still not fixed fully.