If there is an error when saving an entry in Web Admin I would expect the data in the fields to be untouched. A scenario: You create a new subcluster and add a lot of users and groups. You press save but you forgot to add the agents to the subcluster. Then the detailed view is closed and your user lists are gone. This same kind of scenario can happen on more pages - Desktop Customizer -> Menu Structure - Desktop Customizer -> Application Groups - Locations -> Locations - Locations -> Terminals For these pages I tested to save with empty name or already taken name. In general it would be nice if the data was not lost in these cases.
Profiles -> Profile List has the same problem when trying to save with a space in the Identification field.
Adding to the problem mentioned in comment 0, it's inconsistent across the modules whether the user is returned to the base page or remains in the detailed view upon encountering errors when trying to save a new or an existing table item. Since dev build #3108, among the 7 relevant tlwebadm modules we can attribute the following statuses (X=buggy; ✔=fine) to them concerning saving when adding New or editing Existing table items: * VSM/Subclusters New : ✔ Existing : ✔ * Profiles/Profile List New : ✔ (a bit confusing that one can save an empty id and still be granted the random id initially assigned) Existing : ✔ * Locations/Locations New : X Existing : ✔ * Locations/Terminals New : X Existing : ✔ * Desktop Customizer/Application Groups New : ✔ Existing : ✔ * Desktop Customizer/Applications (Manual) New : ✔ (although the optional 'Application Name' field disappears if saved empty when triggering errors pertaining to other fields) Existing : ✔ * Desktop Customizer/Menu Structure New : ✔ Existing : ✔
*** Bug 8113 has been marked as a duplicate of this bug. ***
One odd behavior that we noticed on the Profiles/Profile List page is that after pressing “Add new profile”, in the pop-up then pressing “Delete” without checking the confirm-checkbox, the pop-up just closes. We expect the confirm-checkbox to be required for the delete button to do anything.
Unfortunately, commit r39973 introduced a regression which causes attempts to add new terminals with existing MAC addresses to result in a state where the existing terminal is being modified in the popup, with the possibility of modifying the MAC address -- an action which is normally prohibited. It's possible this is due to the backend signaling it's still a new terminal being added -- which causes the MAC address field to be editable -- but the detailed view is actually displaying an existing terminal.
Regarding comment 2, I can no longer reproduce any problems with the popup closing on Locations/Terminals in recent builds. I tried saving a new terminal: * Without a “Terminal name” * Without a “Hardware (MAC) address” * With an invalid “Hardware (MAC) address” All of these result in nice errors being presented inside the popup. The Locations/Terminals page was likely fixed as part of commit r39973. Issues regarding the popup closing on save errors remain on the Locations/Locations page, see bug 8123.
When doing bug 284 this bug can be triggered in an additional way. 1) Go to VSM -> Subclusters in Web Admin and edit an existing subcluster (the entry should have values under fields "Agents", "Users" and "Groups") 2) For field "Max users per agent", choose the input box and type a negative number, e.g. -2. 3) Press save. 4) The correct warning is shown (Max users per agent must be a positive number.), but note that the fields for "Agents", "Users" and "Groups" are all empty. Since "Agents" requires at least one entry, the user get an error when trying to save the entry if just adding a valid number, but it's still not very intuitive why these fields disappear. Also note that when this bug triggers, both radio buttons for "Max users per agent" is unselected. If the entry is saved in this state, it will be saved as value "No limit" (max_users_per_agent = 0).
