In 'Definitions >> Networks', press the little blue "i" button beside a host in use as an authentication server; nothing appears. This information does appear in V7.403.
If you attempt to delete the host definition, you are warned that the host is in use in an auth server, so the problem appears to be in the code for the "i" button.
In 'Definitions >> Networks', press the little blue "i" button beside a host in use as an authentication server; nothing appears. This information does appear in V7.403.
If you attempt to delete the host definition, you are warned that the host is in use in an auth server, so the problem appears to be in the code for the "i" button.
That makes sense, however, if the code to display the pre-delete warning exists, then there would not seem to be as much involved in this "feature" request...
I realize that "i" is explained to the user as "where is this object in use?" I suggest that, in future versions, the developers treat "i" as if it meant "press here to see what you would damage if you were to Delete this object." That would make for more modular code.
You are right, it is not obvious why this is non-trivial.
However, it *is* non-trivial.
To understand the difference, consider how the "pre-delete" warning is actually implemented: When you hit the "delete" button (or any other button to change data, for example an "apply" button), the WebAdmin locks the Confd and sends a configuration change request to the Confd. The Confd executes the change request on a copy of the configuration storage and collects error messages along the way. In case there are no errors at all, the Confd commits the changes to the master storage, signals success to the WebAdmin and that's the end of the story. In case there is a fatal error, the Confd aborts all changes at once, rolls back whatever changes were done before the error was detected, signals utter failure to the WebAdmin, and the WebAdmin displays the fatal error message to the user, and that's game over.
In case there is a non-fatal error (like: object still in use), the Confd adds the error to his list, *continues* with the requested changes, potentially collecting more non-fatal errors (for example, the object you plan to delete might be used at more than one place), and rolls the changes back only when it's clear that all problems have been found. Finally, he hands the whole list to the WebAdmin, who will ask the user for confirmation of the whole list. In case the user confirms the list of non-fatal errors, the WebAdmin hands the confirmed list back to the Confd and triggers all the changes again. During this second pass, the Confd will typically only encounter non-fatal errors confirmed by the user, so the changes will be applied and saved to the master storage.
So (but now i'm starting at nitpicking), this is not a "pre-delete" warning, it is more like a "post-delete" warning. The point is that it's safe even when two administrators are changing stuff concurrently. Imagine you click delete, get a confirmation dialogue, start thinking about the message, perhaps even read a bit in the manual pondering it, and finally decide you agree and hit "confirm". Now what if, in the meantime, your colleague changed the configuration to use the object in question at another place where it wasn't used before? With a pure "pre-delete" warning, you would probably destroy your colleague's work by hitting "confirm". NOT so with the ASG 7.500! The Confd will detect that now, there is an additional non-fatal error you never confirmed, and you will be presented another confirmation dialogue, so nothing will be damaged.
On first sight, this suggestion sounds reasonable, but in view of the explanation given above, it would in fact rather make for more scary, more fragile, and much slower code. When you press an "information" button, you don't expect the object to be deleted, not even from a temporary copy of the storage. I will sleep better if the implementation of the "info" button works without locking the storage and doing rollbacks. [:O]
Actually, the implementation of the "info" button uses the Confd public functions get_affected_nodes() and get_objects_using_object(). These two access the Confd storage in read-only mode, and i'm convinced that's the right thing to do here. And the code *is* modular in so far as the internal implementation of del_object() uses the same two functions when figuring out what else must be changed when removing the object from the storage - but del_objects is doing *tons* of other consistency and safety checks, too, which are not needed when not actually deleting, but when just aking where it's used.
By the way, you can also call these two functions from the RAW prompt in the Confd command line client: Type "cc" at the root shell prompt, then "RAW", then "help get_objects_using_object" or "get_affected_nodes('REF_NetworkAny')" or whatever you are interested in.
Have fun,
Ingo
