Organizations: allow uploading avatar

[stsewd]

• The file size is set to 750kb as max
• The image dimensions should be equal or less to 500px
• Only jpg and png formats are allowed (this is a soft check anyway), we are not checking for the content, but django does check if the file is an image using pillow at least.
• Images are publicly accessible and can be enumerated, I think this is fine, avatar images aren't sensible information.
• pillow is a required dependency when using ImageField

This requires creating a new bucket and the corresponding settings in ops.

Closes https://github.com/readthedocs/readthedocs-corporate/issues/1471

[stsewd]

Not sure about the migrations check, I don't see any changes locally :/

[humitos]

Looks good to me. I left some small comments.

[humitos]

We use the slug of the object in other buckets to generate the path. It will be easier to find the file when debugging as well.

Suggested change

	return f"avatars/organizations/{instance.pk}.{extension}"
	return f"avatars/organizations/{instance.slug}.{extension}"

[stsewd]

Organization slugs can be renamed, we don't want to have broken/orphan avatars when that happens.

[humitos]

Nope, organization slugs cannot be changed. We use them on the media bucket to store the documentation. We should keep consistency here as well.

[stsewd]

Slugs are changed via support, the slug from the media bucket is the project slug, not the organization slug.

[humitos]

We don't change slug via support on purpose. We always tell people to re-create the object. The project slug in .com is the combination of "organization slug + project slug"

[humitos]

If it feels like much more work, the rest of us are all okay with just using the org slug.

👍🏼

[stsewd]

Using a UUID is safer (we don't need a hash) and just avoids having edge cases with slug renames. Slug renames can lead to collisions, allowing another organization to control the avatar from another organization. Why take that risk when a UUID is much safer?

[agjohnson]

Yeah UUID does avoid all that.

But we're all saying the slug is fine because the risk here doesn't seem significant. The cost of this discussion and spending more time engineering a solution for an edge case will overshadow the cost of spending a few extra minutes each year telling a couple users they need to update their avatar.

[stsewd]

The cost of having to deal the avatars randomly changing when there is a slug change is greater than implementing a good solution from the start that only requires a couple of lines of code. And as mentioned, this edge case allows for random users changing the avatar from another organization, so the problems caused are not insignificant.

[ericholscher]

So implement a UUID and move forward?