[Fix #4576] Do not delete projects which have multiple users #4577

safwanrahman · 2018-08-28T11:38:37Z

Fixes #4576
The query was limiting the users before annotation because of django's backward relation query. the Documentation of django does not provide much information about it, but I have gone through the differentiate of the sql query and found the root cause.
I have also added tests for this so it should not happen again. I should have written the tests when I implemented the feature in #3214.
@agjohnson @humitos r?

humitos

These changes look good.

I test these queries (old and new ones) in production DB and the new ones return what is expected.

Although, by checking the underline SQL code executed I wasn't able to fully understand the difference

humitos · 2018-08-28T12:44:29Z

readthedocs/core/signals.py

@@ -79,12 +80,16 @@ def decide_if_cors(sender, request, **kwargs):  # pylint: disable=unused-argumen
 def delete_projects_and_organizations(sender, instance, *args, **kwargs):
    # Here we count the owner list from the projects that the user own
    # Then exclude the projects where there are more than one owner
-    projects = instance.projects.all().annotate(num_users=Count('users')).exclude(num_users__gt=1)
+    # Add annotate before filter
+    # https://bit.ly/2Nne6ZJ


nit: I'd use the original link from the docs instead of this one that hides the topic/section

the link is >100 charecters. linter raise error on that!

I personally prefer to put a # noqa or similar on this line and have the original link to the docs.

+1 on dropping bitly link from code. pointing to a github issue or self-reference the pr, or noqa on the line all work for this case.

humitos · 2018-08-28T13:21:55Z

readthedocs/core/tests/test_signals.py

+        obj.refresh_from_db()
+        assert obj.id
+        obj_users = obj.users.all()
+        assert len(obj_users) == 1


nit: use .count() here.

We need to take the queryset value in memory eventually. So better to use len() to reduce single COUNT sql query

I wouldn't use len to count queryset elements independently of the context.

humitos · 2018-08-28T13:24:56Z

There are two unrelated tests failing (yaml config file)

agjohnson

Nice catch! I still don't fully understand the fix so we might need some more thorough tests to ensure this does not happen again.

agjohnson · 2018-08-28T15:07:41Z

readthedocs/core/tests/test_signals.py

+import pytest
+
+from django.contrib.auth.models import User
+from django_dynamic_fixture import G


nitpick: we don't use django_dynamic_fixture.G at all, it's a poorly named variable -- linting would pick up on this if we were running pre-commit on our tests. django_dynamic_fixture.get is also poorly named, but much better than G. My personal preference is import django_dynamic_fixture as fixture; fixture.get.

agjohnson · 2018-08-28T15:09:39Z

readthedocs/core/tests/test_signals.py

+
+
+@pytest.mark.django_db
+class TestProjectOrganizationSignal(object):


I'm mostly certain we have tests for both of these cases already. Can you provide test output of these tests without your patch applied?

I missed adding tests while implementing the feature for both of the case.
Here is the output without applying my patch

=============================================================================== FAILURES =============================================================================== ______________________________________ TestProjectOrganizationSignal.test_multiple_users_project_organization_not_delete[Project] ______________________________________ self = <readthedocs.core.tests.test_signals.TestProjectOrganizationSignal object at 0x10eb85d30>, model_class = <class 'readthedocs.projects.models.Project'> @pytest.mark.parametrize('model_class', [Project, RemoteOrganization]) def test_multiple_users_project_organization_not_delete(self, model_class): """ Check Project or RemoteOrganization which have multiple users do not get deleted when any of the user delete his account. """ obj = django_dynamic_fixture.get(model_class) user1 = django_dynamic_fixture.get(User) user2 = django_dynamic_fixture.get(User) obj.users.add(user1, user2) obj.refresh_from_db() assert obj.users.all().count() > 1 # Delete 1 user of the project user1.delete() # The project should still exist and it should have 1 user > obj.refresh_from_db() core/tests/test_signals.py:52: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ../.tox/py36/lib/python3.6/site-packages/django/db/models/base.py:592: in refresh_from_db db_instance = db_instance_qs.get() _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = [], args = (), kwargs = {}, clone = [], num = 0 def get(self, *args, **kwargs): """ Performs the query and returns a single object matching the given keyword arguments. """ clone = self.filter(*args, **kwargs) if self.query.can_filter() and not self.query.distinct_fields: clone = clone.order_by() num = len(clone) if num == 1: return clone._result_cache[0] if not num: raise self.model.DoesNotExist( "%s matching query does not exist." % > self.model._meta.object_name ) E readthedocs.projects.models.DoesNotExist: Project matching query does not exist. ../.tox/py36/lib/python3.6/site-packages/django/db/models/query.py:387: DoesNotExist ________________________________ TestProjectOrganizationSignal.test_multiple_users_project_organization_not_delete[RemoteOrganization] _________________________________ self = <readthedocs.core.tests.test_signals.TestProjectOrganizationSignal object at 0x10eb9f9b0>, model_class = <class 'readthedocs.oauth.models.RemoteOrganization'> @pytest.mark.parametrize('model_class', [Project, RemoteOrganization]) def test_multiple_users_project_organization_not_delete(self, model_class): """ Check Project or RemoteOrganization which have multiple users do not get deleted when any of the user delete his account. """ obj = django_dynamic_fixture.get(model_class) user1 = django_dynamic_fixture.get(User) user2 = django_dynamic_fixture.get(User) obj.users.add(user1, user2) obj.refresh_from_db() assert obj.users.all().count() > 1 # Delete 1 user of the project user1.delete() # The project should still exist and it should have 1 user > obj.refresh_from_db() core/tests/test_signals.py:52: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ../.tox/py36/lib/python3.6/site-packages/django/db/models/base.py:592: in refresh_from_db db_instance = db_instance_qs.get() _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = [], args = (), kwargs = {}, clone = [], num = 0 def get(self, *args, **kwargs): """ Performs the query and returns a single object matching the given keyword arguments. """ clone = self.filter(*args, **kwargs) if self.query.can_filter() and not self.query.distinct_fields: clone = clone.order_by() num = len(clone) if num == 1: return clone._result_cache[0] if not num: raise self.model.DoesNotExist( "%s matching query does not exist." % > self.model._meta.object_name ) E readthedocs.oauth.models.DoesNotExist: RemoteOrganization matching query does not exist. ../.tox/py36/lib/python3.6/site-packages/django/db/models/query.py:387: DoesNotExist ================================================================= 2 failed, 2 passed in 12.99 seconds ================================================================== ERROR: InvocationError for command '/Users/safwan/readthedocs/.tox/py36/bin/py.test core -s --reuse-db -vvv' (exited with code 1)

Maybe is worth it to add a test for the delete_account view too

Yeah, I am going to add some test on that! but its out of scope of this PR!
will open another PR for that!

Great, test output looks good. That's what I'd expect if the delete cascaded to the project

agjohnson · 2018-08-28T15:11:06Z

readthedocs/core/signals.py

@@ -79,12 +80,16 @@ def decide_if_cors(sender, request, **kwargs):  # pylint: disable=unused-argumen
 def delete_projects_and_organizations(sender, instance, *args, **kwargs):
    # Here we count the owner list from the projects that the user own
    # Then exclude the projects where there are more than one owner
-    projects = instance.projects.all().annotate(num_users=Count('users')).exclude(num_users__gt=1)
+    # Add annotate before filter
+    # https://bit.ly/2Nne6ZJ


+1 on dropping bitly link from code. pointing to a github issue or self-reference the pr, or noqa on the line all work for this case.

agjohnson · 2018-08-28T15:12:12Z

readthedocs/core/signals.py

-                                                       .exclude(num_users__gt=1))
+    oauth_organizations = (RemoteOrganization.objects.annotate(num_users=Count('users'))
+                                                     .filter(users=instance.id)
+                                                     .exclude(num_users__gt=1))


