Custom dashboards with saved queries

[GoogleCodeExporter]

As a user I would like to see within one screen the current state of all the 
projects I'm interested in. Since I'm watching those projects which are 
interesting to me I can use the 'My -> Watched Changes' screen [1] to get an 
overview of all the open changes that are relevant to me and that I potentially 
want to review. However I also want to know which changes of my watched 
projects have been merged / abandoned. Currently I can't find this information 
in a single screen (of course it is possible to query for 'is:watched 
status:merged' and 'is:watched status:abandoned' but I don't want to type this 
query string each time). This is why I'm proposing to extend the 'My -> Watched 
Changes' screen so that it also shows closed changes. I imagine the 'My -> 
Watched Changes' screen to contain sections similar to the 'My -> Changes' 
screen (AccountDashboardScreen), one section for open changes, one section for 
merged changes and one section for abandoned changes. Of course the table in 
each section must be pageable.

What do you think?

My main use case for this screen would be to check the current state of my 
projects in the morning when I come into office to get a quick overview of what 
happened while I was gone. 

[1] http://code.google.com/p/gerrit/issues/detail?id=605

Original issue reported on code.google.com by edwin.ke...@gmail.com on 29 Jul 2010 at 6:56

• Blocking: #739, #739

[GoogleCodeExporter]

I don't disagree with the idea.

But if we're going to build this, lets spend an extra few hours and
do something that is even more flexible for the end-user so we
don't have to predict everything they want/need up front.

The screen that shows the dashboard is already able to show any
number of sections.  However none of them are paginated.  If we
enable optional pagination for these sections and drive each one
with its own query, we can do what you want by creating three
sections, one for each status.

Create a database object Dashboard that has a unique sequence
primary key and children DashboardSection.  Each child object
has a title and a query string associated with it.  Dashboards can
optionally be owned by a user, or be owned by nobody in which
case they are site-wide.

Create a URL that loads the Dashboard and reuses that UI code
to display the sections with pagination.  Dashboards can just be
loaded into the UI early during sign-in and put into the user's
My menu, as they are fairly lightweight.

Then we just need a small UI addition to the Settings area
that lets users define their Dashboards.  This should be a
simple UI since the section objects are pretty trivial, just a
title and a query.

Once that is all working we should be able to redefine
the current Mine view as a site-wide dashboard for the
current user and use queries for the 3 views.  Which means
users would be able to customize their own dashboard views.

This also resolves another bug that was opened recently where
a user wants to bookmark query URLs inside of the server and
not their browser.  For that they can just create a new Dashboard
with a single section that has the query.  :-)

Sound reasonable?

Original comment by sop@google.com on 29 Jul 2010 at 5:22

• Changed state: Accepted

[GoogleCodeExporter]

Yes, I completely agree.

When I was writing the above feature request I actually also had the thought 
that some generic way of defining queries and including them into various 
dashboard screens would be great but for that moment I was not following this 
thought.

I definitely think it makes sense to spend this effort and go for this generic 
solution that you proposed. I'm sure users will love this feature. :-)

Original comment by edwin.ke...@gmail.com on 30 Jul 2010 at 5:53

[GoogleCodeExporter]

We would like to take care about this feature, but due to planned vacations we 
could start the implementation of it only in first half of September. 

Would this be ok? 
Of course we don't want to stop anyone who wants to go ahead already now.

Original comment by edwin.ke...@gmail.com on 30 Jul 2010 at 9:29

[GoogleCodeExporter]

Sure, starting this in September is fine.  Changes come into Gerrit
only as people have time to work on it around their other duties
and personal lives.  :-)

For now I'll tag you as the owner of this.

Original comment by sop@google.com on 30 Jul 2010 at 2:18

[GoogleCodeExporter]

Issue 636 has been merged into this issue.

Original comment by sop@google.com on 4 Aug 2010 at 11:02

[GoogleCodeExporter]

Looking at our latest internal plannings and priorities I have to say that the 
implementation of this feature is postponed. We are still interested in doing 
the implementation but at the moment we can't estimate when it can be done. I 
will update this issue as soon as we have some concrete planning for the 
implementation.
If somebody wants to take over, please let us know!

Original comment by edwin.ke...@gmail.com on 21 Sep 2010 at 11:24

[GoogleCodeExporter]

I think Martin started looking into this last week actually.

Original comment by nas...@chromium.org on 21 Sep 2010 at 2:11

[GoogleCodeExporter]

I have some additional thoughts on the UI for this. Instead of a Settings UI to 
create/edit the queries, I was imagining an inline UI directly on a dashboard.  
A dashboard would start out blank and would always have an "ADD Query" button 
at the bottom of the dashboard.  Pressing this would add the first (blank) 
query to the dashboard in "edit" mode.

Edit mode for a query would display a inline query editor UI which takes the 
place of the query being edited directly in the dashboard.  The edit UI would 
have at least a title field, a query field, a save and a delete button.  It 
might also have a row limit field.  

Saving the query would return the query to display mode.  Returning to display 
mode would remove the edit UI and replace it with the new query results and a 
query header. The query header would include at least the title, possibly the 
query parameters in italics and an edit button.  Additionally, I envision some 
up/down arrows on each query header which would move the query up or down on 
the dashboard with respect to other queries.  Perhaps there would even be a 
minimize query button for each section.  Clicking the edit button would return 
it to edit mode by removing the query header and results and replacing them 
inline again with the query editor.  Any other queries would remain visible 
above and below the edit UI.

The main advantage to editing queries inline, is that users could then edit and 
tweak their dashboards directly instead of having to go to the settings page, 
make a change, go back to the dashboard to see the effect, and if not right, 
return to the settings page, repeat.  I think that this would be a bit more 
pleasant.  It also alleviates the need to figure out which settings page goes 
with which dashboard allowing us to be a bit more flexible in how many 
different dashboards that we create and how we organize them.

