[NEW] Allow user's default preferences configuration

[goiaba]

@RocketChat/core

Closes #3887

This improvement allows to set default values to be used in user's preferences. It creates a new section named "Default User Settings" into "Accounts" section where default configurations can be set.

[goiaba]

@RocketChat/core

It would be nice if someone could review this PR. :-)

[joshuamorse]

I would love to see this merged!

[danieljhochman]

+1 Would also love to see this merged.

[rodrigok]

@goiaba This will change the values to the default ones just when the user save his profile.

Using that solution you will update the values and lost the state undefined, so if we change one setting on admin from, lets say, false to true there is no way to update the users to the new value cuz we can't know if the user has no value defined or if he set the value to false and don't want to change it to true.

The correct implementation for this is create a helper function to return the user's setting instead of accessing the user.preferences.settings..., the helper should receive the user object of id and the preference name/path to return, check the preference and return it if exists or return the setting from admin area if it does not exists.

What do you think @goiaba ?

[goiaba]

@rodrigok You mean we should replace every users.settings.preferences.<a-key> in the code by something like getUserPreference(userId, preferenceKey [,fallbackValue])?

The getUserPreference method would be responsible by choosing between the default value (when the user value is undefined) and the value the user set. If so, I like this approach.

[rodrigok]

@goiaba Exactly that :) thanks

[goiaba]

I'm wondering why this if is necessary here. Why are all the groups already expanded (and consequently the expand class does not exists in the html) when the test reach the Accounts section?

[rodrigok]

I have no idea 😄

[goiaba]

@rodrigok I did some stuff here but need help to test accordingly. Too many changes...

[rodrigok]

This part is not good, we was getting only users that did change their configurations, not all users as this code does now.

[goiaba]

@rodrigok Actually, as I didn't touch the userIds list and we are using a findByIds function, I think we are getting the same users, but now returning all their preferences. Or the fields argument generates something like a where clause?

[rodrigok]

🤦‍♂️ You're right, was too much code to read 😄

[rodrigok]

Did you change Desktop_Notifications_Duration to Accounts_Default_User_Preferences_desktopNotificationDuration right? Is there a migration for that?

[rodrigok]

Same for Desktop_Notifications_Default_Alert and Mobile_Notifications_Default_Alert

[goiaba]

Right, I forgot the migration script. :-( I Will work on it.

[rodrigok]

@goiaba It looks awesome, reviewing the code I had 2 main concerns:

1. Migration for certain values you changed
2. The sendNotificationsOnMessage can increase the process load cuz we are returning all users to iterate over now