* MM-44412: correct usage of updateAt to createAt
* lint
* correct usage of updateAt to createAt - CRT unsupported
* remove dead code
* remove unrequired tests
* update test name
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* [MM-44329] Added methods to sqlstore.Store
* [MM-44329] Added methods to the store.Store interface
* [MM-44329] Regenerated mocks
* [MM-44329] Added comments for the store.Store interface
Co-authored-by: Tim Scheuermann <tim.scheuermann@mattermost.com>
* MM-41728: Validate emoji size in app on import
* use NotNil instead of Error for AppErr
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* Prevent cloud limited installations from restoring teams when at or above the teams limit
* Code clean up
* fix i18n
* Actually fix i18n
* updates for govet
* Update model/client4.go
Co-authored-by: Vishal <vish9812@gmail.com>
* [MM-44397] Restrict team creation based on subscription limits (#20282)
* restrict team creation based on limits
* Update api4/team.go
Co-authored-by: Maria A Nunez <maria.nunez@mattermost.com>
* Fix tests
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
Co-authored-by: Maria A Nunez <maria.nunez@mattermost.com>
* Add additional field to teamsusage
* Fix
* remove useless test
* Fix error for team creation
* Remove apostrophe
* Add ReturnStatusOK to softDeleteTeamsExcept
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
Co-authored-by: Vishal <vish9812@gmail.com>
Co-authored-by: Maria A Nunez <maria.nunez@mattermost.com>
* MM-43666 - request bussiness email
* add the newValidEmail information
* revert ff model changes
* remove unnecessary pointer and fix test spelling
* fix unit tests and add a new one for when passing a valid email
* fix go lint
Co-authored-by: Pablo Velez Vidal <pablo.velez@mattermost.com>
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* store: guests will only receive results of which channels they are in
* api4/channel_test: add test case for guest accounts channel autocomplete
* apply to searchengine and also for AutocompleteInTeam
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* Prevent cloud limited installations from restoring teams when at or above the teams limit
* Code clean up
* fix i18n
* Actually fix i18n
* updates for govet
* Update model/client4.go
Co-authored-by: Vishal <vish9812@gmail.com>
* [MM-44397] Restrict team creation based on subscription limits (#20282)
* restrict team creation based on limits
* Update api4/team.go
Co-authored-by: Maria A Nunez <maria.nunez@mattermost.com>
* Fix tests
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
Co-authored-by: Maria A Nunez <maria.nunez@mattermost.com>
* Add additional field to teamsusage
* Fix
* remove useless test
* Fix error for team creation
* Remove apostrophe
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
Co-authored-by: Vishal <vish9812@gmail.com>
Co-authored-by: Maria A Nunez <maria.nunez@mattermost.com>
* Add a test for SetPostUnread-DM Channel
* assert early
* Unread post in DM thread
* Replace th.BasicUser with u1 var
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
Summary
In a bulk import, if the createAt of a reply is older than the createAt of the parent post, then instead of erroring, we log a warning and set the createAt of the reply to that of the parent post.
I checked the exporting logic, there doesn't appear to be away for the reply createAt to be older than the parent createAt, as a side-effect of the exporting logic.
Ticket Link
https://mattermost.atlassian.net/browse/MM-43878
A deadlock that has been found on our Community servers is:
```
------------------------
LATEST DETECTED DEADLOCK
------------------------
2022-03-03 06:14:37 0x2aec58887700
*** (1) TRANSACTION:
TRANSACTION 1043681684, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 23 lock struct(s), heap size 1136, 137 row lock(s), undo log entries 26
MySQL thread id 448011, OS thread handle 47195956565760, query id 752406931 10.128.147.211 mmcloud updating
DELETE FROM SidebarChannels WHERE ((ChannelId IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) OR ChannelId IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)) AND CategoryId = ?)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 907 page no 368 n bits 0 index PRIMARY of table `mattermost`.`SidebarChannels` trx id 1043681684 lock_mode X waiting
Record lock, heap no 121 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len=26; bufptr=0x2aebbd36b75c; hex= 3363776f6a6a6d36316a62663967657036706872316533696a77; asc 3cwojjm61jbf9gep6phr1e3ijw;;
1: len=26; bufptr=0x2aebbd36b776; hex= 3568616279726d36746a6265747061656538786973786d6b7177; asc 5habyrm6tjbetpaee8xisxmkqw;;
2: len=26; bufptr=0x2aebbd36b790; hex= 373568726a7a68676169726370653477696877727866716f7463; asc 75hrjzhgaircpe4wihwrxfqotc;;
3: len=6; bufptr=0x2aebbd36b7aa; hex= 00003e355176; asc >5Qv;;
4: len=7; bufptr=0x2aebbd36b7b0; hex= 39000352420fce; asc 9 RB ;;
5: len=8; bufptr=0x2aebbd36b7b7; hex= 80000000000000fa; asc ;;
*** (2) TRANSACTION:
TRANSACTION 1043681679, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 76 lock struct(s), heap size 1136, 294 row lock(s), undo log entries 72
MySQL thread id 447990, OS thread handle 47194812454656, query id 752406930 10.128.147.211 mmcloud updating
DELETE FROM SidebarChannels WHERE ((ChannelId IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) OR ChannelId IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)) AND CategoryId = ?)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 907 page no 368 n bits 0 index PRIMARY of table `mattermost`.`SidebarChannels` trx id 1043681679 lock_mode X
Record lock, heap no 121 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len=26; bufptr=0x2aebbd36b75c; hex= 3363776f6a6a6d36316a62663967657036706872316533696a77; asc 3cwojjm61jbf9gep6phr1e3ijw;;
1: len=26; bufptr=0x2aebbd36b776; hex= 3568616279726d36746a6265747061656538786973786d6b7177; asc 5habyrm6tjbetpaee8xisxmkqw;;
2: len=26; bufptr=0x2aebbd36b790; hex= 373568726a7a68676169726370653477696877727866716f7463; asc 75hrjzhgaircpe4wihwrxfqotc;;
3: len=6; bufptr=0x2aebbd36b7aa; hex= 00003e355176; asc >5Qv;;
4: len=7; bufptr=0x2aebbd36b7b0; hex= 39000352420fce; asc 9 RB ;;
5: len=8; bufptr=0x2aebbd36b7b7; hex= 80000000000000fa; asc ;;
[bitmap of 256 bytes in hex: 00 00 00 00 00 00 00 f0 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 907 page no 67 n bits 0 index PRIMARY of table `mattermost`.`SidebarChannels` trx id 1043681679 lock_mode X waiting
Record lock, heap no 103 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len=26; bufptr=0x2aeb4515ec1b; hex= 6431376b35706f71786979776d6b6d616b6a78623539356b366f; asc d17k5poqxiywmkmakjxb595k6o;;
1: len=26; bufptr=0x2aeb4515ec35; hex= 7067653939686a356562676b38636f6f70637a6e7871677a6568; asc pge99hj5ebgk8coopcznxqgzeh;;
2: len=26; bufptr=0x2aeb4515ec4f; hex= 336e3731636a73656f667931397267746664337962786d713777; asc 3n71cjseofy19rgtfd3ybxmq7w;;
3: len=6; bufptr=0x2aeb4515ec69; hex= 00003e34fa4d; asc >4 M;;
4: len=7; bufptr=0x2aeb4515ec6f; hex= 4600026d940e4c; asc F m L;;
5: len=8; bufptr=0x2aeb4515ec76; hex= 8000000000000082; asc ;;
*** WE ROLL BACK TRANSACTION (1)
```
It seems like 2 DELETE queries are somehow deadlocking on the same row.
On looking at it deeply, we can see that in an updateSidebarCategory scenario,
we run 2 delete queries in a single transaction. In that delete query, we not only delete the existing channels for a category,
but also delete the new channels that are going to be inserted in the new category.
The potential issue with this is that since we are updating both the source and destination category in a single transaction,
the category which is moved appears in the destination section for the first category, and in the source section for the second category.
Which means in a single transaction, you have 2 queries possibly interlocking due to the same channels.
Therefore, if we run 2 separate updateCategories with an inverted order of categories, then the same set of delete queries
can lock on the opposite order of channels and cause a deadlock.
I haven't been able to reproduce this, but just a hunch. And in any case, this will reduce the number of DB updates.
```release-note
NONE
```
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
