I may start from saying that described below is probably not a “real Bug”, but rather not a very logical thing (to me ), that may cause some mistakes. Please correct me if I’m wrong.
which doesn’t make a lot of sense, since Firewall will fire up the Alerted again as in #2as soon as Application will try to connect.
Sure eventually we can go to Predefined Rules Setup and fix all that by creating/adding necessary rule(s).
So, basically all that can be at least a bit confusing… and may lead to some other mistakes
Probably it would be better if the “Apply” [predefined policy] button being inactive until rule(s) were created in the first place… meaning that the empty Policy will not be created (“Cancel” is the only option).
That’s how it seems to me… but perhaps I don’t see something obvious - the purpose, which the empty Policy can serve.
Well, the thing may not have very bad implications except user with less experience may create the policy which he/she was not intended to set up…
…but I may disagree with “GUI glitch”, from programmer’s point of view
apparently you gave some GUI advice but anyway I guess that an user who took the effort to create a predefined policy only to apply it without rules may be considered already confused as well (thus confusion may actually be a precondition and not a result).
So it is a good thing that disabling the apply button as you suggested will have them remember why they got to create a new policy in the first place
until then their confusion may lead them to foresee even very bad implications if they assign a predefined policy they though filled with rules only to get alerted again like you pointed out.
Indeed this glitch ought to apply also to manually created/edited Network Security Policies as well (through the same Application Network Access Control dialog in #1). Thus there would be no need to eventually create another topic for that purpose and I guess you may agree at least on that and add mention of manually created/edited Network Security Policies to your first post as well.
But anyway do you think that OK button ought to be additionally disabled (or other solution provided) for the Network Security Policies dialog in testcase screenshot #6?
Indeed there is that blank policy testcase (predefKetarin) and related add rules for this application message but I don’t actually know what you may think about that, although you apparently pointed out that blank policies cannot be assigned using treat as option of alerts (#2).
I was not arguing with you by any means in the first place :).
My comment about “GUI glitch” was about the fact that the thing was just missed in the logic when it was programmed rather than incorrectly designed GUI.
Not a big deal in this case.
As for the solution - yes that would be the easiest way to fix it by disabling (deactivating) the “Apply” button until at least one rule is in the list (and sure disable it again when & if all rules removed during editing.
Subsequent Canceling as the only choice should remove the name created.
Probably there can be additional message/notification, about the fact that new policy was not added to the List of predefined, but that could be redundant (depends on taste of a programmer)
I see that GUI glitch was was an arguable term as you pointed out the glitch pertains GUI logic and thus it ought to be strictly considered a GUI logic glitch.
As the solution ought to to apply to Application Network Access Control dialogs thus preventing future confusion for predefined policies and Network Security Policies creation/editing, but neglecting users supposedly already confused and having blank policies, I assume we both deem that blank policy scenario unlikely to happen though a fix may be appropriate.
), that may cause some mistakes. Please correct me if I’m wrong.
