[Copilot]

The tzctl and wifictl modules were never imported, so the @additional_section/@additional_config registries were always empty. As a result, WPA_SUPPLICANT_CONF and LOCAL_TIME_FILE had no effect, and everything built on those registries was dead code. This PR removes it, including the JS pushConfigReboot flag, which could no longer become true.

• Modules and settings
  • Delete controls/tzctl.py and controls/wifictl.py.
  • Drop WPA_SUPPLICANT_CONF and LOCAL_TIME_FILE from settings.py and motioneye.conf.sample.
  • Trim the ENABLE_REBOOT comment that referred to wifi/time zone.
• config.py
  • Remove additional_section, additional_config, get_additional_structure, _get_additional_config and _set_additional_config.
  • Remove their registries and cache, plus the call sites in get_main, set_main, get_camera and set_camera.
  • Remove the # additional configs _-key ↔ @_-key copy loops in the *_ui_to_dict/*_dict_to_ui converters, and the @_ skip when writing config lines.
• Handlers
  • MainHandler no longer builds or passes main_sections/camera_sections.
  • ConfigHandler.set_config no longer returns and computes a reboot-needed flag from additional configs.
  • ENABLE_REBOOT is still honoured by the explicit reboot/shutdown buttons and by config restore.
• main.html
  • Remove the config_item macro, all *_sections.get(...) loops and the "Additional Main/Camera Sections" blocks.
• main.js
  • Remove the additional-section/config blocks in the four config collect/populate functions, and the additional-section hide-logic calls.
  • Remove pushConfigReboot and the reboot parameter of pushMainConfig()/pushCameraConfig(), and update all callers.
  • Remove the "this will restart the system" confirm in applyConfig, which was unreachable.

Notes for review

• ui['_client_secret'] in main_dict_to_ui is unrelated to this feature and is kept. The UI still posts it back as _client_secret, which main_ui_to_dict no longer copies to @_client_secret, so it is ignored on save.

This is fine, as client_secret is a R/O setting, which cannot be changed in the frontend. It is hence ignored intentionally when sent back. If it was ever further handled as @_client_secret, then this was unintentional.

• The data.reboot handling after a config save in the UI is kept because the restore path still uses it.

After another review iteration, data.reboot is only checked at the backup restore dialog, as only the restore handler emits it now.

• Python was only compile-checked, and the UI was not exercised in a browser.

I did that => all works still perfectly fine: No missing sections, no errors, shutdown/reboot buttons work as before. Reboot after restore works as well, though its check loop fails because the config handler returns 403 after the reboot, as of the reset session. I just updated it to use the manifest.json API, which does not require authentication, and is a very small JSON document (compared to the base path fully fledged HTML).

[MichaIng]

Remove some related newlines and adjust description of enable_reboot setting. The buttons still work well, and were never tied into the "additional" configs path.

[MichaIng]

Finally removing all this whole "additional" system admin stuff, now that tzctl isn't otherwise used anymore. I tracked down all the paths at which those could be triggered in backend and frontend, and could not find any. Then did let Copilot walk through it, which came to the same result: All dead code.

To actually make use of this, source code changes would be required, to load the modules, and call their @additional_config/@additional_section decorated functions. For tzctl and wifictl, of course this requires root, which renders it wrong for what motionEye is supposed to be: A camera/motion frontend and management UI, not a system administration UI.

I am sure those features were implemented in motionEyeOS. Code on Git(Hub) is never lost, it can always be recovered from the commit and PR history, just in case anyone every wants to work with it. But I do not see this coming, nor do I think it is reasonable to expand the scope of motionEye in such way.

For reboot/shutdown button, which is what the enable_reboot setting actually toggled, do still work well, if the run user has permissions to do that. They were never related to the "additional" features stuff. For this, as well as SMB mounts, I want to add some strictly scoped sudoers config, to optionally install via motioneye_init.

Regarding the points to review:

ui['_client_secret'] in main_dict_to_ui is unrelated to this feature and is kept. The UI still posts it back as _client_secret, which main_ui_to_dict no longer copies to @_client_secret, so it is ignored on save.

This is fine, as client_secret is a R/O setting, which cannot be changed in the frontend. It is hence ignored intentionally when sent back. If it was ever further handled as @_client_secret, then this was unintentional.

The data.reboot handling after a config save in the UI is kept because the restore path still uses it.

After another review iteration, data.reboot is only checked at the backup restore dialog, as only the restore handler emits it now.

Python was only compile-checked, and the UI was not exercised in a browser.

I did that => all works still perfectly fine: No missing sections, no errors, shutdown/reboot buttons work as before. Reboot after restore works as well, though its check loop fails because the config handler returns 403 after the reboot, as of the reset session. I just updated it to use the manifest.json API, which does not require authentication, and is a very small JSON document (compared to the base path fully fledged HTML).

[zagrim]

👍 If this indeed didn't break any "normal" functionality, great! Let's hope this also reduces some of the confusion the settings handling code tends to cause in me due to the "additional sections"...

[Marijn0]

I am sure those features were implemented in motionEyeOS. Code on Git(Hub) is never lost, it can always be recovered from the commit and PR history, just in case anyone every wants to work with it. But I do not see this coming, nor do I think it is reasonable to expand the scope of motionEye in such way.

Yeah, I don’t see anyone reviving motionEyeOS either. The last substantial activity was over six years ago. If I remember correctly, we’ve already removed some other code that was probably related to motionEyeOS. So IMO, it makes sense to clean up these remaining bits as well.