Remove hardcoded UI logic in app restoration over existing instance #7843
Description
Currently, the replaceExistingDisabled function in the RestoreSingleInstanceModal Vue component (see ns8-core, core/ui/src/components/backup/RestoreSingleInstanceModal.vue) uses a hardcoded array of module names to determine whether an app can be restored over an existing instance. This is flagged with a FIXME in the code. A more robust and maintainable solution would be to obtain this information from the backend API, rather than hardcoding it in the UI.
Proposed solution
- Extend (or add) a backend API that returns whether a given module can be replaced/restored over an existing one.
- The UI should use this API to determine the eligibility, removing the hardcoded restriction in the Vue component.
- Ideally, the API should return this eligibility together with the other module or instance data required during restoration.
- If one of the APIs already invoked in RestoreSingleInstanceModal (e.g., list-modules, determine-restore-eligibility, etc.) could be extended to return this information, it should be preferred.
Alternative solutions
- Continue maintaining the hardcoded list in the UI (not recommended: leads to bugs, inconsistent behavior, and technical debt).
- Move the logic to a configuration file shipped with the frontend (still suboptimal versus API-driven approach).
Additional context
See the FIXME in RestoreSingleInstanceModal.vue, function replaceExistingDisabled. The modules currently hardcoded are: ["samba", "loki", "mail", "ejabberd", "nethvoice-proxy"].
The backend should provide a reliable, maintainable source of truth.
See also
- https://github.com/NethServer/ns8-core/blob/main/core/ui/src/components/backup/RestoreSingleInstanceModal.vue
- Discussion https://mattermost.nethesis.it/nethesis/pl/a3ihuk748tnnxeici9hftrffac
Thanks to @stephdl