The bug can reproduced simply by adding a new alternative id, and then editing + saving an existing one. This will cause the id that is being edited to be removed from the form.
Cause:
The fields used to create/edit an alternative id are in a standalone form (i.e. it's not part of the big form that controls the entire asset view). Instead, it's a small form that is "manually" synced back to the big form via observables. This is quite an opaque task with a lot of corner cases. In this case, a subscriber that syncs the two forms was triggered after saving the existing id, but before resetting the small form back to a non-edit state. This caused the subscriber to perceive the id as being "new", and the form as "cancelled", which is why it removes the "cancelled" id.
Solution:
Reorder the state updates so that the subscriber is executed only after the form has been fully reset.
Resolves #33.
The bug can reproduced simply by adding a new alternative id, and then editing + saving an existing one. This will cause the id that is being edited to be removed from the form.
Cause:
The fields used to create/edit an alternative id are in a standalone form (i.e. it's not part of the big form that controls the entire asset view). Instead, it's a small form that is "manually" synced back to the big form via observables. This is quite an opaque task with a lot of corner cases. In this case, a subscriber that syncs the two forms was triggered after saving the existing id, but before resetting the small form back to a non-edit state. This caused the subscriber to perceive the id as being "new", and the form as "cancelled", which is why it removes the "cancelled" id.
Solution:
Reorder the state updates so that the subscriber is executed only after the form has been fully reset.