Add a new project summary module.

[anonymous]

This module should useful information like:

• Number of open tickets
• Tickets targeted for each milestone
• Tickets assigned to the current user (but see rather #4588 for that)
• And more...

... like a project description, attachments, etc.

[daniel]

Ah. bug #1... hehe.. this one will be here a while, or slowly die..

[anonymous]

Personally...

I think actually leaving a COMMENT as to why you made a change to this ticket number!

Going from high priority to low and back makes no sense with out an explanation!!!

[daniel]

This is a pretty vague ticket. Lets close it.

[daniel]

The idea is central for the redesign, but needs to be fleshed out somewhere else.

[anonymous]

Test

[cboos]

I wonder if this could not be done with a set of wiki macros: with the [[TicketQuery()]] and the  WikiInclude macro to be able to include the WikiStart, it should be possible to compose something like a dynamic My Page.

Note: it would be useful to be able to delete all the test comments attached to this ticket...

[anonymous]

123

[anonymous]

I think project summary (WikiStart) should contain "news" or "announce". To enable this, add the new type named "news" or "announce" to ticket by default, and show recent of these summaries by macro.

And I think "recent colosed tickets", "recent added tickets", and these kind of information can be showed using some macro by defaults.

[Tov Are]

Tidsstyring

Jeg savner muligens mulighet til å legge inn tidsestimater på tickets. Det ville vere nyttig, å kunne ha den type informasjon i samme systemet.

[cboos]

According to our roadmap, this should be a 1.0 feature.

[cboos]

Quite unbelievably, this is not a test ticket, but a valid one.

Though the question of whether this should be done as a plugin might be asked...

An alternative to a plugin would be the possibility to have macros that can provide all the required info an be inserted in the WikiStart page.

e.g. the TicketQuery macro could be adapted to accept a count format, in addition to the compact one, and that would simply show the number of tickets matching the specific request.

trac/ticket/query.py

@@ -677 +677 @@
     This macro accepts two parameters, the second of which is optional.
 
     The first parameter is the query itself, and uses the same syntax as for
-    {{{query:}}} wiki links. The second parameter determines how the list of
-    tickets is presented: the default presentation is to list the ticket ID next
-    to the summary, with each ticket on a separate line. If the second parameter
-    is given and set to '''compact''' then the tickets are presented as a
-    comma-separated list of ticket IDs.
+    {{{query:}}} wiki links.
+
+    The second parameter determines how the list of tickets is
+    presented: the default presentation is to list the ticket ID next
+    to the summary, with each ticket on a separate line.
+    If the second parameter is given, it must be one of:
+     - '''compact''' -- the tickets are presented as a comma-separated
+       list of ticket IDs.
+     - '''count''' -- only the count of matching tickets is displayed
     """
 
     def render_macro(self, req, name, content):
         query_string = ''
-        compact = 0
+        compact = False
+        count = False
         argv = content.split(',')
         if len(argv) > 0:
             query_string = argv[0]
             if len(argv) > 1:
-                if argv[1].strip().lower() == 'compact':
-                    compact = 1
+                format = argv[1].strip().lower()
+                if format == 'compact':
+                    compact = True
+                elif format == 'count':
+                    count = True
 
         buf = StringIO()
 
@@ -709 +717 @@
                         (ticket['status'], href, summary, ticket['id'])
                     links.append(a)
                 buf.write(', '.join(links))
+            elif count:
+                buf.write(len(tickets))
             else:
                 buf.write('<dl class="wiki compact">')
                 for ticket in tickets:

[cboos]

btw, the count format is now implemented in 0.11.

[cboos]

I've removed (My Page) from the summary, as this is more related to #4588.

This is about whole project summary, which makes a lot of sense in the multiple project per environment case.

See TracMultipleProjects/SingleEnvironment#Projectresource.

[cboos]

#1877 proposed a patch on 0.8 to give a summary of tickets for all projects (in the multiple environment case).

This makes me think that in order to complement the Project Summary, there should probably be a Projects Overview, in the same vein as we now have a Milestone and the Roadmap for getting an overview of all the milestones.

[lkraav <leho@…>]

cool, first ticket ever.

from the looks of the description, it would seem the current 0.12-trunk capabilities of Roadmap fulfill the original idea.

or what's the latest thought process on this for you cboos?

[cboos]

Milestone 1.0 deleted

[cboos]

Complementary to #130.

The exact form this could take should be very free form, so perhaps rather than the fixed model followed by a milestone (description + ticket progress bar), a project overview could be generated from a set of macros that could be freely modified and repositioned in the project's description. The default layout and content could be taken from ProjectTemplates? sub-pages, with a nice ProjectTemplates?/default.

[Carsten Klein <carsten.klein@…>]

Perhaps this could be made a DashboardPlugin? where the user can edit the page layout and define what is shown and what is not on the DashboardPlugin? admin page.

The dashboard plugin itself should provide extension points, for example DashboardInformationProvider? which can then be implemented by for example the ticket system, for example the LatestTicketChangesInformationProvider?, or the MostActiveTicketsInformationProvider? and so on.

On the admin page then, the user can opt in/out individual such information providers, setting them up in for example a two or three column layout.

On the dashboard page itself, the user might be enabled to drag around individual renderings of the available information providers to their personal likings, collapsing or expanding individual such renderings.

In a multi project scenario, the multi project system would then provide new implementations of these information providers, overriding the defaults in the system provided by the ticket system, the timeline and so on, coalescing the information from these multiple projects into a single view.

[Carsten Klein <carsten.klein@…>]

Replying to anonymous:

I think project summary (WikiStart) should contain "news" or "announce". To enable this, add the new type named "news" or "announce" to ticket by default, and show recent of these summaries by macro.

And I think "recent colosed tickets", "recent added tickets", and these kind of information can be showed using some macro by defaults.

I do not think that the original WikiStart page should be replaced by something like the dashboard.

If you want to include such information on your WikiStart page, your best bet is to implement or use an existing macro and use that on your page.

-10 for replacing the WikiStart by a Dashboard from me.

[Carsten Klein <carsten.klein@…>]

Replying to Carsten Klein <carsten.klein@…>:

Perhaps this could be made a DashboardPlugin? where the user can edit the page layout and define what is shown and what is not on the DashboardPlugin? admin page.

with that I meant that the plugin will provide a requesthandler responsible for the /dashboard realm.