Create subproject relationship via APIv3 endpoint

[humitos]

The main goal of this PR is to add the ability to create a subproject relationship between two Project objects.

This PR is based on #5952 (https://github.com/readthedocs/readthedocs.org/tree/humitos/apiv3/project-update-endpoint) because it needs the "per object permissions check" changes that PR contains.

There are some things to note about this PR:

• /api/v3/projects/pip/subprojects/ has changed its response. It was returning a list of Project but we found it was not 100% accurate and it was better to return a list of ProjectRelationship objects that includes the alias and the child (Project) rendered itself.
• a subproject relantionship can be create only if the user is maintainer of both projects (parent and child)
• a subproject relationship can be deleted only if the user is maintainer of the parent project

As a side note, while working on the tests for this PR, I found a but in the RelatedProjectQuerySetBase (see commit 0d42c1b).

Closes #6157

[stsewd]

I think you are missing some more checks:

• Adding the project as subproject of itself
• Nesting subprojects: adding as subproject a project that already has subprojects.
• Unique alias across subprojects of project

readthedocs.org/readthedocs/projects/forms.py

Lines 362 to 388 in 044f200

	def clean_parent(self):
	if self.project.superprojects.exists():
	# This validation error is mostly for testing, users shouldn't see
	# this in normal circumstances
	raise forms.ValidationError(
	_('Subproject nesting is not supported'),
	)
	return self.project
	def clean_child(self):
	child = self.cleaned_data['child']
	if child == self.project:
	raise forms.ValidationError(
	_('A project can not be a subproject of itself'),
	)
	return child
	def clean_alias(self):
	alias = self.cleaned_data['alias']
	subproject = self.project.subprojects.filter(
	alias=alias).exclude(id=self.instance.pk)
	if subproject.exists():
	raise forms.ValidationError(
	_('A subproject with this alias already exists'),
	)
	return alias

I think 1 and 3 should be done at the db level.

Also, do we allow to add translations? There are some similar checks to be done too.

[ghost]

Would it also make sense to prevent project deletion if a project has one or more subprojects? I'm not sure if I think having to delete each subproject first would be terribly cumbersome or not, but it may be a good safeguard to have.

[stsewd]

@dwt2 currently if a project (main project) has submodules, and it is deleted, all its subprojects become normal projects.

[ghost]

@dwt2 currently if a project (main project) has submodules, and it is deleted, all its subprojects become normal projects.

Hmm, I think I would be easier on users to have the current default as an option, but also the option to pass a param to delete all subprojects with the top-level project too.

Let's say I intentionally want to delete a project and its 100 subprojects. With the current default I then have to do 100 more API operations to delete each (new) top-level project. Doable, but tedious.

[humitos]

I think you are missing some more checks

I added these checks and tests for them as well. Please, review the PR when you have some time.

Also, do we allow to add translations? There are some similar checks to be done too.

Currently, no. We are only listing translations under /projects/<slug>/translations/

[stsewd]

@humitos can you resolve the conflicts before review?

[humitos]

@stsewd done!

[stsewd]

aren't these constants somewhere?

[humitos]

I've never seen them used as constants. I did a quick grep on their source code and I found that they use just the strings as well :'( : https://github.com/encode/django-rest-framework/blob/e57c1505fc4ed957332ae547a35c8713acfdf30c/rest_framework/schemas/coreapi.py#L37

[stsewd]

hmm, why wasn't this merged to master but apiv3/project-update-endpoint?