We check for the presence of binary_parameters
in the DSN and add the 0x01 byte accordingly.
This helps us avoid casting to string
and efficiently use the database.
```release-note
NONE
```
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* refactor: added is_pinned attribute to post and direct_post objects when doing bulk import
* fix: handling IsPinned nil value in post and direct_post objects import
* refactor: added pinned post tests for post and direct_post objects import
* refactor: TestImportimportMultiplePostLines code enhancements + added pinned post tests in TestImportImportDirectPost
* fix: test message text
* fix: typo Post => DirectPost
* fix: typo Post => DirectPost
* refactor: remove redundant test
* refactor: test enhancements
* refactor: remove print statements.
* refactor: using require instead of assert
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* MM-40148: threadsOnly query param for user threads
Currently we always calculate counts when fetching user threads.
Those counts include total, unread replies, and unread mentions,
and are potentially expensive to calculate.
This commit adds a new query param 'threadsOnly' which won't calculate
any counts and just return threads.
Co-authored-by: koox00 <3829551+koox00@users.noreply.github.com>
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
The older method used to reply completely on timestamps
to take batches of items in a timestamp range and then
just incrementing the timestamp. This led to handling
edge-cases such as more items than the batch count, all
having the same timestamp.
Additionally, relying on timestamp as the page cursor
meant that indexing was not very efficient if you had
several items spread out across large spans of time.
To get away from all of that we use a proper cursor-based
approach consisting of createAt+Id. With this, we move
completely to a constant page size where we can fetch
a given number of objects irrespective of when they
were created. This makes indexing much more faster and
efficient.
https://mattermost.atlassian.net/browse/MM-41260
```release-note
Elasticsearch and Bleve indexing have been revamped to be much
more efficient and faster. The config parameter BulkIndexingTimeWindowSeconds
for both elasticsearch and bleve have been removed.
A new config parameter called BatchSize has been introduced instead.
This parameter controls the number of objects that
can be indexed in a single batch. This makes things
more efficient and maintains a constant workload.
```
When the test fails, it is not clear whether the method
returned an error or it returned a channel with DeleteAt
set to 0. The if condition was also incorrect because
if the error was not-nil the condition would evaluate
to true and the test would pass.
We split the condition into 2 separate cases which will
let us know exactly what is failing.
https://mattermost.atlassian.net/browse/MM-42092
```release-note
NONE
```
* Running CodeQL everyday twice
* Updated scorecard-check to run everyday
* Running Scorecard job once a day
* Disabling Scorecard Job on every PR
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
We implement a cursor based pagination model
to page through the posts in a given thread.
The cursor is a combination of the post.CreateAt+
post.Id to differentiate multiple posts in a given
timestamp.
Some additional parameters like direction, fromPost,
fromCreateAt and perPage were introduced to implement
this.
```release-note
NONE
```
Summary
A number of performance improvements shipped in v6.5 to support CRT with the ThreadAutoFollow bookkeeping enabled but the frontend features disabled. To prepare for a later enabling of the frontend features by default, we want to encourage customers to re-enable ThreadAutoFollow, and plan to enable this by default in v6.6.
Ticket Link
https://mattermost.atlassian.net/browse/MM-42535
Due to the way our community deployment is done. The job server
is restarted every day. This means that whenever there is a job
that takes more than 24 hours, it will always get cancelled
when the server restarts and therefore will never finish.
This PR adds ability to resume any stopped jobs, by storing
intermediate progress in the job metadata and setting
the job to pending instead of cancelled when everything is
shut down.
The user can still cancel a job explicitly by clicking on
the cross button in the system console. That functionality
hasn't changed. Only server stop or stopping/starting
job server via config will pause/resume jobs.
```release-note
The elasticsearch indexing job is resumable now. Stopping a
server while the job is running will put the job in pending status
and will resume the job when the server starts.
The job can still be explicitly cancelled via the system console UI.
```
