Heeelllp! Can't get to dashboard because of unexplained error with "resolve()" (django 1.19, python3)

[Mike Robinson]

I just installed "pip3 django-oscar" in the usual way and I added the shop urls under "/shop" to my urls.py.

I find that I can get to the shop but not to the dashboard with "/shop/dashboard."  I get an error from the default dashboard auth-fn.

ImproperlyConfigured: Please follow Oscar's default dashboard app layout or set a custom access_fn

So I put some debugging messages into my local copy and now things start to get weird.

url-name 'dashboard:promotion-list-by-page' 

gets url '/shop/dashboard/content-blocks/pages/' 

view_module 'django.contrib.flatpages.views'

Huh?!  So I go into the manage.py shell and try some one-liners.  This one's good:

>>> resolve(r'/shop/dashboard/content-blocks/create/')

ResolverMatch(func=oscar.apps.dashboard.promotions.views.CreateRedirectView, args=(), kwargs={}, url_name=promotion-create-redirect, app_names=[], namespaces=['dashboard'])

... but this one tries to go to flatpages!

>>> resolve(r'/shop/dashboard/content-blocks/pages/')

ResolverMatch(func=django.contrib.flatpages.views.flatpage, args=(), kwargs={'url': ''}, url_name=django.contrib.flatpages.views.flatpage, app_names=[], namespaces=[])

... and I'm sure that I am looking at the Python code that defines both:

    def get_urls(self):

        urls = [

            url(r'^$', self.list_view.as_view(), name='promotion-list'),

            url(r'^pages/$', self.page_list.as_view(),

                name='promotion-list-by-page'),

            url(r'^page/(?P<path>/([\w-]+(/[\w-]+)*/)?)$',

                self.page_detail.as_view(), name='promotion-list-by-url'),

            url(r'^create/$',

                self.create_redirect_view.as_view(),

"promotion-list-by-page" occurs only once in the source-code.  As I said above – "reverse()" produces the URL-string indicated, but it resolves to a flatpage while its next-door-neighbor resolves properly to a create-view.  I also printed the class-name so I also know that "PageDetailView" is what's being referenced.

Yes, I -am- running under Python 3...

I simply cannot explain why one URL is not being resolved while its next-door-neighbor is.  Especially since the URL that I'm trying to resolve, came from "reverse()!"

[Mike Robinson]

To clarify:  "/shop" DOES take me to the shop.  But, "/shop/dashboard" produces this error as described.

[Mike Robinson]

Also, I tried to turn OFF the flatpages middleware.  Doesn't seem to make any difference.

On Friday, January 5, 2018 at 11:41:52 AM UTC-5, Mike Robinson wrote:

[Mike Robinson]

This does NOT appear to be a duplicate of GitHub issue #2259 because removing "/shop/" does not change the outcome ...

>>> resolve(r'/dashboard/content-blocks/pages/')

... and also because some URLs which contain it are, as noted, resolved.

On Friday, January 5, 2018 at 11:41:52 AM UTC-5, Mike Robinson wrote:

[Mike Robinson]

I was able to bypass the problem and to use the dashboard – without further incident – by creating the following in my application "settings.py":

def MyDashboardAccessFunction(user, url_name, *url_args, **url_kwargs):

    return user.is_staff

OSCAR_DASHBOARD_DEFAULT_ACCESS_FUNCTION = 'mysite.settings.MyDashboardAccessFunction'

... where "mysite" is the name of the site folder where this "urls.py" file lives.

But, this problem should be looked into and resolved.  The default access-function that you provide is a much cleaner design, and it should work.

[Mike Robinson]

"D'oh!!" 

"D'oh!! D'oh!! D'oh!!"

I found it.  (As Jim Carey said in "Liar, Liar," "it was me!")  

My base URLconf within the application contained this:

    # Flat pages

    url(r'pages/',

        include('django.contrib.flatpages.urls')),

Uh huh ... there it is:  "No Hat!!"  Therefore, it would match "pages/" anywhere in the string, thus intercepting your URLs.

The corrected version reads:

    # Flat pages

    url(r'^pages/',

        include('django.contrib.flatpages.urls')),

Now the string is matched only if it appears at the front of the URL, not anywhere.

So, there you have it:  "never allow your URL-patterns to leave home without their '^' hats!"