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.


Return the non-empty components of the address, but merging the title, first_name and last_name into a single line.


Validate postcode given the country


Returns a hash of the address summary

join_fields(fields, separator=u', ')[source]

Join a sequence of fields using the specified separator


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.


Name (including title)


A field only used for searching addresses - this contains all the relevant fields. This is effectively a poor man’s Solr text field.


Returns a single string summary of the address, separating fields using commas.

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.


Shorthand for the ISO 3166 Alpha-2 code


The full official name of a country e.g. ‘United Kingdom of Great Britain and Northern Ireland’


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.


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.


Return the order linked to this shipping address

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.


A hash is kept to try and avoid duplicate addresses being added to the address book.


Whether this address should be the default for billing.


Whether this address is the default for shipping


Same as previous, but for billing address.


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.

save(*args, **kwargs)[source]

Save a hash of the address fields