Expected Behavior - What were you expecting to happen?
Currently, if on the Project dropdown the environment have a counterpart on the Environment dropdown, the second should be preserved on project selection. For example, imagine 2 projects called GEM and the other Custom GEM, both with environments v1 and v2. If GEM / v2 is selected, and then the project is switch to Custom GEM, the Environment should be kept to v2.
Current Behavior - What happens?
Currently, in the previously described example, on project selection for Custom GEM the Custom GEM / v1 environment is selected. Although for some use cases it makes sense that this happen, it might be that the version number for 2 different projects have nothing to do with each other so jumping to the first project is the correct solution. This should also be taken into account for the possible solution.
Possible Solution
The solution is simple as keeping the environment if it exists by comparing the environment ID might be easy. This will enforce configurations to keep the same ID for the environments if they want to enable this behavior for some of them and/or prefix the ID if they want to keep it independent.
Context
User experience. E.g., in the case of related projects with similar versioning this makes sense for the user that otherwise is jumping always to the upper version of an environment.
Notes and further information
Low priority as it doesn't affect important behavior but user-experience on a use-case of configuration of projects/environments.
Feature request
Expected Behavior - What were you expecting to happen?
Currently, if on the Project dropdown the environment have a counterpart on the Environment dropdown, the second should be preserved on project selection. For example, imagine 2 projects called
GEMand the otherCustom GEM, both with environmentsv1andv2. IfGEM / v2is selected, and then the project is switch toCustom GEM, the Environment should be kept tov2.Current Behavior - What happens?
Currently, in the previously described example, on project selection for
Custom GEMtheCustom GEM / v1environment is selected. Although for some use cases it makes sense that this happen, it might be that the version number for 2 different projects have nothing to do with each other so jumping to the first project is the correct solution. This should also be taken into account for the possible solution.Possible Solution
The solution is simple as keeping the environment if it exists by comparing the environment ID might be easy. This will enforce configurations to keep the same ID for the environments if they want to enable this behavior for some of them and/or prefix the ID if they want to keep it independent.
Context
User experience. E.g., in the case of related projects with similar versioning this makes sense for the user that otherwise is jumping always to the upper version of an environment.
Notes and further information
Low priority as it doesn't affect important behavior but user-experience on a use-case of configuration of projects/environments.