Ви не можете вибрати більше 25 тем Теми мають розпочинатися з літери або цифри, можуть містити дефіси (-) і не повинні перевищувати 35 символів.

use_a_custom_user_model.rst 2.9KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576
  1. ==============================
  2. How to use a custom user model
  3. ==============================
  4. If you are using Django 1.5 or later, then you can specify a custom user model
  5. in your settings. Oscar will dynamically adjust the profile summary view and
  6. profile editing form to use the fields from your custom model.
  7. Before Django 1.5, the recommended technique for adding fields to users was to
  8. use a one-to-one "profile" model specified in the ``AUTH_PROFILE_MODULE``. As
  9. of Django 1.5, this setting is deprecated and will be removed_ in Django 1.7.
  10. Nevertheless, Oscar continues to support this setting and will add relevant
  11. fields to the profile form. Hence profiles can be used in combination with
  12. custom user models. That doesn't mean it's a good idea.
  13. .. _removed: https://docs.djangoproject.com/en/1.5/internals/deprecation/#id4
  14. Restrictions
  15. ------------
  16. Oscar does have some requirements on what fields a user model has. For
  17. instance, the auth backend requires a user to have an 'email' and 'password'
  18. field.
  19. Oscar 0.6 ships with its own abstract user model that supports the minimum
  20. fields and methods required for Oscar to work correctly. New Oscar projects
  21. are encouraged to subclass this User model.
  22. Migrations
  23. ----------
  24. It has previously been suggested to set ``db_table`` of the model to
  25. ``auth_user`` to avoid the migrations from breaking. This issue has been fixed
  26. and migrations are now using ``AUTH_USER_MODEL`` and ``AUTH_USER_MODEL_NAME``
  27. which will use ``db_table`` name of the user model provided by
  28. ``get_user_model()``.
  29. This works in the instances where you are using the default ``auth.User`` model
  30. or when you use a custom user model from the start. Switching over from
  31. ``auth.User`` to a custom model after having applied previous migration of
  32. Oscar will most likely require renaming the ``auth_user`` table to the new user
  33. table in a manual schemamigration.
  34. Example
  35. -------
  36. If you want to use ``oscar.apps.customer.abstract_model.AbstractUser``
  37. which has ``email`` as an index, and want to customize some of the methods on
  38. ``User`` model, say, ``get_full_name`` for Asian names, a simple approach is
  39. to create your own ``user`` module::
  40. # file: your-project/apps/user/models.py
  41. from django.db import models
  42. from oscar.apps.customer.abstract_models import AbstractUser
  43. class User(AbstractUser):
  44. def get_full_name(self):
  45. full_name = '%s %s' % (self.last_name.upper(), self.first_name)
  46. return full_name.strip()
  47. Then adding this ``user`` app to the ``INSTALLED_APPS`` list. Beside that we
  48. need to tell ``django`` to use our customized user model instead of the
  49. default one as the authentication model [1]_::
  50. # use our own user model
  51. AUTH_USER_MODEL = "user.User"
  52. After the migration, a database table called ``user_user`` will be created based
  53. on the schema defined inside of
  54. ``oscar.apps.customer.abstract_models.AbstractUser``.
  55. .. [1] https://docs.djangoproject.com/en/1.6/ref/settings/#auth-user-model