Allow modification of user vm details if user.vm.readonly.details is empty

[Pearl1594]

Description

This PR fixes: #10305
Currently when the global setting 'user.vm.readonly.details' is cleared, it sets the global setting value to NULL. Querying a global setting whose value is null returns the default value. Hence, updating this specific global setting value to "" as opposed to NULL.

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

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 15.30%. Comparing base (c1bc57b) to head (a970680).
Report is 24 commits behind head on 4.19.

Files with missing lines	Patch %	Lines
.../cloud/configuration/ConfigurationManagerImpl.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               4.19   #10456      +/-   ##
============================================
+ Coverage     15.16%   15.30%   +0.13%     
- Complexity    11302    11513     +211     
============================================
  Files          5408     5413       +5     
  Lines        473931   485627   +11696     
  Branches      57844    62331    +4487     
============================================
+ Hits          71866    74314    +2448     
- Misses       394034   403077    +9043     
- Partials       8031     8236     +205     

Flag	Coverage Δ
uitests	4.19% <ø> (-0.10%)	⬇️
unittests	16.04% <0.00%> (+0.15%)	⬆️

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.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Pearl1594]

@blueorangutan package

[blueorangutan]

@Pearl1594 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.

[weizhouapache]

@Pearl1594
would be good to add a parameter to ConfigKey to indicate whether use default value if empty ?

[Pearl1594]

@Pearl1594 would be good to add a parameter to ConfigKey to indicate whether use default value if empty ?

Currently when value is null, it picks up the default value, but in this case, we do not want it to use the default value. Unless I understood you wrong @weizhouapache

[DaanHoogland]

@Pearl1594 would be good to add a parameter to ConfigKey to indicate whether use default value if empty ?

Currently when value is null, it picks up the default value, but in this case, we do not want it to use the default value. Unless I understood you wrong @weizhouapache

Yes, @Pearl1594 , but I think it is still good to use a ConfigKey and let users set it explicitely to "".

[weizhouapache]

@Pearl1594 would be good to add a parameter to ConfigKey to indicate whether use default value if empty ?

Currently when value is null, it picks up the default value, but in this case, we do not want it to use the default value. Unless I understood you wrong @weizhouapache

@Pearl1594 would be good to add a parameter to ConfigKey to indicate whether use default value if empty ?

Currently when value is null, it picks up the default value, but in this case, we do not want it to use the default value. Unless I understood you wrong @weizhouapache

Yes, @Pearl1594 , but I think it is still good to use a ConfigKey and let users set it explicitely to "".

yes. using ConfigKey is more generic, it is easier to support more configurations in the future, for example user.vm.denied.details.

[blueorangutan]

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