[
https://issues.apache.org/jira/browse/IGNITE-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16439228#comment-16439228
]
Ilya Borisov commented on IGNITE-8200:
--------------------------------------
So here's what was happening:
The cluster edit form stores a deep clone of current cluster value, this is
what user actually edits. It changes the local value only when "cluster"
binding value changes and old/new _id properties don't match, all in order to
handle transition between "new" and uuid id values right after cluster
creation. This behavior relies on assumption that any cluster binding changes
will contain the same value because that's what user has edited. The assumption
fails to count for one additional way to edit current cluster: the import from
DB dialog. When user imports models/caches into current cluster, "models" and
"caches" properties of cluster will change, but form will ignore these, because
it only checks the id. Afterwards, if user attempts to leave the form, the form
changes dialog will ask user what they want to do with removed caches/models,
since that's the difference between initial cluster value (step 3 from issue
description) and cluster at step 4.
To fix the issue, I've added an additional check for caches/models deep
equality into $onChanges form component callback, so it will accept new cluster
value if it was imported.
> Web console: unexpected confirmation
> ------------------------------------
>
> Key: IGNITE-8200
> URL: https://issues.apache.org/jira/browse/IGNITE-8200
> Project: Ignite
> Issue Type: Bug
> Reporter: Pavel Konstantinov
> Assignee: Ilya Borisov
> Priority: Major
> Fix For: 2.6
>
>
> # initial state - there are no clusters
> # create a new one, do not save
> # open Advanced screen, save
> # import from DB, save
> # open Caches screen - unexpected confirmation about unsaved changes appear
> # click Cancel, save, open Caches again - unexpected confirmation again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
