Roundup Tracker

Differences between revisions 10 and 11
Revision 10 as of 2013-03-11 01:47:22
Size: 3799
Comment:
Revision 11 as of 2013-03-27 14:13:35
Size: 3960
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * Improve REST/json/ajax support. (for REST see: RoundupIssue:2550734)  * Improve REST/json/ajax support. (for REST see: RoundupIssue:2550734) See also RoundupRemote Library (the wikiword is banned from this wiki, so split into two words) however the link to the mailing list discussion is inaccessible.

Roundup / Python Tracker enhancements

  • Merge Roundup branch / fork from http://hg.python.org/tracker/roundup/ back into mainline.

  • Encapsulate tracker-specific improvements into Roundup extension modules.
  • Improve Rietveld integration.
  • Add stand-alone patch review support to Roundup.
  • Improve REST/json/ajax support. (for REST see: 2550734) See also RoundupRemote Library (the wikiword is banned from this wiki, so split into two words) however the link to the mailing list discussion is inaccessible.

  • Modularize features from tracker templates to improve customizability.
  • Create a new version of the batch editor: (see: ProjectManagerBatchEditing and BatchSearchAndEditing)

    • That allows you to search to generate the list of issues to update, but also provides a checkbox for each issue allowing the user to include/exclude each issue as needed.
  • Provide a mechanism to allow reverse links (i.e. links to the
  • Modify permissions to make a permission that specifies a matching
    • property take precedence over a permission that doesn't specify

      a matching property See email discussion.

  • Rewrite journaling to:
    • Stop it from missing updates to the database (see discussion at roundup tracker 2550731).

    • Filter properties when user does not have
      • permission to see them.
    • Enhance API to search for:
      • changes to a particular property (or properties)
      • changes in a particular time range
  • Make Roles into real objects and not just text strings.
    • This will have a number of advantages including:
      • Editing roles in the user item will not have typos
      • User classhelp can query database for roles so you
        • can add a new role and have it show up in the classhelp automatically
  • Develop code to link a roundup issue in one tracker with an
    • issue in another tracker. Use case: We have two roundup trackers, one external and customer accessible and a second internal only. We would like to link an issue in the external tracker to an issue in the internal tracker and permit changes to the internal tracker to modify the external tracker issue. Think of this as extending links and multilinks to issues to a second tracker instance.
  • develop a class/widget that allows:
    • links to multiple object types
    • links to arbitrary uri's Use case: in an issue tracker you may have different classes
      • of assets (hardware, software ...) that are best modeled as different objects with different properties, but you want to link them into a ticket as a generic "asset" rather than having separate hardware, software, firmware, squishware properties on the issue as the relation from the issue to the object is the same (asset) and that is what we want to model rather than modeling the type of asset.
      Similarly allowing arbitrary uri's to be included is sort of an
      • extension to this to allow something similar to rt's mechanism where they really support url's and issues are just a special form of url specified with the issue number.

(In addition some of these ideas are also captured in Roundup's own tracker)