Bug fix when deleting user from admin interface

[avilches]

Summary

Error when a user is deleted in the Django admin interface:

gateway     | Internal Server Error: /backoffice/auth/user/2/delete/
gateway     | Traceback (most recent call last):
gateway     |   File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 89, in _execute
gateway     |     return self.cursor.execute(sql, params)
gateway     |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gateway     | psycopg2.errors.UndefinedTable: relation "allauth_emailaddress" does not exist
gateway     | LINE 1: ...user"."is_active", "auth_user"."date_joined" FROM "allauth_e...

From @Tansito:

From what I understood the problem is that it's trying to access to allauth tables that don't exist so with our current authentication configuration we could:

• Remove django-allauth[socialaccount]
• Remove dj-rest-auth
• And maybe the simplejwt dependency, but I'm not sure about this one

This PR removes all these dependencies, disabled them from the INSTALLED_APPS and update the configuration settings and test to ensure everything works as expected.

[avilches]

Funny, the database population when running tests does include the allauth tables. So, when I removed the dependencies, fewer records are created and the primary keys changed.

[Tansito]

Hehe as I commented in the PR from @paaragon this is a bit tricky:

#1791 (comment)

Feel free to ping @korgan00 for more info. If the situation it's not clear we can comment it Monday when I return.

[ElePT]

Note regarding the failure in Tests QS on Kubernetes: it looks like something strange was going on with the kind download yesterday, and this affected the Tests QS on Kubernetes action, but I think that it was fixed today, so re-running the failed test should do the trick.

[Tansito]

If someone tests this PR before me please be aware that this PR it is a bit special. It's not so important that all the tests passed if not that this PR can be executed in a database previously created without errors.

[ElePT]

If someone tests this PR before me please be aware that this PR it is a bit special. It's not so important that all the tests passed if not that this PR can be executed in a database previously created without errors.

What would you recommend as the best path for testing this change @Tansito? Reviewing the code in my case wouldn't help much without having the ability to test it.

[Tansito]

I would say the correct way to test it would be:

1. From main run the docker compose to apply the migrations from main
2. We can execute a very simple job locally
3. Stop the docker compose and move to this branch
4. Execute again the docker compose to verify that the migrations from database work
5. Run another job locally just verify that everything works or navigate through the panel administrator

[avilches]

I would say the correct way to test it would be:

1. From main run the docker compose to apply the migrations from main
2. We can execute a very simple job locally
3. Stop the docker compose and move to this branch
4. Execute again the docker compose to verify that the migrations from database work
5. Run another job locally just verify that everything works or navigate through the panel administrator

I can do this test too. But I feel it's a little overkill... I mean, what's so special about this PR compared to any other PR that includes database migrations? If there's nothing special, should we repeat all these steps to test every PR that has a database migration? Don't get me wrong, I just want to know if we're dealing with a potential error that requires these manual tests. And if so, automate them.

[ElePT]

I think that @avilches raises a valid point, but on my side I can say that I ran the manual test and everything seemed to work, jobs ran, migrations seemed to be applied successfully.

[Tansito]

What it makes this PR different from another migration is that other migrations are auto-generated but this one specifically is our first manual database migration (I think it was manually created by you @avilches , at least, correct me if it was not like that). It's not that I don't trust on your skills Alberto, don't get me wrong, but I wouldn't consider the same implications an autogenerated migration that a migration created manually. That is my reason.

[avilches]

Tested in local with Postgres (docker-compose)

1. main branch and docker-compose -f docker-compose-dev.yaml up -d gateway
2. Executed a job using the 01_running_program.ipynb against localhost:8000. It worked (as expected)
3. checkout the branch bugfix-deleting-user
4. build the Gateway image with the Postgres specific migration: docker-compose -f docker-compose-dev.yaml build gateway
5. restart the Gateway with docker-compose -f docker-compose-dev.yaml up -d gateway
6. logs show the Postgres migration worked fine:

7. Backoffice admin works. Now it doesn't show the Social account sections.

8. Tried again to run a jub. It worked.

The PR is safe to merge @Tansito

[avilches]

Postgres before and after