#11285 Fixed issue of server config properties not getting rendered correctly

[arishta-dev]

Describe changes proposed in this pull request:

Problem:

The server config API returns all values as strings, including boolean values (like 'true' or 'false'). Our current code only converts those strings to actual boolean values if they exist in our ServerConfigDefaults file. This caused a few boolean values like skin_show_donate_button to be rendered as string: true.

Solution:

Added a second pass after applying defaults that looks at all config values from the API and converts any 'true'/'false' strings to proper boolean values.

Checks

• Has tests or has a separate issue that describes the types of test that should be created. If no test is included it should explicitly be mentioned in the PR why there is no test.
• The commit log is comprehensible. It follows 7 rules of great commit messages. For most PRs a single commit should suffice, in some cases multiple topical commits can be useful. During review it is ok to see tiny commits (e.g. Fix reviewer comments), but right before the code gets merged to master or rc branch, any such commits should be squashed since they are useless to the other developers. Definitely avoid merge commits, use rebase instead.
• Is this PR adding logic based on one or more clinical attributes? If yes, please make sure validation for this attribute is also present in the data validation / data loading layers (in backend repo) and documented in File-Formats Clinical data section!

Any screenshots or GIFs?

If this is a new visual feature please add a before/after screenshot or gif
here with e.g. Giphy CAPTURE or Peek

Notify reviewers

Read our Pull request merging
policy. It can help to figure out who worked on the
file before you. Please use git blame <filename> to determine that
and notify them either through slack or by assigning them as a reviewer on the PR

[netlify]

✅ Deploy Preview for cbioportalfrontend ready!

Name	Link
🔨 Latest commit	c0841ed
🔍 Latest deploy log	https://app.netlify.com/sites/cbioportalfrontend/deploys/676690ccc664ce0008b8aa8b
😎 Deploy Preview	https://deploy-preview-5070.cancerrevue.org
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[arishta-dev]

This PR fixes the issue:
cBioPortal/cbioportal#11285

[inodb]

@arishta-dev Thanks so much for all your work! As mentioned on slack this works but was thinking a cleaner solution might be to fix this in the backend code directly (ensuring it generates JSON boolean properties correctly): https://github.com/cBioPortal/cbioportal/blob/be86bae2829f86cf9aeb091d60f582ce2a5f1110/src/main/resources/webapp/config_service.jsp#L145-L150

[arishta-dev]

Hi @inodb, from what I understand, the property values are being fetched from various sources in the backend (application.properties, env variables, etc) and then being returned as Map<String, String> in the config_service API.
To achieve what you suggested, we can change the boolean data types to Object and make the API return Map<String, Object>.
Please let me know how this approach looks, if it looks good, I will put up a different PR in cbioportal repo.

    private Map<String, Object> getFrontendProperties(HttpServletRequest request, Authentication authentication) {
    String baseUrl = requestUtils.getBaseUrl(request);
    Map<String, Object> properties = new HashMap<>();
    
    Map<String, String> originalProperties = frontendPropertiesService.getFrontendProperties();

    for (Map.Entry<String, String> entry : originalProperties.entrySet()) {
        String value = entry.getValue();
        if (value.equalsIgnoreCase("true") || value.equalsIgnoreCase("false")) {
            properties.put(entry.getKey(), Boolean.valueOf(value));
        } else {
            properties.put(entry.getKey(), value);
        }
    }

[arishta-dev]

Hi @alisman I have addressed your review comments, but @inodb is suggesting an alternate approach to make the API return the correct response instead of processing it in the frontend, please TAL at my comment, if it looks good, will go with this approach. Thanks!
#5070 (comment)

[inodb]

Thanks so much @arishta-dev ! That makes sense to me, but I'll double check with @alisman regarding the approach on Monday