These changes should conform to our styleguide by running pre-commit on the file

I think it does not break PEP8 styleguide. Can you explain how it would change?

Perhaps a link to the style guide is warranted. I don't know of any RTD style guide outside of what the tests do. I searched our docs but I came up empty.

We have the style guide inside pre-commit p:

Yup, no explicit styleguide. it's all enforced by pre-commit via yapf and friends. In this specific case, we opt for no right side alignment of variables and arguments. Both are pep8 compliant, but right side alignment is too unreadable and annoying to maintain.

Info on pre-commit procedure is here:
https://docs.readthedocs.io/en/latest/contribute.html#contributing-to-development

safwanrahman · 2018-08-28T16:01:52Z

updated!

davidfischer

Overall, this is a good fix.

At some level, this bug was a mismatch between the expectations of the user and reality. One thing that would clear this up is to show on the delete screen exactly what is going to be removed by a user deleting their account (at least the projects). The Django Admin does this and I think it's a good pattern. That way there are fewer surprises.

davidfischer · 2018-08-28T18:59:23Z

readthedocs/core/signals.py

-                                                       .exclude(num_users__gt=1))
+    oauth_organizations = (RemoteOrganization.objects.annotate(num_users=Count('users'))
+                                                     .filter(users=instance.id)
+                                                     .exclude(num_users__gt=1))


Perhaps a link to the style guide is warranted. I don't know of any RTD style guide outside of what the tests do. I searched our docs but I came up empty.

davidfischer · 2018-08-28T19:22:45Z

readthedocs/core/signals.py

