Make language setting available via graph user (read & write)

[kulmann]

Is your feature request related to a problem? Please describe.

Actually two ideas:

1. ownCloud Web currently has quite some boilerplate code to fetch or update the current value of the language setting. Using the anyways generated graph client would reduce code complexity in ownCloud Web.
2. the settings service currently validates the provided value on save. The language is actually something that should be defined by the respective client. At the moment the settings service holds a hardcoded list of available languages. Just having a language attribute on the user data type and being able to update that to any string would be much appreciated. That way ownCloud Web could define the available languages based on translation coverage from transifex.

Acceptance Criteria

• We havelanguage prop in GET /me and GET /users/{user-id}
• Clients can set Being able to set any alphanumeric value in PATCH /users/{user-id}
• Clients can set the language during the POST request to create a user

NOTE: we removed the requirement to do any admin related read or write with the preferred language because that would be a major change to the settings service. The settings service can currently only read and write settings for the acting user.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[dschmidt]

owncloud/web#9243 (comment)

[mmattel]

@2403905 we just discussed language a view minutes ago, maybe this one is interresting for you too.

[butonic]

We will extend the libregraph user resuource with a preferredLanguage property, following MS graph: https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0#properties

Property	Type	Description
preferredLanguage	String	The preferred language for the user. The preferred language format is based on RFC 4646. The name is a combination of an ISO 639 two-letter lowercase culture code associated with the language, and an ISO 3166 two-letter uppercase subculture code associated with the country or region. Example: "en-US", or "es-ES". Returned by default.

Note: Clients can store en but need to be able to interpret en-US in case another client stores a region code

To set the language to english:

PATCH https://cloud.ocis.test/graph/v1.0/me
Content-type: application/json

{
  "preferreddLanguage": "en"
}

when successful will return a HTTP/1.1 204 No Content response.

[butonic]

To persist the language setting we have to use the settings service, as it contains the currently configured language of the user. We also cannot use the User resource of the CS3 API to store the language, as it has no language property. For the LDAP backend we could use the inetOrgPerson optional preferredLanguage attribute, but it might be readonly.

To avoid problems with these backends we will stick to the settings service at the cost of making an additional request to the settings service (which requires a new grpc client) that can be aquired with eg.:

	traceProvider, err := tracing.GetServiceTraceProvider(cfg.Tracing, cfg.Service.Name)
	if err != nil {
		l.Error().Err(err).Msg("cannot initialize tracing")
		return err
	}

	grpcClient, err := grpc.NewClient(
		append(
			grpc.GetClientOptions(cfg.GRPCClientTLS),
			grpc.WithTraceProvider(traceProvider),
		)...,
	)
	if err != nil {
		l.Error().Err(err).Msg("cannot create grpc client")
		return err
	}

	valueService := settingssvc.NewValueService("com.owncloud.api.settings", grpcClient)

[dragonchaser]

can we close this now?