Skip to content

WIP: Explore instance-level service inheritance Option B

Andy Schoenen requested to merge jira_instance_inheritance_experiment into master

What does this MR do?

This MR is to explore option B for instance level services described in #213568 (closed). For now, we only want to support Jira.

The project service should inherit from the instance level service. It should also be possible to override the instance level setting.

Here are the development steps we did to build a proof of concept for this solution:

Steps

1. Hide all services but Jira in instance level settings

Commit: !29044 (e9b0d96d)

2. Inherit data field settings from instance level

Commit: !29044 (b612debe)

This overrides the getters, so they return the instance level setting.

3. Inherit boolean accessors

Commit: !29044 (7afb43bf)

This commit adds getters for the boolean settings stored in the services table. It brought up a problem when on the project level a service showed up as active even though a service record for that project didn't exist. This is because we initialize all services on the project integrations settings page. Even though the record is not saved yet, it will inherit the active value from the instance level service.

4. Show services that are not persisted as not active

Commit: !29044 (6b65cd3e)

This lists non persisted services not as active to fix the problem described in step 3.

5. Allow overriding the inherited value in data fields

Commit: !29044 (5b28fbe1)

Let getters only returns the inherited value if the original value was nil. This would make it possible to override a value.

6. Allow overriding service accessors

Commit: !29044 (0ad74c14)

Allowing override for the boolean columns on the service table requires allowing NULL for those columns. However inheriting the active value and therefore having active = NULL brings up a problem. We often query for services where active = true but since the column is now NULL, those services wouldn't show up any more.

7. Fix service scopes

This step would require to tweak the service scopes to return services based on the instance level setting.

A possible solution could be something like this: !29044 (e8858bd5)

8. Populate project services

When a new instance level service is created, we should create a new service with nil values in all projects where the service doesn't exist yet. This should also fix the problem described in 3. We might be able to revert step 4.

9. Add feature to reset all overrides.

There should be a feature to reset all project level settings to inherit from the instance level. This can be done by deleting all project level services and recreating them with NULL values. Or by setting all columns in all existing project level services to NULL.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by 🤖 GitLab Bot 🤖

Merge request reports