Hardcoded web options

[kobergj]

Fixes #4921

[ownclouders]

💥 Acceptance test Web-Tests-ocis-smoke-ocis-storage-1 failed. Further test are cancelled...

[mmattel]

LGTM from docs pov

[micbar]

seems that we have some fallout here from the options.

@JammingBen Any ideas how that could break the selenium tests?

[JammingBen]

https://host.docker.internal:9200/config.json returns a lot more options now.

Before:

After:

Note that options holds a lot more items. E.g. it now has sharingRecipientsPerPage: 0, which overwrites Web setting it to 200 per default. As a result, no sharing recipients will be shown -> failing pipeline.

Is it desired for oCIS to return all those values now? If so, the default values have to be implemented in oCIS I suppose.

[micbar]

@JammingBen Thanks for digging into it. We need to omit empty values to use the web defaults.

[micbar]

this one was missing

[micbar]

@JammingBen @kobergj @mmattel
I added some defaults.

Ocis default is now

{
  "previewFileMimeTypes": [
    "image/gif",
    "image/png",
    "image/jpeg",
    "text/plain",
    "image/tiff",
    "image/bmp",
    "image/x-ms-bmp"
  ],
  "sharingRecipientsPerPage": 200,
  "sidebar": {
    "shares": {
      "showAllOnLoad": false
    }
  },
  "routing": {
    "idBased": true
  },
  "contextHelpersReadMore": true
}

@kulmann FYI

[micbar]

Some empty defaults are omitted on the json object. They are relying on the web default.

Please speak up if you think that we should make all of the defaults explicit.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[mmattel]

Consider before merging:

Following point for ease of readbility/identification:
Current:
yaml:"href" env:"WEB_OPTION_FEEDBACKLINK_HREF"
yaml:"OpenAppsInTab" env:"WEB_OPTION_OPEN_APPS_IN_TAB"

For naming the envvars to identify its purpose we have set that they start with: WEB_OPTION_ which is good as we can identify them very easy. But looking for the yaml version, we "only" have href.

If one is looking for all options that configure the webui, not the web service itself, he can clearly identify them in the envvars but not in the yamls.

Proposal:
Start all yamls that are related to configure webui options start with option. This would ease identify them compared to that what we currently have in this PR like:
yaml:"optiontHref" env:"WEB_OPTION_FEEDBACKLINK_HREF"
yaml:"optionOpenAppsInTab" env:"WEB_OPTION_OPEN_APPS_IN_TAB"
...

This also would help documenting that there are options to configure the webui behaviour as I could then reference to a common name component in both the envvars table and the yaml table.

[micbar]

@mmattel The yaml is nested:

web:
  options:
     feedbacklink:
        href: https://www.example.com

[kulmann]

Some empty defaults are omitted on the json object. They are relying on the web default.

Please speak up if you think that we should make all of the defaults explicit.

I would prefer to define the defaults implicitly in web. I need to define them there anyway because:

• oc10 needs defaults as well
• any newly introduced config option would need a roundtrip to the ocis repo first
• I don't want to manage defaults in two repos (ocis and web)

[mmattel]

I would prefer to define the defaults implicitly in web

To make admins aware about the implicit setting made by the webui, we could add what is implicit set in the envvar description. Else, how does an admin know what is configured?

[kulmann]

I would prefer to define the defaults implicitly in web

To make admins aware about the implicit setting made by the webui, we could add what is implicit set in the envvar description. Else, how does an admin know what is configured?

Mentioning the defaults from web in the env var descriptions is a good idea, yes.

[micbar]

Mentioning the defaults from web in the env var descriptions is a good idea, yes.

What is missing?

I added some.

[micbar]

The feedback link defaults are already mentioned. The rest is IMO part of the ocis defaults and thereby documented.

Probably missing:

• what about the xhr timeout option @kulmann

[kulmann]

• what about the xhr timeout option @kulmann

Not relevant for oCIS as we use TUS there.