Split payment models into abstract and concrete versions
Hattip to @BuddhaOhneHals for doing this in the first place.
Unfortunately, I couldn't (be bothered to) merge the original commit as
the merge conflicts were too painful to resolve - simpler to just
reapply the same change myself.
Fixes #466
- Added stubs for both apps
- Switched to using :automodule: for abstract models instead of
individual :autoclass:
- Added instructions on creating a Partner and ProductClass instance
when setting up a new Oscar instance
The mailing list raised the issue of having to include the models.py to
replace a Form. The docs weren't clear, so I've taken the opportunity
to:
* merge 'INSTALLED_APPS' section and 'models.py & admin.py'.
* change misc wordings and add clarifications
- Made instructions on using a custom template more expliciy. Should be
better for new users.
- Fixes a few typos and mistakes in the code examples.
This commit is squash of pull request #640.
Attempt at making it clearer what needs to be done for what kind of
customisation. Created a new topic that lines out the prepatory
steps that need to be taken, and moved duplicate information from the
how-tos into the new topic.
The old howto included out-dated info on how to translate Oscar. That
has been replaced by a link to the Transifex project.
It was the only howto left under the Contributing headline, which really
shouldn't be there (as there's an entirely different section in the docs
for contributing). As it is more of a topic anyway, and will hopefully
soon include documentation on translation style etc., it was turned into
a topic.
OSCAR_REQUIRED_ADDRESS_FIELDS allows setting which fields are required.
The use case is that post codes are expected to be required, but many
countries don't actually use them.