Multiple admin sites with different admin-tools configurations?
Nan
I need to run multiple admin sites for different subsets of users, and
would like to be able to use django-admin-tools in order to add
descriptions to each model's listing, etc. However, the admin tools
settings appear to be global. Is it possible to use different
settings for different admin sites?
Thanks!
Alex Robbins
init_with_context function[1] in the dashboard class. You would add
different things depending on the request url. If there were small
differences, that would be a pretty clean way to do it. If they are
two completely different admins, that might get a little ugly.
Alex
> --
> You received this message because you are subscribed to the Google Groups "django-admin-tools" group.
> To post to this group, send email to django-ad...@googlegroups.com.
> To unsubscribe from this group, send email to django-admin-to...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-admin-tools?hl=en.
>
>
David Jean Louis
You could also implement a callable, i.e. "custom_dashboard_factory()",
that would return the Dashboard class conditionally, given the current site.
Then you just have to set the ADMIN_TOOLS_INDEX_DASHBOARD to your
factory function.
--
David
Le 22/06/2010 15:49, Alex Robbins a �crit :
patrickk
I neither understand alex reply with using init_with_context nor
davids with using a custom_dashboard_factory.
@david: when you say that "that would return the Dashboard class
conditionally, given the current site", you´re talking about the
"current admin-site", right?
thanks a lot,
patrick
On 22 Jun., 21:13, David Jean Louis <izimo...@gmail.com> wrote:
> Hi,
>
> You could also implement a callable, i.e. "custom_dashboard_factory()",
> that would return the Dashboard class conditionally, given the current site.
> Then you just have to set the ADMIN_TOOLS_INDEX_DASHBOARD to your
> factory function.
>
> --
> David
>
> Le 22/06/2010 15:49, Alex Robbins a crit :
>
> > I think you could implement that functionality using the
> > init_with_context function[1] in the dashboard class. You would add
> > different things depending on the request url. If there were small
> > differences, that would be a pretty clean way to do it. If they are
> > two completely different admins, that might get a little ugly.
>
> > Alex
>
David JL
honestly I've never tried django-admin-tools with multiple admin sites
(with AdminSite instances), so I'm not sure it will work.
What I was thinking is something like this:
someapp/utils.py
"""
from someapp.admin import siteA, siteB
from someapp import dashboards
def custom_dashboard_factory():
if sometest(siteA, siteB):
return dashboards.SiteACustomDashboard()
return dashboards.SiteBCustomDashboard()
"""
someapp/settings.py
"""
ADMIN_TOOLS_INDEX_DASHBOARD = 'someapp.utils.custom_dashboard_factory'
"""
But again, I'm not sure if it will work and especially my solution
doesn't give access to the current request object which I guess is
needed to know what's the current admin site...
I don't what to speak for him but I think that what Alex proposes is
something like:
someapp.dashboards.py
"""
from admin_tools.dashboard import Dashboard
class MyDashboard(Dashboard):
def init_with_context(self, request):
if sometest(request):
self.append(module_for_siteA_1)
self.append(module_for_siteA_2)
# etc...
else:
self.append(module_for_siteB_1)
self.append(module_for_siteB_2)
# etc...
"""
Here you have access to the request...
I hope it's a bit more clear ;)
--
David
2010/7/12 patrickk <sehma...@gmail.com>:
--
David JL <izim...@gmail.com>
patrickk
approach.
problem is that I need to access different admin-sites. currently, I´m
not able to add apps from a second admin-site instance to an AppList
within dashboard.py (for example).
shouldn´t it be easy to work with multiple admin-sites (and admin-
tools)? I mean, that´s a very basic admin-interface functionality,
right?
proposal:
IMO, it should be possible to define different dashboards
(dashboard.py) for different admin-sites. don´t ask me how to achieve
that though ...
regards,
patrick
Alex Robbins
as it could be.
It would help us if you could tell us what the problem is. How did the
first method fail? What did you try? What were the errors? How did the
second method fail? What did you try....etc.
David was correct about my approach. I was thinking you'd do this:
someapp.dashboards.py
"""
from admin_tools.dashboard import Dashboard
class MyDashboard(Dashboard):
def init_with_context(self, request):
if sometest(request):
self.append(module_for_siteA_1)
self.append(module_for_siteA_2)
# etc...
else:
self.append(module_for_siteB_1)
self.append(module_for_siteB_2)
# etc...
"""
and then sometest would look at the request's url to decide which
admin site it was in.
def sometest(request):
return request.path.startswith('/url/to/admin_site_A/')
I agree it would be nice to explicitly assign dashboards to admin
instances, but it isn't implemented that way right now and everyone is
busy. Definitely make an enhancement issue for that. It would be good,
but it might be a (long) while.
Good luck!
Alex
patrickk
thanks for your help.
the problem is that I can´t append apps registered with the 2nd admin-
site. that´s all.
class CustomIndexDashboard(Dashboard):
...
def init_with_context(self, context):
if context["request"].path == "/admin/":
... do something with apps registered with this admin-site
... works!
if context["request"].path == "/second-admin-site/":
... do something with apps registered with the second
admin-site
... apps are not available.
regards,
patrick
On Jul 13, 3:47 pm, Alex Robbins <alexander.j.robb...@gmail.com>
wrote:
Alex Robbins
I'll have to get back to you on that (after more thinking).
Alex
David JL
that the admin site is the default admin site
(django.contrib.admin.site), hence, they don't support custom
AdminSite instances...
Maybe a solution would be to add a "site" property to dashboards ?
(hey, I'm on holidays :) patches welcome !)
Regards,
--
David
2010/7/13 Alex Robbins <alexander...@gmail.com>:
--
David JL <izim...@gmail.com>
Klemens Mantzos
grappelli_admin_tools can do this now
(http://bitbucket.org/fetzig/grappelli-admin-tools/).
@everybody: ATTENTION grappelli_admin_tools is a fork especially for
django-grappelli. we thought it would be nice to sort and group the
apps/models as we want and admin_tools.dashboard seems to do that very
good. so grappelli_admin_tools is an customized admin_tools.dashboard
only (no menu, no theming). => can't make any assumptions about the
other parts of admin_tools.
how to get multiple AdminSite's workin':
1) new settings:
ADMIN_TOOLS_INDEX_DASHBOARD = {
'www.admin.main_site': 'www.dashboard.CustomIndexDashboard',
...
the name of the AdminSite has to be equal to its name in the namespace
(will maybe change this).
i.e. main_site = AdminSite("main_site")
2) added functionality to all functions which get
ADMIN_TOOLS_INDEX_DASHBOARD and ADMIN_TOOLS_APP_INDEX_DASHBOARD (if
dict then...)
3) checked for all reverse('admin:... calls and replaced "admin" with
result of get_admin_site_name(context)
don't know if i missed some stuff, but it seems to work fine with two
AdminSite instances, and works still with one instance too :)
please send me feedback.
@izi/david/half programmer half amazing: great! it's such a pleasure
to hack into your code. hope you like the feature.
greets,
klemens
--
klemens mantzos
http://fetzig.at/
David Jean Louis
sorry for the delay...
I'll have to check this out, I don't have a multi admin site test
project currently but I will do.
> @izi/david/half programmer half amazing: great! it's such a pleasure
> to hack into your code. hope you like the feature.
>
Thanks ! and I'd like to forward the compliment to the people who are
contributing: alex, mike, just to name a few.
Now, to be honest, I'm not sure the grappelli-admin-tools fork is a good
idea... I'm sure the changes could be merged upstream, as long as they
do not break things.
What do you (grappelli) guys think about working on a clean patch
against the current code ?
Regards,
--
David
patrickk
generally speaking, I do agree with not having a grappelli-fork.
that being said, the main reason for our fork are the templates –
grappelli-templates are slightly different compared with the original
admin-interface (and admin-tools as well).
so I´m not sure how to solve this. any ideas?
the only solution I can currently think of is adding the admin-tools
templates to grappelli (the styles are already there). but then we
need a way to define a custom templates-folder for admin-tools.
regards,
patrick
>
> Regards,
>
> --
> David
>
> > greets,
> > klemens
>
>
> >> Hmm, yeah some dashboard modules (AppList comes to my mind...) assume
> >> that the admin site is the default admin site
> >> (django.contrib.admin.site), hence, they don't support custom
> >> AdminSite instances...
> >> Maybe a solution would be to add a "site" property to dashboards ?
> >> (hey, I'm on holidays :) patches welcome !)
>
> >> Regards,
>
> >> --
> >> David
>
> >>> Hmm, I hadn't thought of it failing like that :)
>
> >>> I'll have to get back to you on that (after more thinking).
>
> >>> Alex
>
>
> >>>> hi alex,
>
> >>>> thanks for your help.
>
> >>>> site. that�s all.
> >>>>>> approach.
>
> >>>>>> problem is that I need to access different admin-sites. currently, I�m
> >>>>>> within dashboard.py (for example).
> >>>>>> tools)? I mean, that�s a very basic admin-interface functionality,
>
> >>>>>> proposal:
> >>>>>> IMO, it should be possible to define different dashboards
>
> >>>>>>>> thanks a lot,
> >>>>>>>> patrick
>
> >>>>>>>> On 22 Jun., 21:13, David Jean Louis<izimo...@gmail.com> wrote:
>
> >>>>>>>>> Hi,
>
> >>>>>>>>> You could also implement a callable, i.e. "custom_dashboard_factory()",
> >>>>>>>>> that would return the Dashboard class conditionally, given the current site.
> >>>>>>>>> Then you just have to set the ADMIN_TOOLS_INDEX_DASHBOARD to your
> >>>>>>>>> factory function.
>
> >>>>>>>>> --
> >>>>>>>>> David
>
> >>>>>>>>> Le 22/06/2010 15:49, Alex Robbins a crit :
>
> >>>>>>>>>> I think you could implement that functionality using the
> >>>>>>>>>> init_with_context function[1] in the dashboard class. You would add
> >>>>>>>>>> different things depending on the request url. If there were small
> >>>>>>>>>> differences, that would be a pretty clean way to do it. If they are
> >>>>>>>>>> two completely different admins, that might get a little ugly.
>
> >>>>>>>>>> Alex
>
> >>>>>>>>>> [1]http://packages.python.org/django-admin-tools/dev/dashboard.html#admi...
>
>
> read more »
David Jean Louis
> grappelli-templates are slightly different compared with the original
> admin-interface (and admin-tools as well).
>
>
> the only solution I can currently think of is adding the admin-tools
> templates to grappelli (the styles are already there). but then we
> need a way to define a custom templates-folder for admin-tools.
>
> regards,
> patrick
>
Hi Patrick,
Maybe you could just override / extend the admin-tools templates simply
by creating a admin_tools directory in the grappelli/templates/
directory, and if a patch for the python part of admin_tools is still
needed, we could apply it upstream. It's better to have to maintain some
templates than a complete fork.
The only requirement I can think of is that "admin_tools" will have to
be placed before "grappelli" in the INSTALLED_APPS.
Regards,
--
David
>> read more �
>>
>
Mikhail Korobov
I'm glad to hear there is some discussion about merging grappelli-
fork. Hope we will find a good decision.
There are django admin template overrides in django-admin-tools (4
templates: index, app_index, base_site and base) and admin-tools-
specific templates (the rest).
In my opinion overriding admin-tools-specific templates should
definitely be possible from third-party apps. This is my proposal:
1. Move all existing admin-tools templates into 'default' subfolders (/
menu/templates/admin_tools/ will become /menu/templates/admin_tools/
default/ and /dashboard/templates/admin_tools/ will become /dashboard/
templates/admin_tools/default/ ).
2. Change all the template renderers to try /menu/templates/
admin_tools/ first and /menu/templates/admin_tools/default/ second
(django template rendering methods support iterables instead of single
template name).
3. Put necessary grappelli-admin-tools templates into grappelli-admin-
tools' /menu/templates/admin_tools/ and /dashboard/templates/
admin_tools/ (inheriting from default/ when it make sense)
4. Change the install instruction of grappelli-admin-tools to make it
clear it now depends on django-admin-tools.
As for default admin templates, grappelli overrides them now anyway so
it should continue override them as usual.
If some extra blocks should be added to django-admin-tools templates
in order to easy grappelli life then they certainly should be added.
>
> продолжение »
Mikhail Korobov
admin-tools templates.
>
> продолжение »
patrickk
override/extend the templates just by using an admin-tools folder,
right?
@mikhail: this approach looks good to me. it´s backwards-compatible
and allows for easy overriding of admin-tools templates.
@david again: what do you think about mikhails proposal?
regards,
patrick
>
> read more »
patrickk
"default"-folder allows for overriding admin-tools templates by apps
which are not necessarily _before_ admin-tools within INSTALLED_APPS.
that´s the main reason for using a default-folder. or do I miss
something here?
regards,
patrick
>
> read more »
David Jean Louis
> @david: if admin-tools has to be installed before grappelli, we cannot
> override/extend the templates just by using an admin-tools folder,
> right?
>
Sorry Patrick, of course I meant *after*... ;)
But as Mikhail noted there will be some trouble with the django admin
templates, because both admin-tools and grappelli override them...
Hence, Mikhail's proposal seems to be the way to go.
I'll try to install grappelli + admin-tools on a virtualenv and see how
it goes.
Regards,
--
David
Mikhail Korobov
a full set if templates in grappelli and put grappelli before
admin_tools in INSTALLED_APPS. Am I missing something? I thought that
overriding standard django admin templates that was overrided by
admin_tools can be done the same way.
I can imagine some hacks that will enable independent overriding of
django admin templates with inheritance support. E.g.: admin/
base_site.html may inherit from variable template (this is supported
by django) and the name of template is populated via context
processor. admin_tools context processor will forward admin/
base_site.html template to admin_tools/base_site.html and grappelli
can forward it to grappelli/base_site.html (grappelli/base_site.html
may extends admin_tools/base_site.html in this case).
There is also a `AdminSite.index_template` param, don't know if it is
relevant.
The `default` folder approach is not absolutely backwards-compatible:
custom module templates that inherits from existing admin_tools
templates will be broken. I don't think there are a lot of third-party
modules in the wild but I may be wrong. Maybe we should take opposite
route: leave existing templates as-is but try to load e.g. from /menu/
templates/admin_tools/overrides/ first. This is less fancy but it is
backwards-compatible.
>
> продолжение »
Mikhail Korobov
question. You're right, `default` folder make it possible to override
templates which are not necessarily before admin-tools. But I think it
is not the main benefit and the main benefit is that with `default`
folder overriding templates can extend default templates.
>
> продолжение »
David Jean Louis
Ok, I like the last option Mikhail proposed, that is:
- leave admin_tools templates in the directory they are located now,
- change the renderers to first look for a
admin_tools/{dashboard,menu}/overrides/<template_name>.html, if it
exists, use it, if not use
admin_tools/{dashboard,menu}/<template_name>.html.
For grappelli admin tools that would mean to just create a
admin_tools/{dashboard,menu}/overrides/, and put the templates there.
Once we've done this, we'll sort out the things that possibly need to be
modified upstream in the python code, to achieve complete integration.
What do you all thing about the idea ? Am I missing some drawbacks of
this solution ?
Regards,
--
David
Klemens Mantzos
> Hi all,
>
> Ok, I like the last option Mikhail proposed, that is:
> - leave admin_tools templates in the directory they are located now,
> - change the renderers to first look for a
> admin_tools/{dashboard,menu}/overrides/<template_name>.html, if it exists,
> use it, if not use admin_tools/{dashboard,menu}/<template_name>.html.
>
> For grappelli admin tools that would mean to just create a
> admin_tools/{dashboard,menu}/overrides/, and put the templates there.
> Once we've done this, we'll sort out the things that possibly need to be
> modified upstream in the python code, to achieve complete integration.
>
> What do you all thing about the idea ? Am I missing some drawbacks of this
> solution ?
GREAT.
except of the multiple AdminSite() support python code is the same.
> --
> You received this message because you are subscribed to the Google Groups
> "django-admin-tools" group.
> To post to this group, send email to django-ad...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-admin-to...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-admin-tools?hl=en.
>
>
--
klemens mantzos
http://fetzig.at/
David Jean Louis
> On Sat, Sep 18, 2010 at 12:20, David Jean Louis<izim...@gmail.com> wrote:
>
>> Hi all,
>>
>> Ok, I like the last option Mikhail proposed, that is:
>> - leave admin_tools templates in the directory they are located now,
>> - change the renderers to first look for a
>> admin_tools/{dashboard,menu}/overrides/<template_name>.html, if it exists,
>> use it, if not use admin_tools/{dashboard,menu}/<template_name>.html.
>>
>> For grappelli admin tools that would mean to just create a
>> admin_tools/{dashboard,menu}/overrides/, and put the templates there.
>> Once we've done this, we'll sort out the things that possibly need to be
>> modified upstream in the python code, to achieve complete integration.
>>
>> What do you all thing about the idea ? Am I missing some drawbacks of this
>> solution ?
>>
> GREAT.
>
> except of the multiple AdminSite() support python code is the same.
>
Hi Klemens,
your solution for this (multiple admin sites) looks great and backwards
compatible, I see no reason to not merge it upstream.
I'm super busy with work at the moment unfortunately :( so I won't have
time to do the changes before two weeks or so...
If anyone want to work on a fork of the current code and integrate those
changes (it will be excellent if doc/tests were updated also !) it will
be very appreciated.
Klemens Mantzos
> Hi Klemens,
>
> your solution for this (multiple admin sites) looks great and backwards
> compatible, I see no reason to not merge it upstream.
>
> I'm super busy with work at the moment unfortunately :( so I won't have time
> to do the changes before two weeks or so...
> If anyone want to work on a fork of the current code and integrate those
> changes (it will be excellent if doc/tests were updated also !) it will be
> very appreciated.
maybe i'll do it sooner. will talk with patrick about that. let you know.
greetings,
Klemens Mantzos
not only the templates/admin_tools templates are custom in
grappelli-admin-tools.
templates/admin/... too.
(to just load grappelli first in INSTALLED_APPS wouldn't do. we have
i.e. admin/base.html for grappelli and a different admin/base.html for
grappelli+admin_tools.)
any suggestions how to fix that?
regards,
klemens
> --
> You received this message because you are subscribed to the Google Groups
> "django-admin-tools" group.
> To post to this group, send email to django-ad...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-admin-to...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-admin-tools?hl=en.
>
>
--
klemens mantzos
http://fetzig.at/
Klemens Mantzos
INSTALLED_APPS = (
...
'grappelli',
'admin_tools.theming',
'admin_tools.menu',
'admin_tools.dashboard',
'django.contrib.admin',
...
)
all admin_tools/{dashboard,menu}/overrides/ templates are in grappelli.
grappelli has additionally an admin/for_admin_tools/ directory (or
however you wanna name it).
i.e. grappelli has an admin/base_site.html. this template checks via
template_tag if admin_tools is in the INSTALLED_APPS. if true it
extends from admin/for_admin_tools/. if not it renderes the "grappelli
without admin-tools" version of the template.
any suggestions?
regards,
klemens
Mikhail Korobov
good.
I've described another (very similar) approach earlier in this thread:
base_site.html may inherit from variable template (this is supported
processor. admin_tools context processor will forward admin/
base_site.html template to admin_tools/base_site.html and grappelli
can forward it to grappelli/base_site.html (grappelli/base_site.html
may extends admin_tools/base_site.html in this case).
admin-tools as well as before. But this will make grappelli dependent
hard on django-admin-tools.
>
> продолжение »