Issue #43 resolved

Issues with dashboard preferences and layout

Mikhail Korobov
created an issue

==== Issue 1: ====

Show all modules in index dashboard

Go to some app's index

Remove a module - "Modules" panel will appear

Go back to index dashboard

There will be "Modules" panel with removed module and one module from index dashboard will become hidden

==== Issue 2 ====

Everytime the dashboard definition changes (i.e. change the number of columns) the dashboard layout is broken, see this thread for more information:

Comments (24)

  1. David Jean Louis repo owner
    • changed status to open

    Hey Mike,

    indeed, that's a nasty bug, at the moment dashboard preferences are "global", we need to add a "dashboard id" column to the DashboardPreferences model.

    -- David

  2. Mikhail Korobov reporter

    I think it is possible that the best solution here is a more robust id generation for html elements. It could solve this problem as well as the problem described here:

    The weak point in my proposal it that I haven't thought about the exact algorithm. But I think the core problem is that there is no direct mapping between exact dashboard module instance and the id of html element and if we find a way to solve it then preferences-related problems should gone.

  3. Anonymous

    Hi, I'm still having issues with this. Is there anyone on it? Or could some one give me more info so I can try to fix it myself? Thanks

  4. David Jean Louis repo owner

    Hi Alex, thanks for your time, it is appreciated.

    If I understand correctly, your patch addresses issue 1 of this bug, adding a discriminator to the dashboard preferences that allows to determine which dashboard we're dealing with given a request path, but issue 2 is still there, right ?

    I'm over busy at work right now, but keeping an eye on it.

    Mikhail, I you have time, would you mind giving a look at this with alex ?

    Once this issue is resolved I think we could release a version 0.4.0 (0.3.0 is getting old...).


    -- David

  5. aleray

    Hi David,

    the issue addressed with this patch is issue 1 (on 2 described in this page). It would be really nice to find a solution for issue 2 before releasing 0.4.0, because this is last bug I'm encountering.

    Please don't hesitate to correct my code, I did it very roughly, and for instance visiting directly the change form page (http://localhost:8000/admin_tools/dashboard/set_preferences/) breaks the code as the request info I've used to detect the pathname is only valid using ajax.

    As for bug #2, it not only happens when I modify the file, but also simply when I change the page layout, by dragging a module to another column for instance.

    I'll try to have a look at this too.



  6. Mikhail Korobov reporter

    Hi Alex and David!

    Please let me think a day or two on this problem. I have some ideas but they may be too magic and they need some thought. It's a shame the bug is unfixed for several months but that's a tough bug ;)

    The side note: I think we should release 0.4.0 without these bugs fixed, there are a lot of other useful changes in trunk.

    But the main reason to make a release is the migrations.

    If we are going to introduce migrations in django-admin-tools then we should release initial migrations as soon as possible. New users will be able to run

    $ ./ migrate

    and old users will be able to upgrade just by running

    $ ./manage migrate --fake

    The process will be complicated if there will be migrations besides the initial migration because some migrations should be faked and some should be ran really.

    So I propose to provide initial migrations for all models and make a 0.4.0 release. And then after some time and fixing this bug, when the dust settle, release the 0.4.1 bug-fixing release. I think that generally releases should be more frequent - there is no reason to keep changes out of pypi.

  7. David Jean Louis repo owner

    Mikhail, Alex, sounds good.

    I'll release 0.4.0 on monday 13/12, with migrations infrastructure addition only, then we'll work on the issue and release a 0.4.1.


    -- David

  8. aleray

    Hi Mikhail,

    the reason I didn't used the get_id method was that I didn't notice it before :-) It makes much more sense indeed with get_id(); I have updated my code according to your suggestion.


    I would really love to see bug #43.2 fixed, and would be happy to help. I have noticed that what introduce bug #43.2 isn't in the first place wrong settings send to set_preferences() but a layout problem. The settings get wrong only when there is already a wrong layout which is then modified.

    Steps to reproduced #43.2 (with a six modules layout on 3 columns, 2 modules per column):

    • exec `truncate admin_tools_dashboard_preferences;` in the db shell to reset the preferences
    • reload your dashboard page
    • move the 1st module from the 1st column to the top of the second column: the post data are:
    data	{"positions":["module_2","module_1","module_3","module_4","module_5","module_6"],"columns":[1,3,2],"disabled":{},"collapsed":{}}
    • reload the page. The layout gets wrong although the preferences in the loadscript function are OK:
        loadScripts(js_files, function(){
            jQuery(function($) {

    Any idea on what is going on?



  9. Mikhail Korobov reporter

    Hi Alex,

    That's great!

    I think you hit the right solution and I was going to the wrong direction.

    The id generation code ( though can still be useful: it is backwards-compatible and can fix an another bug: if e.g. modules are reordered or e.g. some modules were deleted in python code then now the preferences will belong to wrong modules. It'll be possible to overcome this with manual id selection using my patch. Some empirical algorithm can be used later to remove or reduce the need for manual id selection then (e.g. generate id by module class).

    Another idea is about the migrations. We already have the denormalized storage here (the 'data' field in DashboardPreferences model). So it is possible not to introduce the scheme migration and instead change the way preferences work (store the existing {} as {'dashboard_1': {}, 'dashboard_2': {}}). This means more work that will lead to easier upgrading. Don't know if it is worth it.

    The initial migrations are a good step anyway.

  10. aleray


    Glad to see my fix included! Mikhail, indeed what you are proposing is a tempting option. I'll try to think about it in the coming days.



  11. Log in to comment