Don't allow mixing project-level and instance-level provider settings
Summary
Product Analytics provider config (collector connection string, cube url / key etc) can be defined at the instance-level (admin area) and project-level. When a project-level setting exists, it is used. When it does not exist, the backend falls back to the instance-level settings.
Currently, it is possible to mix and match - have some project-level settings, and some instance-level settings. This is probably undesirable as it would mean the gitlab project is partially connected to different parts of different analytics providers.
Steps to reproduce
Configure a GitLab instance with product analytics. Set up the analytics provider in admin area.
Create a new project, and set one of the provider settings in Project -> Settings -> Analytics, e.g. collector host.
Try onboard that project, and notice that it onboards with the instance-level configurator, but shows project-level collector host within the instrumentation instructions.
Alternatively - onboard a project with a project-level provider. Then delete one of the settings for that project. It will start falling back to the instance-level setting.
Example Project
What is the current bug behavior?
We can set a mixture of project-level and instance-level settings.
What is the expected correct behavior?
-
Only a full set of project-level settings should be allowed. The settings form should validate that all 4 have been entered to allow saving.
-
The backend should check before falling back to instance-level settings, e.g. in here something like:
if (has_all_project_settings?) {
@project.project_setting.public_send(key).presence ||
} else {
::Gitlab::CurrentSettings.public_send(key)
}
Implementation plan
- Add a frontend validation that doesn't allow submitting the form unless all 4 fields are filled.
- Adds a similar backend validation.
- Updates the backend logic to use the instance-level settings if not all the fields are filled in.