Paul Walsh mentioned he's having some issues with shipping third-party Oscar extensions with a dashboard.
The way I see it there's a few issues that need thinking about:
a) We need to gain an understanding of how people customise the dashboard menus. Based on that, we should decide if we stick with the declarative approach currently employed (setting DASHBOARD_MENU), or consider a registration approach (similar to the Django admin).
b) We need a flexible way to hide dashboard menu entries that a user doesn't have access too. That's necessary for the permission-based dashboard.
c) We need to decide whether dashboard sub-apps should live beneath a dashboard app, or under their app.
All the while, get_classes must keep working, and we should keep the app refactor coming in Django 1.7 in mind.
specialunderwear
commented
1 year ago
Paul Walsh mentioned he's having some issues with shipping third-party Oscar extensions with a dashboard.
The way I see it there's a few issues that need thinking about:
a) We need to gain an understanding of how people customise the dashboard menus. Based on that, we should decide if we stick with the declarative approach currently employed (setting
DASHBOARD_MENU), or consider a registration approach (similar to the Django admin).b) We need a flexible way to hide dashboard menu entries that a user doesn't have access too. That's necessary for the permission-based dashboard.
c) We need to decide whether dashboard sub-apps should live beneath a dashboard app, or under their app.
All the while,
get_classesmust keep working, and we should keep the app refactor coming in Django 1.7 in mind.