Currently I am developing a module for our own issue tracker. Of course our issue tracker is build in Drupal; so it is a Drupal module. The development started, after I tried the Dashboard module in core, and some contrib modules. I will leave those unnamed. Not that there is something wrong with the modules, they all have their audience, but I want to take it a step further.

First I must admit: I am a big fan of Panels. I know, I know... something must be wrong with me; It is slow, it is for site builders, not for real programmers, and all kinds of other arguments... I say: blah, blah, blah. I am not here to argue about Blocks vs Panes or Display Suite and Context. Been there, done that (And believe me, we do a lot of Drupal module development)... I just prefer Panels and Panelizer for most use cases; period.

With that out of the way, I can come to the point; Why develop a new module, when there are already good Dashboard modules? The reason is simple. It is not 'only' a dashboard module, users can change the way they see a page. They don't have to be owner of the content, they just drag-n-drop the order in the display and show or hide stuff to their liking. Another user can drag-n-drop the order of the same content to his or her liking. So... how to use it, and what is so cool?

How I came to development of this module.

First forget Panelizer for a moment. We start with Panels and the Page manager of ctools. It is standard behaviour of Panels that you can override a node view page, so that you can use Panels to construct the node page.Suppose there is a node type called 'issue'. That node type holds all issues (dûh). The node type has a lot of fields like detailed description, assignee, project, status, attachments and more... We need all those fields.. they have a purpose, but it also gives us a display nightmare. Different users find different stuff important. Account management only cares about the hours and how fast things are picked up, project leads want a decent way to estimate and relate stuff and the developer need to access all the fine details, including the attachments.So what I did was overriding the default node view with a Panel and started playing around. Assignee at the top, description lower.. etc, etc. It took me a while to figure out a way to display everything and to have a display that I liked. First my buddy from account management showed up in my office... "Listen, I realy like your hard work (typically a sales guy), but I want to see also all previous issues for this project, or maybe even every issue from the same client, and can client name go on top, together with the reporter?". Luckely I did build it all with Panels, so 15 minutes and some Views magic later, I did my job... Happy sales guy!Next in line was the Project lead. "Can't we show related issues? Issues might have something in common because of a particular modules or so.." No, is not an answer for a devoted developer, so again some views, search api thingies... and woot! I did have a cool pane with related stuff. Then a developer showed up. "What is all this stuff on my issue pages? It is way to crowded... Just give me clear instructions, don't bother me!" Woops... developers... they have their own way of saying things.. All I understood that something was completely wrong.

How to fix this with a custom module?

It was clear that there never could be an agreement on what field on top, what is important and what not to display on that page. So I developed a module called Panels User Override. The administrator provides a 'sane' layout of the page. He even provides some extra stuff that is not in the normal display. A user then can drag-n-drop the way he/she sees the page. So every user can have the issues his or her way, without me doing anything... fantastic! This module also opend the way for a new frontpage of our issue tracker. It will be (in the near feature) a Panel page, with way more possibilities then our friend 'Dashboard', that only works with 'Blocks'.

What this module is not.

It is not Panelizer. It cannot be compared to Panelizer. I see no reason why it cannot work together with Panelizer from a technical perspective, but I cannot come up with a use case. I think you will create a nightmare for your users. You then can override displays that are already overriden per node... See a whole thread on this topic in the issue tracker of this module.I already did make the module available it in my sandbox on drupal.org, but it is not ready to promote it to a full project. It might never see the full project status. One of the main problems is the way it does access checks now... it simply doesn't do any access checks. So you can also override Panels, that you have no access to, and drag-n-drop panes that are not available for you. Not a real problem... it does no harm that you can change the order on things you will never see, but it is weird for the user. I do have some ideas how to fix that.Problem is that I don't have a context on edit. Possible ways to solve this are:

1. The edit/override can only be started from a context (e.g. edit THIS layout). Thing is that this doesn't make it clear that you also edit the same display for all other contexts (nodes).
2. Leave all intact as it is now and load a default context on edit. But I simply cannot figure out a way... how to do this? I see that the developers of Panels have the same issue with this, because the preview is also loaded without a default context....

Well.. test it, review it, patch it and come with better ideas! But don't depend on it. It might change, dissapear or never be touched again, without notice. So use this custom developed module at your own risk!