Add IProvideEnabledStateBackend interface

[come-nc]

This allows user backends to present some users as disabled, and to manage themselves how disabling users works.
It is used in the LDAP backend to support a new option to make remnants users appear as disabled.

• The configuration option is not exposed in the UI

[come-nc]

Rebased and fixed conflicts.

@blizzz Should the configuration be global like implemented or for each ldap configuration? If we want to put in the UI we have to set it as a per-configuration setting anyway, no?

[blizzz]

@blizzz Should the configuration be global like implemented or for each ldap configuration? If we want to put in the UI we have to set it as a per-configuration setting anyway, no?

We can also add another section with global LDAP settings. We have a few of them, but none are exposed. Is there a scenario where different settings per config make sense? For me it makes more sense as a global flag, otherwise we are inconsistent across configs, potentially resulting in confused admins.

[come-nc]

We can also add another section with global LDAP settings. We have a few of them, but none are exposed. Is there a scenario where different settings per config make sense? For me it makes more sense as a global flag, otherwise we are inconsistent across configs, potentially resulting in confused admins.

Well I don’t know, a per-configuration setting can always be configured the same way for all configurations while if we make it a global setting people are stuck with it. But I have to say I do not have a particular usecase in mind.
If we make it global, can we leave it as-is and keep adding a config UI for a following PR?

Do we have a list of global settings that would make sense to appear in that UI?

[blizzz]

Do we have a list of global settings that would make sense to appear in that UI?

By the power of ack we have in app config:

• enforce_home_folder_naming_rule (i don't recall this one 😅 )
• cleanUpJobChunkSize (doc should be sufficient)
• bgjRefreshInterval (doc should be sufficient)

For completeness:

• cleanUpJobOffset (controlled by the app, background job state)
• background_sync_interval (controlled by the app, background job state)
• background_sync_prefix (controlled by the app, background job state)
• background_sync_offset (controlled by the app, background job state)

Then we also have system keys (config.php):

• ldapProviderFactory (do not expose)
• ldap_log_file (would be a candidate)
• ldapUserCleanupInterval (doc should be sufficient)

[come-nc]

Rebased and added the option to the UI.
I added it per-connection, because this is how the UI is organized, it fits nicely next to the other options in advanced.

[artonge]

Suggested change

	public function setUserEnabled(string $uid, bool $enabled, callable $queryDatabaseValue, callable $setDatabaseValue): void;
	public function setUserEnabledState(string $uid, bool $enabled, callable $queryDatabaseValue, callable $setDatabaseValue): void;

[come-nc]

I’d prefer to keep setUserEnabled wording, to match existing OCP\IUser::setEnabled.

[come-nc]

So, since I started working on this I discovered we have no method to list disabled users.
As we need to avoid doing so by calling isEnabled on all users, I intend to add a method to this new interface to list disabled users.

[come-nc]

So, since I started working on this I discovered we have no method to list disabled users. As we need to avoid doing so by calling isEnabled on all users, I intend to add a method to this new interface to list disabled users.

Done.

[Pytal]

/backport to stable26