check avatar truthiness directly

rebase before addressing feedback

rebase ebfore landing

In D7320#217782, @ashoat wrote:

Can you please include the actual changes instead of submitting a diff that only changes types?

JK this is handled by @rohan in D7211

https://linear.app/comm/issue/ENG-3607/remove-edit-thread-name-permission-forpersonal-threads

remove EDIT_THREAD_AVATAR from PERSONAL

rebase before addressing feedback

Does it make sense to just remove EDIT_THREAD_NAME permissions for threadTypes.PERSONAL now, so we don't have to run another migration for that?

Read through it a couple times carefully and I think this change should be good.

In D7313#217566, @ginsu wrote:

I don't think we want to allow EDIT_THREAD_AVATAR for PERSONAL and PRIVATE threads. I know right now we can modify the username for PERSONAL and PRIVATE, but we should probably change that in a future diff

land

land

Gave it a very brief skim, but looks reasonable. Assuming we don't care about the 80char/line limit for these files.

rebase before landign

rebase before landing

For encryption both enabled and disabled, send a photo and confirm it works. Refresh the website to reload from keyserver.

Looks good, would've been helpful to have a few more specifics in the Test Plan

Minor nits inline.

Looks good, minor nits inline.

I think the condition at web/media/multimedia.react.js:52-53 was intended to be || instead of &&?

Looks great!

Looks reasonable to me, but would be great if @ashoat OR @tomek could take another look here since (I think) they have more context.

rebase before landing

I know this is a big diff; however, when we eventually have avatars in stable condition, I think it will be nice to get rid of this code, so having one diff that shows all the changes that need to be "reverted" is why I decided to make this diff bigger than normal.

Looks good. I think the layout of those modals is generally weird (particularly the vertical spacing), but this is a strict improvement.

Thanks for testing those scenarios in Test Plan. Question about API inline.

Thanks for testing all those scenarios in the Test Plan. Two questions inline.

rebase before landign

Makes sense.

std::unique_ptr<std::string> instead of std::string>

fix formatting (I guess it was a tab and space instead of two spaces? thought we stuck to spaces generally but made it consistent)

formatting?

update again

update

The whole function becomes kind of spaghetti - a refactor follow-up wouldn't be a bad idea

(Resigning to remove from my queue since it seems like @ashoat has got it, feel free to re-add me if there's anything specific)

rebase and land