Skip to content

Comments

[DC-135] feat: introduce system based configuration aka group policy#12367

Open
DeepDiver1975 wants to merge 17 commits intomasterfrom
feat/global-configuration
Open

[DC-135] feat: introduce system based configuration aka group policy#12367
DeepDiver1975 wants to merge 17 commits intomasterfrom
feat/global-configuration

Conversation

@DeepDiver1975
Copy link
Member

@DeepDiver1975 DeepDiver1975 commented Oct 9, 2025

Background

When the client is installed in a bigger organization via tools like Microsoft SCCM (now known as MECM) or similar tools it can be required to specify some pre-configured values.
Platform specific configuration storage shall be used (e.g. registry on MS)

Solution

See DC-228.

@update-docs
Copy link

update-docs bot commented Oct 9, 2025

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

@DeepDiver1975 DeepDiver1975 changed the title feat: allow account setup configuration via system based configuratio… [DC-135] feat: allow account setup configuration via system based configuratio… Jan 16, 2026
@DeepDiver1975 DeepDiver1975 force-pushed the feat/global-configuration branch from f445526 to e40cda6 Compare January 16, 2026 14:08
…d settings from a system location. skipUpdateCheck is using SystemConfig already. Proxy settings will follow
@DeepDiver1975 DeepDiver1975 changed the title [DC-135] feat: allow account setup configuration via system based configuratio… [DC-135] feat: introduce system based configuration aka group policy Jan 16, 2026
@DeepDiver1975 DeepDiver1975 marked this pull request as ready for review January 16, 2026 16:06
if (connection.isEmpty())
con = defaultConnection();
if (_systemConfig.skipUpdateCheck()) {
return true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similar to comment for moveToTrash I think this is very confusing and goes against the idea that system config takes precedence and does the resolving

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the comments in the main PR, if this is going to stay I would like the value resolution to move to the SystemConfig so we don't have cross dependencies, and there is no chance of getting the wrong one (eg the systemconfig value vs the configfile value, which may be different)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is going to stay, so the evaluation and availability of skipupdatecheck value needs to move to system config impl

I think we should also consider a different name for that class since it's more like a collection of fixed app values, which may or may not come from an actual system config, so the current name is misleading.

fallback = getValue(skipUpdateCheckC(), QString(), fallback);

QVariant value = getPolicySetting(skipUpdateCheckC(), fallback);
QVariant value = getValue(skipUpdateCheckC(), QString(), fallback);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not understand this at all. please add a comment to explain it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this actually needs to move to the system config so maybe it just goes away, hope hope!

@erikjv erikjv self-assigned this Feb 2, 2026
@DeepDiver1975
Copy link
Member Author

docs have been added: owncloud/docs-client-desktop#681

@erikjv
Copy link
Contributor

erikjv commented Feb 4, 2026

What's left is the skipUpdateCheck, which has the same problem as the moveToTrash. I propose we remove it for now, so we can close this PR, and do further work in another PR.

About which config value has a higher priority, and which class resolves the: I think there are no settings left that come from the config and the system config. So I propose to fix this in another PR too.

@DeepDiver1975
Copy link
Member Author

What's left is the skipUpdateCheck, which has the same problem as the moveToTrash. I propose we remove it for now, so we can close this PR, and do further work in another PR.

We need to keep this as a functional parity to the currently documented mechanism - see https://doc.owncloud.com/desktop/6.0/automatic_updater.html#preventing-automatic-updates

For the specific case the current implementation is valid


bool SystemConfig::allowServerUrlChange() const
{
// If a theme provides a hardcoded URL, do not allow for URL change.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this correct? My understanding was: if the system config defines the url we should take that value AND the allow change value.

else the theme is in play and any theme url = absolutely you can't change it

this seems to mix them?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted this to behave exactly as described. If a URL is hardcoded in the theme that is it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then please update the description to make that abundantly clear. this detail should also go in the jira story for this pr

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

along with an explanation of how this jives with PMFR-499

Copy link
Contributor

@modSpike modSpike Feb 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per group discussion we decided that indeed, if a system config override is allowed, and a URL preset is defined in the system config, this always takes priority over any other setting.

// a theme can provide a hardcoded url which is not subject of change by definition
auto serverUrl = Theme::instance()->overrideServerUrlV2();
if (!serverUrl.isEmpty()) {
return serverUrl;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is wrong, too. The idea of the system config is it can "override" anything else. if we take the theme url by default, Kiteworks distributions can never override it with this impl

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above - same explanation

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

per latest above: I am not sure why this should be a system config setting at all.

If org provides any url (via config or theme) the url should not be editable. If it's not that simple I need to know why.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

per discussion we do need this value and it will be evaluated according to scheme described in DC-228

return _skipUpdateCheck;
}

OpenIdConfig SystemConfig::openIdConfig() const
Copy link
Contributor

@modSpike modSpike Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openIdConfig should have an isEmpty/isValid (or similar) impl so we don't have to magically guess which values can be undefined

in fact all possible values need to be defined to pass an "isValid" check. We need this to validate system config then fall back to defaults if the config is mis-defined

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also I would fill the member with values from the theme if that is where they are coming from so it doesn't need to be reevaluated on subsequent gets

#include "common/asserts.h"
#include "common/utility.h"
#include "common/version.h"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stinky!

see my previous comments about avoiding circular deps between the settings classes. I think we have decided any values "in common" should be resolved in the systemConfig from here out

@modSpike
Copy link
Contributor

modSpike commented Feb 6, 2026

meet results = we have a theme switch that determines whether sysconfig can override other app settings. If this is true, we always take system config value as highest precendence. If no value is provided in the config, we fall back to previous methods of determining the value.

this pr should be updated to refer to DC-228 since it has full details of the reqs.

auto theme = Theme::instance();

if (theme->allowSystemConfigOverrides()) {
if (system.contains(OidcClientIdKey) || system.contains(OidcClientSecretKey) || system.contains(OidcPortsKey) || system.contains(OidcScopesKey)
Copy link
Contributor

@modSpike modSpike Feb 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the bulk check using ||
Just because one of those exists in the system config doesn't mean any of the others will be there. I don't understand the purpose.

I think for this one in particular, since we really want ALL values to be filled even with empty strings, I would just do system.value(key, QString()).toString on each of these, do the ports thing separate, then load it all into an openIdConfig and check isValid.

if not load from theme.

I would also break this down into loadOpenIdConfigFromConfig and loadOpenIdConfigFromTheme as this is pretty difficult to read.

openIdConfig fromSystem = loadOpenIdConfigFromConfig
if fromSystem.isValid
_openIdConfig = fromSystem
else
_openIdConfig = loadOpenIdConfigFromTheme

is a lot simpler to understand

// ini is used on macOS in contrary to plist because they are easier to maintain.
// Note: rev-domain notation and lowercase is typically used.
return QString("/Library/Preferences/%1/%2.ini").arg(theme.orgDomainName(), theme.appName());
return QStringLiteral("/Library/Preferences/%1/%2.ini").arg(theme.orgDomainName(), theme.appName());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's with putting the QStringLiterals back?

SystemConfig::SystemConfig()
{
const bool allowSystemConfigOverrides = Theme::instance()->allowSystemConfigOverrides();
auto format = Utility::isWindows() ? QSettings::NativeFormat : QSettings::IniFormat;
Copy link
Contributor

@modSpike modSpike Feb 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why load the QSettings if allowSystemConfigOverrides is false?
Later thought: I think the most readable impl here would be:

load the values from theme (or wherever default should come from). then

if allowOverrides:
load the settings.
if settings.contains(key) replace what came from the theme with the override

this eliminates some really ugly if/else evals AND makes the override concept really clear.

// If a theme provides a hardcoded URL, do not allow for URL change.
_allowServerURLChange = Theme::instance()->overrideServerUrlV2().isEmpty();
}
_skipUpdateCheck = system.value(UpdaterSkipUpdateCheckKey, false).toBool();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eh - is it really safe to default skip update check this way? meaning if we are allowing the config to set this, if the value doesn't exist is it really just as simple as "false" (after all the rigamarole around this I really am not sure anymore). It also needs some explicit value anyway in the case that allowOverrides is false, in which case the settings should not even be checked

#include "accessmanager.h"
#include "account.h"
#include "config/systemconfig.h"
#include "configfile.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this go?

}

bool ConfigFile::skipUpdateCheck() const
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

point me to where the old config value is scrubbed from the user file please - I haven't seen it

void setValue(const QString &key, const QVariant &value);

private:
SystemConfig _systemConfig;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

YES! thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants