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:
Model
Superclass address object
This is subclassed and extended to provide models for user, shipping and billing addresses.
- active_address_fields()[source]¶
Returns the non-empty components of the address, but merging the title, first_name and last_name into a single line. It uses fields listed out in base_fields property.
- clean()[source]¶
Hook for doing any extra model-wide validation after clean() has been called on every field by self.clean_fields. Any ValidationError raised by this method will not be associated with a particular field; it will have a special-case association with the field defined by NON_FIELD_ERRORS.
- generate_hash()[source]¶
Returns a hash of the address, based on standard set of fields, listed out in hash_fields property.
- get_address_field_values(fields)[source]¶
Returns set of field values within the salutation and country.
- join_fields(fields, separator=', ')[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.
- property salutation¶
Name (including title)
- save(*args, **kwargs)[source]¶
Save the current instance. Override this in a subclass if you want to control the saving process.
The ‘force_insert’ and ‘force_update’ parameters can be used to insist that the “save” must be an SQL insert or update (or equivalent for non-SQL backends), respectively. Normally, they should not be set.
- property summary¶
Returns a single string summary of the address, separating fields using commas.
- class oscar.apps.address.abstract_models.AbstractBillingAddress(*args, **kwargs)[source]¶
Bases:
AbstractAddress
- property order¶
Return the order linked to this shipping address
- class oscar.apps.address.abstract_models.AbstractCountry(*args, **kwargs)[source]¶
Bases:
Model
The field names are a bit awkward, but kept for backwards compatibility. pycountry’s syntax of alpha2, alpha3, name and official_name seems sane.
- property code¶
Shorthand for the ISO 3166 Alpha-2 code
- name¶
The full official name of a country e.g. ‘United Kingdom of Great Britain and Northern Ireland’
- property numeric_code¶
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¶
The commonly used name; e.g. ‘United Kingdom’
- class oscar.apps.address.abstract_models.AbstractPartnerAddress(*args, **kwargs)[source]¶
Bases:
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:
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.
- property order¶
Return the order linked to this shipping address
- class oscar.apps.address.abstract_models.AbstractUserAddress(*args, **kwargs)[source]¶
Bases:
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¶
A hash is kept to try and avoid duplicate addresses being added to the address book.
- is_default_for_billing¶
Whether this address should be the default for billing.
- is_default_for_shipping¶
Whether this address is the default for shipping
- num_orders_as_billing_address¶
Same as previous, but for billing address.
- num_orders_as_shipping_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.
Views¶
None.