In D6924#211499, @tomek wrote:

How the pinning will be saved on client's side? Do we plan to have it included in a message info? If that's the case, do we plan to update all the message infos saved on all the clients?

Call parseMessageSQLResult instead of rawMessageInfoFromRows

Rename types

Update toggleMessagePinRequestInputValidator

Update ToggleMessagePinRequest

Simplify the migration

Introduce two columns in messages

In D6924#207293, @tomek wrote:

On the other hand creating a new table also has some issues from the design's perspective. For example, thread column is a function of messageID because based on message id we can uniquely identify a thread. So this new table isn't e.g. a joining table but instead it depends on just messages table and could be replaced by new columns (is_pinned and pin_timestamp) on it.

I'm not sure, at this point, what is the best design here, but I think that we should spent a little more time figuring it out.

Flip the isPinned condition

I'm going to wait until the architecture of pinned_messages is decided in D6924 before requesting review, I just put this up so I could continue working locally.

In D6924#206038, @atul wrote:

While I agree that it might be better database design to create a separate table, it will complicate things on the SQLite side.

We persist messageStore.messages and threadStore in SQLite on the native client, and it would probably make the most sense to store pinned_messages in the SQLite threads table instead of introducing a whole new table and set of “ops.” That would introduce inconsistency between the MariaDB and SQLite database… which isn’t the end of the world, but could be avoided if we stored pinned_messages in the threads table?

Abandoning this since this isn't actively being worked on, but it can be revisited and reopened at a later point if needed

In D6865#205681, @ashoat wrote:

Hey @rohan, you seem to have partially landed your stack. Just wanted to get some clarification – what is the current state of master after your partial land? I want to make sure we aren't in a bad state where we are blocked from deploys. (If so, we should revert)

Revert Modal changes

Use MultimediaModal and allow video support for the modal

Rebase

Rebase

Rebase

Rebase

In D6865#204399, @ashoat wrote:

Why are we using Modal though? Should we just update MultimediaModal to look like those designs?

In D6485#204702, @ashoat wrote:

On the ORDER BY / LIMIT question from earlier, I think you had mentioned over chat that you would have to wrap the SELECT / UNION SELECT and apply them to the whole thing. Is that still your belief? I noticed this StackOverflow implies the opposite, but I haven't done any testing to confirm.

Make sure lines are < 80 characters

Pass in viewer parameter

Check visible permission

thumbnailUploadType and thumbnailUploadExtra are not used so I'm removing them from the query

Address feedback on filteredMediaInfos

Rebase on D6485

Rebase on D6485

Rebase on D6485

Rebase on D6485

Rebase on D6485

Rebase on D6485