+    # https://github.com/rtfd/readthedocs.org/pull/4577
+    # https://docs.djangoproject.com/en/2.1/topics/db/aggregation/#order-of-annotate-and-filter-clauses # noqa
+    projects = (Project.objects.annotate(num_users=Count('users')).filter(users=instance.id)
+                                                                  .exclude(num_users__gt=1))


I ran this query and it seems correct to me.

agjohnson · 2018-08-28T20:01:17Z

Showing changes would be interesting. Though:

It might be too noisey unless we prune the list some how
It might be inaccurate unless we copy what the admin does -- that is, we don't want to just show our interpretation of what is changing, but what is actually changing at the database

Fixing the logic here i think matches user expectations at least

humitos · 2018-08-29T09:52:09Z

I like @davidfischer's idea about showing what's going to delete. Although, I think we can implement that in another PR and merge this fix soon since it's an important bug and may cause more nightmares to us dealing with the backups.

Also, I'd like to think and discuss a little more about what to show. On one side, I suppose that showing the Projects to be deleted is enough, but that seems to be the "common sense" thought and maybe doesn't worth to make it explicit. On another side, I don't want to go too verbose, as @agjohnson said.

Maybe we can take a look at what other services do for a similar flow.

davidfischer · 2018-08-29T15:51:06Z

It might be too noisey unless we prune the list some how

I think only showing the projects is good. If deleting their account means deleting a lot of projects I think it would be nice to know that.

It might be inaccurate unless we copy what the admin does -- that is, we don't want to just show our interpretation of what is changing, but what is actually changing at the database

This is not quite correct. Deleting a user in the admin would not delete any projects. We implemented custom logic to delete projects based on a signal. If we plan to only show which projects are deleted, then we only need to copy our own logic.

I think we can implement that in another PR

That's fair.

agjohnson · 2018-08-29T22:05:35Z

I want to get this out and style fixes weren't applied. I merged manually.

safwanrahman · 2018-08-30T11:28:08Z

Thanks @agjohnson. Sorry I missed the styling issue with the pull request discussion!

safwanrahman requested review from agjohnson, humitos and davidfischer August 28, 2018 11:38

humitos reviewed Aug 28, 2018

View reviewed changes

agjohnson requested changes Aug 28, 2018

View reviewed changes

safwanrahman added 4 commits August 28, 2018 21:32

[Fix readthedocs#4576] Do not delete projects which have multiple users

57003c6

adding more tests

bb4f6e8

fixup

33e4157

adding self reference PR

f46abb5

safwanrahman force-pushed the project_delete branch from 11b6633 to f46abb5 Compare August 28, 2018 15:42

davidfischer reviewed Aug 28, 2018

View reviewed changes

agjohnson added this to the 2.7 milestone Aug 28, 2018

agjohnson merged commit f46abb5 into readthedocs:master Aug 29, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Fix #4576] Do not delete projects which have multiple users #4577

[Fix #4576] Do not delete projects which have multiple users #4577

safwanrahman commented Aug 28, 2018

humitos left a comment

humitos Aug 28, 2018

safwanrahman Aug 28, 2018 •

edited

Loading

humitos Aug 28, 2018

agjohnson Aug 28, 2018

humitos Aug 28, 2018

safwanrahman Aug 28, 2018

humitos Aug 29, 2018

humitos commented Aug 28, 2018

agjohnson left a comment

agjohnson Aug 28, 2018

agjohnson Aug 28, 2018

safwanrahman Aug 28, 2018

stsewd Aug 28, 2018

safwanrahman Aug 28, 2018

agjohnson Aug 28, 2018

agjohnson Aug 28, 2018

agjohnson Aug 28, 2018

safwanrahman Aug 28, 2018

davidfischer Aug 28, 2018

stsewd Aug 28, 2018

agjohnson Aug 28, 2018

agjohnson Aug 28, 2018

safwanrahman commented Aug 28, 2018

davidfischer left a comment

davidfischer Aug 28, 2018

davidfischer Aug 28, 2018

agjohnson commented Aug 28, 2018

humitos commented Aug 29, 2018

davidfischer commented Aug 29, 2018

agjohnson commented Aug 29, 2018

safwanrahman commented Aug 30, 2018



		@pytest.mark.django_db
		class TestProjectOrganizationSignal(object):

[Fix #4576] Do not delete projects which have multiple users #4577

[Fix #4576] Do not delete projects which have multiple users #4577

Conversation

safwanrahman commented Aug 28, 2018

humitos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

safwanrahman Aug 28, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

humitos commented Aug 28, 2018

agjohnson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

safwanrahman commented Aug 28, 2018

davidfischer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

agjohnson commented Aug 28, 2018

humitos commented Aug 29, 2018

davidfischer commented Aug 29, 2018

agjohnson commented Aug 29, 2018

safwanrahman commented Aug 30, 2018

safwanrahman Aug 28, 2018 •

edited

Loading