Various settings not saved after RC server upgrade

Description

Recently went on major upgrade spree going from 3.18.1 all the way through 5.1.0, which included migrating to a new host (Rocky 8 instead of CentOs 7). Mongodb restored etc no issues, history intact all of that.

However, somewhere along the road it seems that certain settings do not “save” in administration panel. For instance, we want to disable the use of Avatars for users, and also converting ascii to emoji setting.

When flipping these settings, they turn gray as expected, saving settings displays “changes saved” (or what the exact text is).
However, these changes have no effect. Avatars are still displayed, ascii is still converted to emojis.

Server Setup Information

  • Version of Rocket.Chat Server: 5.1.0
  • Operating System: Rocky 8
  • Deployment Method: tar
  • Number of Running Instances: 1
  • DB Replicaset Oplog: enabled
  • NodeJS Version: 14.19.3
  • MongoDB Version: 4.4.16
  • Proxy: apache
  • Firewalls involved:

Any additional Information

Hi!

Can you find that setting directly in DB and make sure they are being saved?

If you leave the mouse on the label of the setting, it will should up the ID of that setting, like so:

image

The setting must be saved in the database:

Also, do you see any outstanding log in browser developer console on stdout?

Hi

First of, thanks for the prompt reply!

The following screenshot is under admin - account - default user preference; (to show that it’s disabled and the db id)

I then used mongo shell to have a look into the db;
db.rocketchat_settings.find({_id: “Accounts_Default_User_Preferences_displayAvatars”})

{ “_id” : “Accounts_Default_User_Preferences_displayAvatars”, “_updatedAt” : ISODate(“2022-09-27T07:49:22.003Z”), “autocomplete” : true, “blocked” : false, “createdAt” : ISODate(“2022-09-17T05:42:37.419Z”), “enterprise” : false, “group” : “Accounts”, “hidden” : false, “i18nDescription” : “Accounts_Default_User_Preferences_displayAvatars_Description”, “i18nLabel” : “Display_avatars”, “packageValue” : true, “public” : true, “requiredOnWizard” : false, “secret” : false, “section” : “Accounts_Default_User_Preferences”, “sorter” : 21014, “ts” : ISODate(“2022-09-17T05:42:37.419Z”), “type” : “boolean”, “value” : false, “valueSource” : “packageValue”, “env” : false }

and for ascii → emoji;
db.rocketchat_settings.find({_id: “Accounts_Default_User_Preferences_convertAsciiEmoji”})
{ “_id” : “Accounts_Default_User_Preferences_convertAsciiEmoji”, “_updatedAt” : ISODate(“2022-09-21T12:05:47.945Z”), “autocomplete” : true, “blocked” : false, “createdAt” : ISODate(“2022-09-17T05:42:37.410Z”), “enterprise” : false, “group” : “Accounts”, “hidden” : false, “i18nDescription” : “Accounts_Default_User_Preferences_convertAsciiEmoji_Description”, “i18nLabel” : “Convert_Ascii_Emojis”, “packageValue” : true, “public” : true, “requiredOnWizard” : false, “secret” : false, “section” : “Accounts_Default_User_Preferences”, “sorter” : 21007, “ts” : ISODate(“2022-09-17T05:42:37.410Z”), “type” : “boolean”, “value” : false, “valueSource” : “packageValue”, “env” : false }

Sorry for the bad formatting, but not really sure where to line break correctly.

So, the thing is what value should I be looking at to see if the settings is saved or not?

This is the value that actually states the setting. So the setting is false, considering the database.

What can happen is that some infos are passed to the client.

Have you tried cleaning the cache? If using the App, right click on the right tab and clear the cache

And if disabled, the value for “value” should be false or true?

We’re using either the windows client, the linux client or the webgui and cleansing cache/cookies etc for browser and the site does nothing. For the linux desktop client I have purged .config/Rocket.Chat and also after tried clear cache in the client for the server.

Does not make any difference on any plattform.

Could one force change the value of “value” in mongodb and that way make it work?

it should reflect what you see on the interface.

I will try to replicate this on the same version and on latest. It may be a bug :grimacing:

Please do if possible, is there any chance this is caused by migrating the same db from such an old version to modern one? I did upgrade RC version by version for each release.

I don’t know if this makes any difference but journal logs spits out alot of;

Exception in callback of async function: URIError: URI malformed
Oct 06 21:32:22 hostname-removed rocketchat[41939]: at decodeURI ()
Oct 06 21:32:22 hostname-removed rocketchat[41939]: at Router.match (/opt/Rocket.Chat/programs/server/npm/node_modules/meteor/simple_json-routes/node_modules/connect-route/lib/connect-route.js:61:12)
Oct 06 21:32:22 hostname-removed rocketchat[41939]: at /opt/Rocket.Chat/programs/server/npm/node_modules/meteor/simple_json-routes/node_modules/connect-route/lib/connect-route.js:102:24
Oct 06 21:32:22 hostname-removed rocketchat[41939]: at runWithEnvironment (packages/meteor.js:1320:24)
Oct 06 21:32:22 hostname-removed rocketchat[41939]: at packages/meteor.js:1333:14
Oct 06 21:32:22 hostname-removed rocketchat[41939]: at /opt/Rocket.Chat/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40

