Address¶
The address app provides core address models - it doesn’t provide any views or other functionality. Of the 5 abstract models, only 2 have a non-abstract version in oscar.apps.address.models - the others are used by the order app to provide shipping and billing address models.
Abstract models¶
- class oscar.apps.address.abstract_models.AbstractAddress(*args, **kwargs)[source]¶
Bases: django.db.models.base.Model
Superclass address object
This is subclassed and extended to provide models for user, shipping and billing addresses.
- active_address_fields(include_salutation=True)[source]¶
Return the non-empty components of the address, but merging the title, first_name and last_name into a single line.
- join_fields(fields, separator=u', ')[source]¶
Join a sequence of fields using the specified separator
- populate_alternative_model(address_model)[source]¶
For populating an address model using the matching fields from this one.
This is used to convert a user address to a shipping address as part of the checkout process.
- search_text = None¶
A field only used for searching addresses - this contains all the relevant fields. This is effectively a poor man’s Solr text field.
- class oscar.apps.address.abstract_models.AbstractCountry(*args, **kwargs)[source]¶
Bases: django.db.models.base.Model
International Organization for Standardization (ISO) 3166-1 Country list.
The field names are a bit awkward, but kept for backwards compatibility. pycountry’s syntax of alpha2, alpha3, name and official_name seems sane.
- name = None¶
The full official name of a country e.g. ‘United Kingdom of Great Britain and Northern Ireland’
- numeric_code[source]¶
Shorthand for the ISO 3166 numeric code.
iso_3166_1_numeric used to wrongly be a integer field, but has to be padded with leading zeroes. It’s since been converted to a char field, but the database might still contain non-padded strings. That’s why the padding is kept.
- printable_name = None¶
The commonly used name; e.g. ‘United Kingdom’
- class oscar.apps.address.abstract_models.AbstractPartnerAddress(*args, **kwargs)[source]¶
Bases: oscar.apps.address.abstract_models.AbstractAddress
A partner can have one or more addresses. This can be useful e.g. when determining US tax which depends on the origin of the shipment.
- class oscar.apps.address.abstract_models.AbstractShippingAddress(*args, **kwargs)[source]¶
Bases: oscar.apps.address.abstract_models.AbstractAddress
A shipping address.
A shipping address should not be edited once the order has been placed - it should be read-only after that.
NOTE: ShippingAddress is a model of the order app. But moving it there is tricky due to circular import issues that are amplified by get_model/get_class calls pre-Django 1.7 to register receivers. So... TODO: Once Django 1.6 support is dropped, move AbstractBillingAddress and AbstractShippingAddress to the order app, and move PartnerAddress to the partner app.
- class oscar.apps.address.abstract_models.AbstractUserAddress(*args, **kwargs)[source]¶
Bases: oscar.apps.address.abstract_models.AbstractShippingAddress
A user’s address. A user can have many of these and together they form an ‘address book’ of sorts for the user.
We use a separate model for shipping and billing (even though there will be some data duplication) because we don’t want shipping/billing addresses changed or deleted once an order has been placed. By having a separate model, we allow users the ability to add/edit/delete from their address book without affecting orders already placed.
- hash = None¶
A hash is kept to try and avoid duplicate addresses being added to the address book.
- is_default_for_billing = None¶
Whether this address should be the default for billing.
- is_default_for_shipping = None¶
Whether this address is the default for shipping
- num_orders = None¶
We keep track of the number of times an address has been used as a shipping address so we can show the most popular ones first at the checkout.
Views¶
None.