I think this makes sense. I just was hoping you could provide a quick clarification just for my understanding. Good work on this!

I'm a bit confused what the difference is between Review, Review Request and Review Request Draft. Would you mind clarifying this please?

Docstrings need to conform to our documentation guidelines. Look for other functions like get_user and make sure you're following that pattern. This needs to have Args and Returns sections.
A function's summary should succintly describe its purpose. The description is used for additional details. Keep this high-level: The fact that it's using get_last_activity_info() is an implementation detail that' best left to the code. The reader doesn't care. They care about hte purpose of the function.

All variables in our Python code use snake_case pattern, rather than camelCase.

This is being set and then overridden below. Doesn't seem like this needs to be set here, because of that.

Something important to note here is that we can't necessarily assume that the review request's owner is the user that performed the update. For review requests, the changedesc object is also returned. This is the "Review request changed" box. An administrator, or special users, can make changes on a review request on another user's behalf, and the user that did that is in changedesc.user.

This can cause problems down the road if we introduce more types of objects and one of them isn't owner. Each check should be very explicit about what object we're working with, and any else: should probably raise an AssertionError if the user isn't an expected type (with a useful message).

Imports should always be in alphabetical order.

The last parameter of a function call shouldn't have a trailing comma. The ) should be on the same line as the last parameter, as well. Note the other columns in this class.

This doesn't seem to be related to your change, so it should be reverted.

This will also need to be in alphabetical order.

This from .. import .. also needs to be in alphabetical order within the list of all imports.

This is only used if the column is testing with a LocalSite. None of these are, from what I can see.

The trailing """ must be on its own line when it's a multi-line docstring.
Also, this docstring doesn't say what is being tested. This should explicitly list the column name. Look at other unit tests in this file.

Several of our test objects use the same usernames, which can create false-positives in username-based tests. Your code should explicitly create a user for each test that we want to check for, make sure the right object is being created with that user, and then use that user for any checks.

We're not testing get_last_activity_info(). This could would be better served testing get_user() on the column.

For each of these, these usernames very well may be the correct ones, but there's nothing currently indicating that we know for sure. The code isn't tying these to the objects the usernames are coming from. We should explicitly use those.

These are probably wrapping prematurely.
Same with the other unit tests.