* Set bot profile image and icon only if they have changed
* Move equality check to the app layer
* Use ioutil.ReadAll
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
Summary
If a user has unfollowed a thread, another user's reply in the thread should not cause the first user to re-follow the thread. The first user will be re-followed if they are mentioned in the thread.
Simplify and make flexible the logic surrounding following and remove some duplicate code.
Ticket Link
https://mattermost.atlassian.net/browse/MM-36544https://mattermost.atlassian.net/browse/MM-37439
* Update store function GetThreadForUser to use master DB to fix replica lag
* Refactor GetThreadForUser store func to take membership as argument to prevent replica lag issues and reduce joins in query
* Add translation
* Fix test
* Updates per feedback
* Minor clean-up per feedback
* check authdata for different format
* add mocks, fix lint
* rename function
* update auth-data with new format
* update assert
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* add request context
* move initialialization to server
* use app interface instead of global app functions
* remove app context from webconn
* cleanup
* remove duplicated services
* move context to separate package
* remove finalize init method and move content to NewServer function
* restart workers and schedulers after adding license for tests
* reflect review comments
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* MM-34002: Improve AddUserToChannel
When we would add a user to a channel, we would
check whether the user is removed from that team or not.
During LDAP sync, this check is not required because the
team member would have just been created. Hence, we
pass a boolean flag to bypass the check.
And with that done, we can freely query the replica.
https://mattermost.atlassian.net/browse/MM-34002
```release-note
NONE
```
* Refactor code
* Rename a struct field
* fix double negative
During LDAP sync, we would call AddTeamMember which had a read-after-write issue
where we would create a team member but then immediately after that
query the team member.
The same pattern was found in:
AddTeamMember
AddTeamMembers
AddTeamMemberByToken
To fix this, we just return the inserted team member from AddUserToTeam and use that
instead of query GetTeamMember again.
```release-note
NONE
```
https://mattermost.atlassian.net/browse/MM-33913
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* Isolate more the mfa service
* Simplifing the mfa service
* Removing channels and adding waitgroup
* Migrating mfa service to regular errors
* Fixing tests
* i18n extract
* Addressing PR review comments
* Removing unneeded struct
* MM-30882: Fix read-after-write issue for demoting user
In (*App).DemoteUserToGuest, we would demote a user, and then immediately
read it back to do future operations from the user. This reading back
of the user had the effect of sticking the old value into the cache
after which it would never be updated.
There was another issue along with this, which was when the invalidation
message would broadcast across the cluster, it would hit the cache invalidation
problem where an unrelated store call would miss the cache because
it was invalidated, and then again read from replica and stick the old value.
To fix all these, we return the new value directly from the store method
to avoid having the app to read it again.
And we add a map in the localcache layer which tracks invalidations made,
and then switch to use master if it's true.
The core change is fairly limited, but due to changing the store method signatures,
a lot of code needed to be updated to pass "context.Background". Therefore the PR
just "appears" to be big, but the main changes are limited to app/user.go,
sqlstore/user_store.go and user_layer.go
https://mattermost.atlassian.net/browse/MM-30882
```release-note
Fix an issue where demoting a user to guest would not take effect in
an environment with read replicas.
```
* Fix concurrent map access
* Fixing mistakes
* fix tests
During user creation via CLI, we would create the user,
but pass the user ID instead when updating the roles.
This falls into the category of read-after-write within a single request.
We fix this by passing the already created user and
directly update the roles.
https://mattermost.atlassian.net/browse/MM-32471
```release-note
NONE
```
