Basket middleware active in Django admin

When loading Django admin, the basket middleware failed (below; worthy of a separate less critical issue). It should detect Django admin and not do anything.

  File "/home/jayvdb/.cache/pypoetry/virtualenvs/django-backend-tUiU8616-py3.8/src/django-oscar/src/oscar/apps/basket/middleware.py", line 41, in load_full_basket
    self.apply_offers_to_basket(request, basket)
  File "/home/jayvdb/.cache/pypoetry/virtualenvs/django-backend-tUiU8616-py3.8/src/django-oscar/src/oscar/apps/basket/middleware.py", line 207, in apply_offers_to_basket
    Applicator().apply(basket, request.user, request)
  File "/home/jayvdb/.cache/pypoetry/virtualenvs/django-backend-tUiU8616-py3.8/src/django-oscar/src/oscar/apps/offer/applicator.py", line 24, in apply
    self.apply_offers(basket, offers)
  File "/home/jayvdb/.cache/pypoetry/virtualenvs/django-backend-tUiU8616-py3.8/src/django-oscar/src/oscar/apps/offer/applicator.py", line 34, in apply_offers
    result = offer.apply_benefit(basket)
  File "/home/jayvdb/.cache/pypoetry/virtualenvs/django-backend-tUiU8616-py3.8/src/django-oscar/src/oscar/apps/offer/abstract_models.py", line 293, in apply_benefit
    if not self.is_condition_satisfied(basket):
  File "/home/jayvdb/.cache/pypoetry/virtualenvs/django-backend-tUiU8616-py3.8/src/django-oscar/src/oscar/apps/offer/abstract_models.py", line 281, in is_condition_satisfied
    return self.condition.proxy().is_satisfied(self, basket)
  File "/home/jayvdb/.cache/pypoetry/virtualenvs/django-backend-tUiU8616-py3.8/src/django-oscar/src/oscar/apps/offer/abstract_models.py", line 48, in proxy
    klass = load_proxy(self.proxy_class)
  File "/home/jayvdb/.cache/pypoetry/virtualenvs/django-backend-tUiU8616-py3.8/src/django-oscar/src/oscar/apps/offer/utils.py", line 29, in load_proxy
    raise exceptions.ImproperlyConfigured(
django.core.exceptions.ImproperlyConfigured: Error importing module oscarbluelight.offer.conditions: No module named 'oscarbluelight'

[solarissmoke]

Having given this some thought, and my suggestion is that we allow short-circuiting the middleware for certain path prefixes (see sample implementation here).

Projects can then exclude whatever they want to - including the Django admin and possibly also the dashboard (plus anything else - it’s common to have a CMS for other content etc). This would actually result in a significant performance improvement for the dashboard.

[solarissmoke]

Looking at this more closely it seems the underlying issue is that there is a reference to a proxy benefit/condition class that no longer exists. Oscar could probably handle that more gracefully - i.e., log the error and return no benefit/condition instead of throwing an exception. Can you confirm that that is what happened?

As regards your other comments, I would request that you try to be a little more measured in the tone of your statements. Statements like “As I said already”, “if you insist that…”, “don’t expect Oscar to do voodoo…” and “most certainly never breaking the Django admin front page” come across as somewhat aggressive/impatient, and are not going to encourage discussion. Everyone that contributes to this project does so in their spare time, and is more likely to engage if the tone is respectable.

In this particular case I would note that Oscar explicitly declares that it does not officially support the Django admin - so it doesn’t actually provide any guarantee that the admin will be functional. I am not saying that that is ideal (especially since some things cannot be done from the dashboard) - but it’s where we are - and we can discuss how to improve things without making blanket statements that leave no room for debate.