APIv3 CRUD for Redirect objects

[humitos]

• CRUD for Redirect objects at /api/v3/projects/<project_slug>/redirects/
• These objects are accessed only by admins of the projects (listing and detail)
  • I'm not sure if it does make sense to use the same pattern of "Public Detail - Private Listing" on these
  • We are not exposing these objects to any other user that are not the maintainers via the WebUI
• Adapt RedirectQuerySet to follow the .api method pattern
  • .public, .private, etc are not needed because they do not make sense (considering the previous item)
• Move redirects/managers.py to redirects/querysets.py to be consistent with the other apps
• Use combined permission_classes, like after the refactor at Make APIv3 permission classes modular #5858
• Minimal DB query optimization to use .only in one of the methods that just checks for in
• Add some tests for Redirect endpoints

[davidfischer]

I know this is a work in progress but it is looking pretty good to me.

One thing that we should probably handle is that the queryset is not using select_related. Perhaps we could have a get_queryset method like this:

def get_queryset(self):
    qs = super().get_queryset()
    qs = qs.select_related('project')
    return qs

[davidfischer]

This permission seems to be generating something like 6 extra queries which was surprising. However, it is not generating N queries where N is the number of redirects.

[humitos]

Well, this is the basic permission check that we need in all the endpoints for user admin of a project. I split it here to make it simpler and have it isolated.

So, if this check is slow, we should take care of it since it's used a on most of the endpoints.

Basically, it does:

• get a Project (from slug in the URL)
• performs a Project.objects.filter(users__in=[user])

I think we can use .only('id') in ProjectQuerySetMixin.has_admin_permission in the if, to avoid bringing the full objects since we only want to make a simple check.

In my very simple local tests, there is a timing difference. I'll add a commit for this.

[humitos]

Also, some of these method are called more than once (at least for the BrowsableAPIRenderer) and returned value won't change in the same request, so we could do something there if we care enough.

[davidfischer]

Overall it probably isn't a big deal either way. Some number of queries is necessary for the permission check but 6 just seemed high. I do wonder if we shouldn't just cache the project object onto the view object since most of our views relate to projects.

[humitos]

I think we can optimize it later if needed --I think it's a good option. Although, I don't want to introduce a "buggy cached object" at this point before knowing that everything is working as we expect :)

[davidfischer]

I'm ok with that for now. Let's keep it in mind though.

[humitos]

One thing that we should probably handle is that the queryset is not using select_related. Perhaps we could have a get_queryset method like this:

This reduces the numbers of queries in N, where N is the number of Redirect objects returned: 💯 --at least in a simple test, but makes sense.

[humitos]

This PR is ready for review.

The same pattern followed for this Redirect resource/objects will be followed for other ones as well, like EnvironmentVariable and WebHook/EmailHook in other PRs.