But as Oscar is built as a highly customisable and extendable framework, it
doesn’t stop there. The behaviour of all Oscar apps can heavily be altered
by injecting your own code.

To extend the behavior of an Oscar core app, it needs to be forked, which is
achieved with a simple management command. Afterwards, you should
generally be able to override any class/model/view by just dropping it
in the right place and giving it the same name.

In some cases, customising is slightly more involved. The following how-tos
give plenty of examples for specific use cases:

Calling ./manage.pyoscar_fork_apporderyourproject/order app will be placed in project_root/yourproject/ directory.
Calling ./manage.pyoscar_fork_apporder.order app will be placed in project_root/ directory.

get_core_apps([]) will return a list of Oscar core apps. If you supply a
list of additional apps, they will be used to replace the Oscar core apps.
In the above example, yourproject.order will be returned instead of
oscar.apps.order.

You can now override every class (that is
dynamically loaded, which is
almost every class) in the app you’ve replaced. That means forms,
views, strategies, etc. All you usually need to do is give it the same name
and place it in a module with the same name.

Suppose you want to alter the way order numbers are generated. By default,
the class oscar.apps.order.utils.OrderNumberGenerator is used. So just
create a class within your order app which
matches the module path from oscar: order.utils.OrderNumberGenerator. This
could subclass the class from Oscar or not: