User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:roadmap_requirements

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
mantisbt:roadmap_requirements [2006/11/18 14:13] – Update the requirements to reflect progress. vboctormantisbt:roadmap_requirements [2011/11/16 07:29] (current) – The page rendering was broken (maybe since new PHP version on mantisbt.org). Added new line to fix it at end of file. atrol
Line 21: Line 21:
 ===== Database Changes ===== ===== Database Changes =====
  
-   * **(Done)** Add a target_release field to the issue that is the same type as version and fixed_in_version.  This field can be left empty of not specified.+   * **(Done)** Add a target_version field to the issue that is the same type as version and fixed_in_version.  This field can be left empty of not specified.  It can also be added to the custom field list (see [[customizing_columns_in_view_issues_page]]).
    * Add a optional target_date to the version table.  This allows the project manager to set a deadline for the release.    * Add a optional target_date to the version table.  This allows the project manager to set a deadline for the release.
  
Line 27: Line 27:
  
     * **(Done)** Add "roadmap_view_threshold" which is to be set to the threshold required for a user to be able to view the Roadmap.  The default value should be VIEWER.  If a user can't see the roadmap, then such user shouldn't be able to view, edit or filter by target release.  If set to NOBODY, then the Roadmap / target release changes are all hidden/disabled.     * **(Done)** Add "roadmap_view_threshold" which is to be set to the threshold required for a user to be able to view the Roadmap.  The default value should be VIEWER.  If a user can't see the roadmap, then such user shouldn't be able to view, edit or filter by target release.  If set to NOBODY, then the Roadmap / target release changes are all hidden/disabled.
-    * Add "roadmap_edit_threshold" which is to be set to the threshold required for a user to be able to set/change the value of the target release.  The default value should be DEVELOPER.+    * **(Done)** Add "roadmap_update_threshold" which is to be set to the threshold required for a user to be able to set/change the value of the target release.  The default value should be DEVELOPER.
  
 ===== General Changes ===== ===== General Changes =====
Line 52: Line 52:
    * If an issue has a fixed_in_release and target_release both set and status is fixed, then the roadmap should use the fixed_in_release field.  Hence, if such release is not yet released, then it will appear under this release rather than the original target_release.    * If an issue has a fixed_in_release and target_release both set and status is fixed, then the roadmap should use the fixed_in_release field.  Hence, if such release is not yet released, then it will appear under this release rather than the original target_release.
    * **(Done)** Similar to the Changelog page, this page should support "All Projects" as well as specific project.    * **(Done)** Similar to the Changelog page, this page should support "All Projects" as well as specific project.
-   * Similar to the Changelog page, it should be possible to directly link to this page from a website.  It should be possible to specify the project_id as a get parameter. +   * **(Done)** Similar to the Changelog page, it should be possible to directly link to this page from a website.  It should be possible to specify the project_id as a get parameter. 
-   * Users should only see the issues that are visible to them.  Hence, private issues should not be visible to users who don't have such access.  Anonymous users should only be able to access it if such access is allowed.+   * **(Done)** Users should only see the issues that are visible to them.  Hence, private issues should not be visible to users who don't have such access.  Anonymous users should only be able to access it if such access is allowed.
    * **(Done)** Use custom functions to allow users to override them and determine the formatting to be used in presenting an issue.    * **(Done)** Use custom functions to allow users to override them and determine the formatting to be used in presenting an issue.
    * **(Done)** The default formatting should show the following information for each issue grouped by the target release:    * **(Done)** The default formatting should show the following information for each issue grouped by the target release:
Line 65: Line 65:
      * Target date (if supplied)      * Target date (if supplied)
      * **(Done)** Issues done (i.e. 20 issues resolved out of 30 planned).      * **(Done)** Issues done (i.e. 20 issues resolved out of 30 planned).
-     * Release description (if not empty).+     * **(Done)** Release description (if not empty). 
 + 
 + 
 + 
 + 
 + 
 + 
  
 ===== Feedback ===== ===== Feedback =====
  
 Please add your comments and feedback in this section. Please add your comments and feedback in this section.
 +
 +  * add the progress bar to roadmap_page.php like trac. (seiji)
 +
 +  * Why does there has to be an additional field that becomes obsolete after the bug is resolved (and the value is copied into "fixed in version"? We renamed "fixed in version" to "target version", use it for both purposes and are quite happy with it. (polzin)
 +             * That sounds like a good idea. I will be keeping both values though. It is clutter but I like it how it is. One box is for what SHOULD happen, and the other is for what DOES happen. So for me, at least, it is a way to see if we are meeting our goals. My main problem is with the wiki page itself. It could probably use redoing to some extent (for example, database changes? The method for adding the field to the reporting screen is no longer really applicable...) (SneakyWho_am_i)
 +
 +  * maybe also add a field to set a version as "private/public" to add milestones/planned releases for developers, without showing them publicly yet (rolf)
 +
 +  * adding an optional target_date to the version table seems redundant. Using the current date_order field allows for all the flexibility required to implement version due dates. To implement due dates at the version level use the date_order field as the target date until a version is released. Then display the date next to the version title in the roadmap. If the current date exceeds the date_order field and the version is not released have the roadmap page highlight the projected released date in red or some other color to show the due date has passed. If wanted it would be trivial to add the number of days the version is late by appending a negative number to the end of the due date. (herringm)
  
mantisbt/roadmap_requirements.1163877226.txt.gz · Last modified: 2008/10/29 04:31 (external edit)

Driven by DokuWiki