Original comment by mf...@codeaurora.org on 21 Sep 2010 at 9:58

[GoogleCodeExporter]

As for the user/site wide distinction, I have a feeling that it will not be 
flexible enough long term.  I have the feeling that many people have custom 
dashboards for their projects that currently use the event streams of the 
various ssh commands to display custom dashboards that Gerrit cannot currently 
do (we do).  With the addition of dashboards, I suspect that much of this 
custom code could eventually disappear (hopefully) and we might find that 
dashboard use grows rapidly.  That being said, I want to at least get our data 
structure close to right so that we can hopefully deal with many of the future 
needs.

Some of my envisioned needs: personal dashboards, project dashboards, group 
dashboards, site-wide dashboards.  This brings up ideas of more than just 
"nobody" as owners.  It also begs the question of how to link these dashboards 
into the various menu hierarchies and who is allowed to edit them.

I also cannot help but think about being able to share queries between 
dashboards.  Perhaps there is a complex query that represents a custom status 
of a project, a query with criteria that might change as a project evolves 
(perhaps because new custom labels are added...).  Several people might want 
that query on their dashboard and they also might want to delegate the 
maintenance logic of how to determine this special status to the original query 
writer.  It could be nice to allow them to see a list of all of queries visible 
to them and to simply add, or link, this specific query to their dashboard, or 
any other dashboard that they can edit.  This would allow them to share in any 
updates to the query without having to recopy the query every time the criteria 
changes (and be aware that it changed).  But, I admit, this may be getting 
ahead of things. :)

However, if we decide that the above idea is valuable, we are likely to find 
that it would be valuable to have the ability to define additional query 
criteria to apply on top of a "linked" query.  Perhaps a user is interested in 
the changes outlined by the linked query, but they want to limit the results to 
the ones they own themselves.

And, finally, a much bigger step would perhaps consider the idea of linking not 
just queries, but entire dashboards also.  I picture a common set of queries 
with very custom criteria which describe a project's status.  If several 
projects share the same status criteria, they may all wish to take advantage of 
a base dashboard which they could link to.  However, to make this effective, 
like with linked queries, it would likely have to be possible to define 
additional criteria to apply on top of linked dashboards.  In this case: to 
specify the project name in order to limit the dashboard to changes from the 
project it represents.  Despite my overzealous suggestions :) this particular 
one might help with Issue 303:   List all projects and jump to 
open/merged/abandoned change lists.

Now, I need to just keep things simple with a flexible migration path...

Original comment by mf...@codeaurora.org on 22 Sep 2010 at 12:31

[GoogleCodeExporter]

Hi Martin,

this reflects pretty well what we have discussed about this topic so far.

I like the idea of having an inline edit UI for queries in the dashboard. 
As you described it this would be a really convenient way for building up 
dashboards and change them as needed. Regarding the positioning of the queries
in the dashboard having up/down arrows on each query header is a good idea,
but maybe we can also allow the user to simply change the query position by
dragging and dropping the query header to a different place? Not sure if gwt
supports dra&drop.

In the long run I also see the need that saved queries might be reused in 
different dashboards and might also be shared with other users. As you already 
pointed out this would result in several requirements:
1. Saved queries need an owner who maintains the query. It must be clear who
is allowed to edit a saved query. Users of the query must be informed about 
changes of the query. 
2. It should be possible to define the visibility of a query. I see here the 
same scopes as you have mentioned for the dashboards (personal, project, group, 
site-wide).
3. We need a screen that lists all queries and allows to edit/delete them.
4. It must be possible to assemble a dashboard from saved queries and to 
include saved queries into existing dashboards. Maybe we can have a screen 
that shows a dashboard on the left side and on the right side a list with 
all available queries that then allows the user to drag&drop the queries into
the dashboard?
5. It must be possible to adapt a saved query to custom needs, e.g to limit a 
saved query to a certain project (this is what you called 'additional query
criteria on top of a linked query').

I also agree that the same is true for entire dashboards.

So as you said the main question is how to start simple and be flexible for
extensions.
I would propose to start with the following:
1. Allow users to save queries:
When a user typed in a query and executed it, there could be a 
'Save this query' button on the screen which allows the user to save the
current query. After clicking on this button a popup can appear which asks 
e.g. for a query title.
2. Allow users to reexecute saved queries:
Have a screen that simply lists all saved queries. For the beginning it would
be sufficient that a query is only visible to the query author. By clicking
on the query the query is executed.
3. Allow users to delete saved queries:
Have a 'Delete' button for each query shown in the query screen.

What do you think?

Another point which some people brought up here is that there should be an
UI that supports the creation of queries. I personally consider it just as 
nice-to-have since I find the query language very intuitive and easy to use 
but some users would prefer a UI-driven way of defining a query, e.g. to have 
checkboxes for the change states ('open', 'merged' etc.) and input fields 
for limiting the search by projects, groups, etc. 

Original comment by edwin.ke...@gmail.com on 23 Sep 2010 at 11:13

[GoogleCodeExporter]

This patch series is an attempt to start by creating a "Saved Search" mechanism:

https://review.source.android.com/#change,21774

I am building upon this to create a "Saved Dashboard" mechanism.

Original comment by mf...@codeaurora.org on 14 Mar 2011 at 11:29

• Changed state: Started

[GoogleCodeExporter]

Issue 1038 has been merged into this issue.

Original comment by edwin.ke...@gmail.com on 5 Jul 2011 at 11:10

[GoogleCodeExporter]

Issue 1186 has been merged into this issue.

Original comment by edwin.ke...@gmail.com on 15 Nov 2011 at 7:23