&&

Oct 06 15:28:48 hostname-removed rocketchat[41939]: === UnHandledPromiseRejection ===
Oct 06 15:28:48 hostname-removed rocketchat[41939]: errorClass [Error]: [TypeError: subscriptions.find is not a function]
Oct 06 15:28:48 hostname-removed rocketchat[41939]: at app/lib/server/lib/sendNotificationsOnMessage.js:392:11
Oct 06 15:28:48 hostname-removed rocketchat[41939]: at /opt/Rocket.Chat/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40 {
Oct 06 15:28:48 hostname-removed rocketchat[41939]: isClientSafe: true,
Oct 06 15:28:48 hostname-removed rocketchat[41939]: error: TypeError: subscriptions.find is not a function
Oct 06 15:28:48 hostname-removed rocketchat[41939]: at app/lib/server/lib/sendNotificationsOnMessage.js:377:41
Oct 06 15:28:48 hostname-removed rocketchat[41939]: at Array.forEach ()
Oct 06 15:28:48 hostname-removed rocketchat[41939]: at app/lib/server/lib/sendNotificationsOnMessage.js:376:11
Oct 06 15:28:48 hostname-removed rocketchat[41939]: at /opt/Rocket.Chat/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40,
Oct 06 15:28:48 hostname-removed rocketchat[41939]: reason: undefined,
Oct 06 15:28:48 hostname-removed rocketchat[41939]: details: undefined,
Oct 06 15:28:48 hostname-removed rocketchat[41939]: errorType: ‘Meteor.Error’
Oct 06 15:28:48 hostname-removed rocketchat[41939]: }

Is it deployed with tar?

Have you upgrade also the dependencies?

When you deploy using tar, it’s up to you to take of those.

Have you tried migrating it to a docker staging environment, and upgrading?

Is it deployed with tar? Yes

Have you upgrade also the dependencies? Dependencies such as? dnf updates are run, every version upgrade I have updated the node deps that have given some error.

Have you tried migrating it to a docker staging environment, and upgrading? No, would that make a difference? if there’s a bug in the software it will be there as well.

Did you try to replicate the issue?

Ok, just a note here.

This default settings (ADMIN > SETTINGS > ACCOUNT > Default User Preferences) are only valid for new users.

Those are the default initial values. If you change them, it will not change your user settings. Those need to be changed on a per user basis.

Are you aware of that, right?

No I did not know that, thanks for clarifying it (it’s not clear at all in the admin panel).

However as another side note, even with users going via their “my account → preferences” and disable the display of avatars and convert ascii to emoji … none of these settings take effect. (doesn’t matter if webgui, windows/linux client)

Yeah, that might be a bug =\

I tried with 5.2.rc-4 and indeed looks like a bug to me:

I am using the new message parser:
image

And those are my settings:
image

Use Emojis is working, I cannot open the emoji selector.

Ascii are still being converted to emojis and avatars are being showed.

For those new to Rocket.Chat, is good to know that we are refactoring a lot of code, paying upfront some technical debts we had.

With that said, the message parser is one of the biggest modules that we are refactoring. Here you can check a lot of those issues:

I will keep this thread in mind, and try to look for an issue that covers this already. But please, feel free to help us on that too and, if necesary, open up an Issue.

Thanks!

I tried flipping the legacy message on/off but with it enabled no msgs are displayed at all, not even new ones (even tho they do get posted). This was tested in both linux client and webGui.

Also had a look around your github and found that there is indeed an issue open/in progress regarding the emoji conversion;
Convert ASCII to Emoji preference does not appear to be honored. · Issue #26681 · RocketChat/Rocket.Chat · GitHub

While I’m not new to RC in that sense, we’ve been running long overdue on a very old setup (if it ain’t broke don’t fix it etc).

I do appreciate the time and help spent on this, and while I understand it’s not a deal breaker issue - if it could be addressed in the future it would be great!

Do you happen to know if there is any kind of workaround ugly or not to use in the meantime?

I tried flipping the legacy message on/off but with it enabled no msgs are displayed at all, not even new ones (even tho they do get posted). This was tested in both linux client and webGui.

Yes, this is an issue (legacy parser not showing messages at all) with 5.1
version. 5.1.4 is already fixed.

The emoji issue should be fixed soon, hopefully in 5.3.0 (as 5.2 is about to be released) We have been refactoring a lot of code, and some stuff are breaking while doing it.

By the way, the fix was already produced, and should be merged soon:

Yes I noticed that when setting up a new test.env. for try latest release later on.

This is great news, I will keep track on your upcoming releases and keeping my fingers crossed that it works once merged. Thanks!

Regarding the display of avatars, should I open an issue on github? or just pile on one that was there already?

1 Like

Yep. That’s a separate issue :frowning:

And there is an issue for that too: