Change the value parameter of the updateConfiguration API to be required

[bernardodemarco]

Description

Currently, the value parameter of the updateConfiguration API is not required. Thus, when the API is executed and the value parameter is not specified, the attributes of the configuration set by the name parameter are returned.

updateConfiguration API call without specifying the value parameter

> update configuration name="quota.enable.service"
{
  "configuration": {
    "category": "Advanced",
    "component": "QUOTA-PLUGIN",
    "defaultvalue": "false",
    "description": "Indicates whether Quota plugin is enabled or not.",
    "displaytext": "Quota enable service",
    "group": "Miscellaneous",
    "isdynamic": true,
    "name": "quota.enable.service",
    "subgroup": "Quota",
    "type": "Boolean"
  }
}

As a consequence of that, when managing global configuration through the UI, for instance, when a configuration value is cleared and updated with a blank value, the UI sends the API call without the value parameter. Since the UI receives a successful response from the backend, it notifies the user that the setting was successfully updated, which does not actually happens.

Additionally, since that the updateConfiguration API is an API to update a resource, it should not be used to list resource details. Currently, however, it is possible to achieve such action through the API.

Therefore, aiming to improve UX, avoid possible inconsistent behaviors and maintain a semantic consistency between the API name and its actual behavior, this PR proposes to change the value parameter of the updateConfiguration API to be required.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• build/CI
• test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Screenshots (if appropriate):

How Has This Been Tested?

• Executed the updateConfiguration API through Cloudmonkey, without specifying the value parameter, and the following API response was returned:

> update configuration name="quota.enable.service"
Missing required parameters:  value

• Accessed the global settings page, updated the account.cleanup.interval configuration to a blank value and verified that a semantic error message was returned:

[bernardodemarco]

@blueorangutan package

[blueorangutan]

@bernardodemarco a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 16.42%. Comparing base (2df1ac5) to head (a66ebe4).

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #10790   +/-   ##
=========================================
  Coverage     16.42%   16.42%           
- Complexity    13549    13554    +5     
=========================================
  Files          5673     5673           
  Lines        500080   500086    +6     
  Branches      60506    60510    +4     
=========================================
+ Hits          82153    82157    +4     
- Misses       408794   408795    +1     
- Partials       9133     9134    +1     

Flag	Coverage Δ
uitests	4.00% <ø> (-0.01%)	⬇️
unittests	17.29% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 13217

[sureshanaparti]

code lgtm

[DaanHoogland]

@bernardodemarco , this means that no configuration value can be set to be empty anymore. I can think of some instances an operator would want to do such a think (like a default ldap setting (basedn or so). Is this still possible with your change?

[bernardodemarco]

@DaanHoogland, yes, it is possible. This change only encompass scenarios in which the value parameter is not included in the API request. For instance:

(all-in-one) 🐱 > update configuration name='alert.email.addresses'

Currently, the Management Server handles this situation by only returning the configuration details:

(all-in-one) 🐱 > update configuration name='alert.email.addresses'
{
  "configuration": {
    "category": "Alert",
    "component": "management-server",
    "description": "Comma separated list of email addresses which are going to receive alert emails.",
    "displaytext": "Alert email addresses",
    "group": "Management Server",
    "isdynamic": false,
    "name": "alert.email.addresses",
    "subgroup": "Alerts",
    "type": "CSV"
  }
}

When performing such API calls, the value of the configuration is not changed. To set its value to be empty, the operator needs to explicitly set the value parameter to an empty string:

(all-in-one) 🐱 > update configuration name='alert.email.addresses' value=''
{
  "configuration": {
    "category": "Alert",
    "component": "management-server",
    "description": "Comma separated list of email addresses which are going to receive alert emails.",
    "displaytext": "Alert email addresses",
    "group": "Management Server",
    "isdynamic": false,
    "name": "alert.email.addresses",
    "subgroup": "Alerts",
    "type": "CSV",
    "value": ""
  }
}

However, I've just realized that, through the UI, it is indeed a little bit awkward for the operator to clear a configuration value. It's required to clear the input field, add an empty space and submit the changes. I'll apply some UI adjustments to enhance UX there

[bernardodemarco]

@DaanHoogland, I've just committed this one 01d7c6e

Now, operators are able to clean up configuration values (i.e. set its value to NULL on the DB) for the configurations with type equal to CSV, Order, WhitespaceSeparatedListWithOptions and String.

• String configuration type:

  2025-04-30.11-36-41.mp4

• Order configuration type:

  2025-04-30.11-38-33.mp4

• CSV configuration type:

  2025-04-30.11-39-27.mp4

• WhitespaceSeparatedListWithOptions configuration type:

  2025-04-30.11-41-21.mp4

[bernardodemarco]

@DaanHoogland, I’ve identified a possible inconsistency with configurations that accept lists of values (such as those of type CSV). Their default value is an empty string, so when the resetConfiguration API is called, the value is reset to an empty string, as expected.

However, when the updateConfiguration API is used with the value parameter set to an empty string, the Management Server currently stores NULL for the configuration in the database. I believe this could lead to bugs down the line, such as potential NPEs.

I suggest opening a separate issue and PR to address this behavior, as it's not directly related to the scope of this PR. What do you guys think? (cc. @winterhazel, @JoaoJandre, @sureshanaparti)

[JoaoJandre]

@bernardodemarco +1 on separate issue.

[winterhazel]

I suggest opening a separate issue and PR to address this behavior, as it's not directly related to the scope of this PR. What do you guys think? (cc. @winterhazel, @JoaoJandre, @sureshanaparti)

@bernardodemarco addressing it separately seems better for me.

[DaanHoogland]

fine by me