Readthedocs.org: Subproject is not updated on save/build

[agjohnson]

When changing a subproject of a superproject, for instance updating the privacy level of the project, symlinks for the superproject are not updated. This might be a regression.

To reproduce

• Create a project A, privacy level public
• Create a project B, privacy level private
• Assign project B as a subproject of project A
• Project B URLs should 404
• Alter project B privacy level to public
• Project B URLs still 404

Expected Result

• Project B URLs shouldn't 404 after updating to public privacy level

Resolving

We should either trigger a save of the project's superproject, or explicitly call a task for re-symlinking the project in the following cases:

• When a subproject is deleted
• When a subproject privacy level is changed
• When a subproject version privacy level is changed (?? not sure here, might need testing on this as well)

[stsewd]

I was able to replicate this, none symlink on A/projects are created. When project A is re-builded the symlink is created.

[stsewd]

Also when removing the subproject the symlink is not erased. Again, rebuilding the project A fix this.

[agjohnson]

Great, I'm glad this is reproduceable.

So, we should either trigger a save of the superproject in these cases, or explicitly call a task to resymlink the superproject. The second option definitely works, but perhaps a full save of the project makes more sense technically.

I'll update the description with more info

[humitos]

I followed the steps to reproduce it mentioned here and I was able to reproduce it.

Then, the solution proposed (call a A.save()) does work and I can access to http://localhost:8000/docs/a/projects/B/en/latest/

In [10]: a = Project.objects.get(slug='a')

In [11]: a.save()
[21/Feb/2018 14:08:34] readthedocs.core.symlink:93[2712]: INFO (Build) [a:] Symlinking subproject: b -> b
[21/Feb/2018 14:08:34] readthedocs.core.symlink:93[2712]: INFO (Build) [a:] Symlinking subproject: B -> b
[21/Feb/2018 14:08:34] readthedocs.core.symlink:93[2712]: INFO (Build) [a:] Symlinking Version: Version latest of A (1173)
[21/Feb/2018 14:08:34] celery.app.trace:123[2712]: INFO Task readthedocs.projects.tasks.symlink_project[fff11308-f0c1-4639-aeab-dea3541f2ad0] succeeded in 0.033074999002565164s: None
[21/Feb/2018 14:08:34] readthedocs.projects.tasks:980[2712]: INFO (Build) [a:] Updating static metadata
[21/Feb/2018 14:08:34] celery.app.trace:123[2712]: INFO Task readthedocs.projects.tasks.update_static_metadata[7f9b4e54-0399-43da-ab66-11b271848c15] succeeded in 0.010115133998624515s: None

I'm trying to write a test case to make this fail first, but I don't know how to manage symlinks from the tests and check the documentation URLs yet.

[humitos]

I'm reopening this one to talk a little more.

I did a manual QA after the today's deploy and I'm not sure if the original issue is fixed or not. I think I'm confused.

Following the steps described in the description, I finally end with:

• http://rtd-project-a.readthedocs.io/projects/rtd-project-b/en/latest/ giving a 404 with the Maze and "This page does not exist yet"
• http://rtd-project-b.readthedocs.io/en/latest/ works

I just found that the test that I wrote at https://github.com/rtfd/readthedocs.org/pull/3649/files#diff-31a1317fe6aaf4de559c18d25fd89323R961 doesn't test what we need: it starts with 2 public project and change the subproject to private and the report is the other way around.

We need the superproject to be public and the subproject to be private. Then change its privacy to public. At first sight, it seems that it should work either way but I think that I definetely made a mistake on this

[ericholscher]

private projects don't work at all on the .org, and we shouldn't try to support them. If this is an issue around privacy levels, then that is an entire other discussion. We _should_ hide privacy levels in the UI though.

[humitos]

@ericholscher this is more a fix for the .com site, but as the code that handles privacy level is done in the .org site the issue/PR is reported here.

I did test this on my .com locally and it works, but what I think it's incorrect it's the description about how to reproduce it since it's not related to the "Project's privacy level" but the "Version's privacy level".

I mean, if I change the "Project's privacy level to public" the Version will still be private and that's why it's not shown, but if I change the "Version's privacy level to public" I immediately see the documentation under http://my-own-organization-project-a.dev.readthedocs.io:8001/projects/my-own-organization-project-b/en/latest/ which I think it's correct.

private projects don't work at all on the .org, and we shouldn't try to support them.

I just did the same test in the .org that I did in .com and it didn't work by changing the "Version's or the Project's privacy level"

I think this is working --if we don't want to support privacy levels in .org.

@agjohnson I would like you to test it a little more in the .com, but from my point of view this does the trick.

[agjohnson]

This sounds like it can be reclosed then.