Save/restore/add reports via trac-admin

[pkou at ua.fm]

Implementing a customized workflow system in Trac affects almost every feature (timeline, roadmap, reports, tickets, queries) because ticket statuses can be different. While all features can be abstracted from ticket statuses, reports cannot.

A solution for this problem is to give administrator a possibility to update reports when a workflow is changed.

It requires the following changes:

1. trac-admin shall allow admins to save existing reports in a file;
2. trac-admin shall allow admins to add new reports from a file;
3. trac-admin shall allow admins to replace workflow-specific reports from a file.

While (1) and (2) is understandable, it is necessary to define how to distinguish between a report that should be replaced during workflow change (e.g. system report) and a report that should be kept during workflow change (e.g. user report).

Possible solutions:

1. Classify all reports as system and other. User is not able to change report type. By default, all reports that are created by Trac are marked as system. When user creates a report, it is marked as other. When user edits a system report, Trac shows a warning that the changes will be lost after workflow change.
   • It requires changes in database (new column type for table report).
   • When system reports are replaced, Trac deletes existing system reports first, then creates reports from a file trying to keep recommended report ID that is specified in a file.
2. Reserve first N reports as system (e.g. N=30). When user creates a report, it is created in user area and has id>N.
   • It requires an upgrade script that moves all reports created by user behind N. As result, report references in wiki will be lost.

{{trac-admin}}} commands:

• report save (system|user) <filename> - save system or user reports to a file;
• report add (system|user) <filename> - add system or user reports from a file;
• report replace (system|user) <filename> - replace system or user reports from a file.

Thus, when a workflow needs to be changed for a project, admin should take the following steps:

1. Specify new workflow in configuration;
2. Replace system reports for a project.

Workaround until the feature is not implemented: Update reports by direct database editing using sqlite.

(In preparation to #869)

[pkou at ua.fm]

Thoughts?

[mgood]

Many users will customize or remove the included reports, so I don't think that we can make a distinction between "system" and "user" reports.

I also think that users should be able to just make the workflow switch and then edit the reports through the web interface. The table schemas won't be any different for different workflows, so the reports should all still run. I understand that they will probably need some changes to capture the information about the new statuses, but this would have no effect on the other portions of the site.

[pkou at ua.fm]

I am trying to find a way that simplifies workflow change for existing projects. Imagine a site where 10 Trac projects are hosted. Changing a workflow could be a nightmare for administrator because for now there is no possibility to change reports as a bulk.

I don't like the idea with system/user reports very much but is there any other choice?

If we forget about system/user reports, then Trac should need to support at least bulk reports save/add/replace (or it is better to say export/merge/import).

When workflow is changed for a project, administrator will need to do the following:

• Export existing reports;
• Modify them (possibly merge with some predefined reports for new workflow);
• Import them back.

Any comments?

[mgood]

I don't think that system/user reports really is a choice because we don't want to prevent users from customizing the built-in reports and it doesn't address the fact that "user" reports could be modified for the new workflow as well.

I'm not sure how much time should be invested in this since I think that with 0.9 forward the trend is to favor the Query module? over the reports. There have been major improvements in the interface and flexibility, and since "query:" TracLinks have been added you can link to queries from the Wiki.

So, an alternative is to use the Query module:

• build your replacements for the reports
• create a Wiki page linking to the queries
• use "trac-admin wiki export/import" to import the queries into the other projects

[pkou at ua.fm]

You have convinced me that system/user reports are not appropriate for Trac.

However, I think that export/import/merge functions for reports are very useful and helpful for project maintenance (change workflow, create a project as a template of another project, update reports in several projects).

TracQuery has been significantly enhanced in 0.9 and it looks very good. I agree that for simple reports TracQuery can be a great replacement. However, the feature itself is not a replacement for TracReports: Nothing can replace raw SQL.

I consider this feature as useful for now.

[cboos]

Instead of a more or less complex export/import at the trac-admin level, perhaps we could think about doing something about that in the context of multiple project support: how a given report could be duplicated (or shared?).

The idea being that once you have written an advanced report that could benefit to all projects, it should be easy to "ditribute" it easily so that it can be used in other projects.