cookiecutter-django: Unknown field(s) (first_name, last_name) specified for User in admin

What happened?

I created a new cookiecutter-django project and went through the steps here to get started. Then I created a superuser and logged in, but when I click on the edit user link from the admin view I get the following error:

django.core.exceptions.FieldError: Unknown field(s) (first_name, last_name) specified for User. Check fields/fieldsets/exclude attributes of class UserAdmin.
image

What should’ve happened instead?

Instead I should have gotten to the edit user admin page.

Additional details

  • Host system configuration:
    • Version of cookiecutter CLI (get it with cookiecutter --version): Cookiecutter 1.7.2 from /Users/leo/.virtualenvs/cryptoswap/lib/python3.9/site-packages (Python 3.9)
    • OS: OSX
    • Python version: Python 3.9.1
    • Docker versions (if using Docker): not using docker
  • Options selected and/or replay file:
    	{
    "cookiecutter": {
    "project_name": "CryptoSwap",
    "project_slug": "cryptoswap",
    "description": "Bitcoin ATMs",
    "author_name": "Leo Policastro",
    "domain_name": "access.cryptoswap.com",
    "email": "leo-policastro@example.com",
    "version": "0.1.0",
    "open_source_license": "MIT",
    "timezone": "UTC",
    "windows": "n",
    "use_pycharm": "n",
    "use_docker": "n",
    "postgresql_version": "12.3",
    "js_task_runner": "Gulp",
    "cloud_provider": "AWS",
    "mail_service": "Mailgun",
    "use_async": "n",
    "use_drf": "y",
    "custom_bootstrap_compilation": "n",
    "use_compressor": "n",
    "use_celery": "n",
    "use_mailhog": "n",
    "use_sentry": "n",
    "use_whitenoise": "n",
    "use_heroku": "y",
    "ci_tool": "Github",
    "keep_local_envs_in_vcs": "n",
    "debug": "n",
    "_template": "gh:pydanny/cookiecutter-django"
    }
    

} ``` Am I doing something wrong? I used cookiecutter for a different project last week and I did not have the same issue.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 18 (16 by maintainers)

Commits related to this issue

Most upvoted comments

There was indeed some patching magic going on. You hinted me in the right direction. I simply removed that code and now recreating does not create these columns anymore. I can thus safely drop the columns from the existing database. Thank you @Andrew-Chen-Wang 🙏

I’ve updated the PR with a few tests, seems to be working. Could one of you have a quick look? Feedback would be appreciated.