allow syncing single users, add verbose and very verbose output

[butonic]

fixes #27707

[tomneedham]

We should get this in 10.0.3 to help big instances sync specific users + aid scripting

[jvillafanez]

I'll have to review this once this is ready. There are some code pieces misplaced

[PVince81]

moving to "triage" for later rescheduling

[PVince81]

unfinished, moving to "planned"

[PVince81]

please post the test plan that you used when testing this

[jvillafanez]

This isn't the place to use symfony's OutputInterface nor ProgressBar. This class shouldn't know how to write in the console, and it should be limited to call the callback for each user.
The callback approach is a better choice in this case.

[jvillafanez]

I'll need someone to convince me this is a good idea.

I think @DeepDiver1975 already created a ConsoleLogger somewhere to provide a log interface connected to a symfony console output. It might be better to enrich that.

[jvillafanez]

Maybe I got confused with https://github.com/owncloud/core/blob/master/lib/private/Migration/ConsoleOutput.php which is similar to what I had in mind...

I'll recheck this

[jvillafanez]

My main concern is that we should bring back the callback approach to the sync service. The sync service should just focus on syncing, not writing; the callback will take care of writing whatever is needed, or move the progress bar, or send an email to the synced user.

If you don't like callbacks, you can create a custom interface for the sync service, so the sync service can call whatever method of the interface.

use \OCP\IUser;
public interface ISyncServiceCallback {
    public function callMeWith(IUser $user);
}

Whatever happens there isn't sync service's bussines.

[butonic]

@jvillafanez I agree that having the OutputInterface here looks messy. The OutputAdapter even more. But using the IOutput interface to log OR write verbose messages to the console does not work either, because then I have no way of finding out the verbosity level.

Let us take a step back and see if we can agree on the overall output design:

1. At any point in the code you might want to tell the admin what is going on.
   a. For web requests the output should land in the log file
   b. For CLI requests the output should land in the console (as well) so the admin knows what is happening.
2. The admin should be able to tune the verboseness as he likes.
3. Some commands, eg repair steps should always use debug level logging in case something goes wrong.
4. On an error we should always log the trace.

Can we agree on this?

The SyncService is a nice example. It is executed when a user is provisioned during a web migration (and the setupAccount should bu used by the User Manager to provision new users, instead of duplicating code). And it is executed via CLI command.

So, I agree that the SyncService should not know about writing to the console. But as a developer we still need to be able to determine how verbose we should be. The Logger uses the loglevel from the config to determine that. The CLI can be configured via the -vvv param. The OutputInterface knows how verbose messages should be, which solves the problem nicely. It also allows writing code that does not compute expensive log messages that never make it into the log because it is not set to debug, without having to get an instance of the Config to read the log level.

It would be my wish to use the OutputInterface instead of the Logger everywhere, because it is much more powerful. The classes don't need to know whether the output goes to the web, the log or the CLI, but it should be able to easily determine how verbose it should be and log accordingly.

Using a callback interface makes logging easier, but does not make showing messages to the admin any easier.

So ... I have not yet thought much about this because I think it would require rewiring the whole logging stuff. Maybe we can implement an ILogger that uses an OutputStream to log, add a getOutputStream() to the server container and then subsequently use it instead of getLogger(). The OutputStream could write to the log as well as the CLI.

Or we extend the ILogger with getVerbosity methods ... but then we still need to make it write to the console.

Meh ... @PVince81 @tomneedham @jvillafanez thoughts?

[DeepDiver1975]

@ownclouders rebase

[ownclouders]

Hey! This pull request is being rebased automatically. Please DO NOT push while rebase is in progress or your changes would be lost!

[ownclouders]

Automated rebase was successful!

[tomneedham]

Closing to stop people using this. We will reimplement this after #29669 since things brings further code de-duplication and refactoring which is necessary.