Issue tracking for this project has moved to the BitBucket issue tracker.
Project URL is: http://bitbucket.org/jdbernard/personal-issue-tracker/
This commit is contained in:
parent
33281f2a10
commit
f2f470ff2a
@ -1,4 +0,0 @@
|
||||
Show full issue text with -v, --verbose
|
||||
=======================================
|
||||
|
||||
Print the full issue when passed the verbose option.
|
@ -1,6 +0,0 @@
|
||||
Add the ability to change an issue's category
|
||||
=============================================
|
||||
|
||||
The -l/--list options lists issues, add a set of options to reclassify
|
||||
an issue from one category to another. The most common is CLOSED, but
|
||||
other categories should also be supported.
|
@ -1,2 +0,0 @@
|
||||
Add the ability to re-prioritize an issue.
|
||||
==========================================
|
@ -1,4 +0,0 @@
|
||||
Add the ability to enter new issues
|
||||
===================================
|
||||
|
||||
Implemented on 2010/02/17
|
@ -1,4 +0,0 @@
|
||||
Add unit tests for LIST operation
|
||||
=================================
|
||||
|
||||
Add unit tests for listing issues with no filter.
|
@ -1,4 +0,0 @@
|
||||
Add unit tests for the PRIORITY filter
|
||||
======================================
|
||||
|
||||
Add unit tests covering the priority selection criteria of the filter.
|
@ -1,4 +0,0 @@
|
||||
Add unit tests for the CATEGORIES filter
|
||||
========================================
|
||||
|
||||
Add unit tests covering the categories filter criteria.
|
@ -1,4 +0,0 @@
|
||||
Add unit tests for the PROJECTS filter
|
||||
======================================
|
||||
|
||||
Add unit tests covering the projects filter criteria.
|
@ -1,4 +0,0 @@
|
||||
Add unit tests for the RECURSE filter
|
||||
=====================================
|
||||
|
||||
Add unit tests covering the subprojects filter criteria.
|
@ -1,4 +0,0 @@
|
||||
Add unit tests for the VERBOSE option
|
||||
=====================================
|
||||
|
||||
Add unit tests covering the verbose option
|
@ -1,5 +0,0 @@
|
||||
Add Apache Ivy to the build process.
|
||||
====================================
|
||||
|
||||
Add the neccesary structure to leverage an existing Ivy repository and to
|
||||
generate artifacts for a local repository.
|
@ -1,4 +0,0 @@
|
||||
Add unit tests for changing an issue's category.
|
||||
================================================
|
||||
|
||||
Test defined in test/com/jdbernard/pit/IssueTest.groovy
|
@ -1,5 +0,0 @@
|
||||
Add unit tests for changing an issue's priority.
|
||||
================================================
|
||||
|
||||
|
||||
Test defined in test/com/jdbernard/pit/IssueTest.groovy
|
@ -1,4 +0,0 @@
|
||||
Add unit tests covering Issue construction.
|
||||
===========================================
|
||||
|
||||
Test defined in test/com/jdbernard/pit/IssueTest.groovy
|
@ -1,2 +0,0 @@
|
||||
Add unit tests covering Project construction.
|
||||
=============================================
|
@ -1,8 +0,0 @@
|
||||
New Issue ID is off by one.
|
||||
===========================
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
When creating a new issue with the --new-issue option, the created issue has
|
||||
the same id as the most recent issue, as opposed to one more than.
|
@ -1,26 +0,0 @@
|
||||
Creating a new issue bases the next id only on the filtered issues.
|
||||
===================================================================
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
This represents a more systematic error. Filtering should be applied when
|
||||
viewing the data only, not when loading the data. It is possible that
|
||||
operations may need the full data to modify parts of it.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
Remove filtering fromt he project and issue construction. Double check that
|
||||
filtering is correctly applied during all the access methods (eachIssue,
|
||||
eachProject, each)
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Updated ProjectTest.testConstruction() to reflect changes.
|
||||
|
||||
Added a test to ProjectTest.testCreateNewIssue() that needs to count a closed
|
||||
task to correctly generate a new id.
|
||||
|
||||
TODO: Need to create filter tests.
|
@ -1,12 +0,0 @@
|
||||
FileProject.delete() does not handle sub-projects correctly.
|
||||
============================================================
|
||||
|
||||
FileProject.delete() deletes the project directory if the directory is empty,
|
||||
but fails to do so if the directory is not empty.
|
||||
|
||||
Initial Recommendation
|
||||
----------------------
|
||||
|
||||
Loop through the issues and delete the files, loop through the projects and
|
||||
call Project.delete(). Alternatively, use File.deleteDir() rather than
|
||||
File.delete()
|
@ -1,2 +0,0 @@
|
||||
Add unit tests for FileIssue.delete()
|
||||
=====================================
|
@ -1,2 +0,0 @@
|
||||
Add unit tests for FileProject.delete()
|
||||
=======================================
|
@ -1,2 +0,0 @@
|
||||
Fix Issue.toString() so that only the first letter is capitalized.
|
||||
==================================================================
|
@ -1,33 +0,0 @@
|
||||
Divorce opened/closed status and classification.
|
||||
================================================
|
||||
|
||||
We need to track open/closed status and classification independantly.
|
||||
|
||||
Classification is one category, status should be another. Possible values for
|
||||
status:
|
||||
|
||||
* new
|
||||
* resolved
|
||||
* awaiting validation
|
||||
* rejected
|
||||
* reassigned
|
||||
|
||||
For the file-based issue implementation, the file format changes from
|
||||
``nnnnsp`` to ``nnnncsp`` where:
|
||||
|
||||
* ``nnnn`` still represents the bug number (no change)
|
||||
* ``c`` represents the *category* (used to be ``s`` the status):
|
||||
|
||||
* ``b``: Bug
|
||||
* ``f``: Feature
|
||||
* ``t``: Task
|
||||
|
||||
* ``s`` represents *status*, a new field:
|
||||
|
||||
* ``a``: Reassigned
|
||||
* ``j``: Rejected
|
||||
* ``n``: New
|
||||
* ``s``: Resolved
|
||||
* ``v``: Awaiting Validation
|
||||
* ``p`` still represents priority, ``0`` being the highest and ``9`` the
|
||||
lowest.
|
@ -1,4 +0,0 @@
|
||||
Ignore hidden directories.
|
||||
==========================
|
||||
|
||||
Directories that are hidden (determined via File.isHidden()) should not be traversed.
|
@ -1,2 +0,0 @@
|
||||
Create a build system
|
||||
=====================
|
@ -1,2 +0,0 @@
|
||||
Incorporate versioning into the build process.
|
||||
==============================================
|
@ -1,2 +0,0 @@
|
||||
Add the ability to change an Issue's priority.
|
||||
==============================================
|
@ -1,2 +0,0 @@
|
||||
Add the ability to change an Issue's category.
|
||||
==============================================
|
@ -1,2 +0,0 @@
|
||||
Add the ability to create a new issue.
|
||||
======================================
|
@ -1,5 +0,0 @@
|
||||
Remember last opened directory.
|
||||
===============================
|
||||
|
||||
This affects the JFileChooser, not the model.rootProject.
|
||||
|
@ -1,2 +0,0 @@
|
||||
De-select the 'CLOSED' category by default.
|
||||
===========================================
|
@ -1,2 +0,0 @@
|
||||
Clear the 'New Task...' dialog when hidden.
|
||||
===========================================
|
@ -1,2 +0,0 @@
|
||||
Set the default priority to '5'.
|
||||
================================
|
@ -1,2 +0,0 @@
|
||||
Issue display needs to save changes.
|
||||
====================================
|
@ -1,2 +0,0 @@
|
||||
Do not load project directory on startup.
|
||||
=========================================
|
@ -1,2 +0,0 @@
|
||||
Clear project lists when opening a new directory.
|
||||
=================================================
|
@ -1,5 +0,0 @@
|
||||
Issue display may still lose changes.
|
||||
=====================================
|
||||
|
||||
If the mouse is not within the text area and the user clicks on something
|
||||
that changes the text area content, the changes are not saved.
|
@ -1,2 +0,0 @@
|
||||
Add an optional word-wrap at 80 characters for the Issue display.
|
||||
=================================================================
|
@ -1,2 +0,0 @@
|
||||
Make 'New' the default new issue status.
|
||||
========================================
|
@ -1,2 +0,0 @@
|
||||
Add the ability to sort issues based on priority, id, category, or status.
|
||||
==========================================================================
|
@ -1,4 +0,0 @@
|
||||
Ignore Hidden directories.
|
||||
==========================
|
||||
|
||||
Directories that are hidden should be ignored (File.isHidden() determines).
|
@ -1,2 +0,0 @@
|
||||
Add the ability to hide projects.
|
||||
=================================
|
@ -1,7 +0,0 @@
|
||||
Hide a new issue after a delay if does not match the viewing criteria.
|
||||
======================================================================
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
The issue is not hidden after a delay, it is immediately hidden.
|
@ -1,2 +0,0 @@
|
||||
Load only N project deep at a time, lazy load any more.
|
||||
=======================================================
|
@ -1,2 +0,0 @@
|
||||
Add a runtime configuration file.
|
||||
=================================
|
@ -1,2 +0,0 @@
|
||||
Add templates for new issues.
|
||||
=============================
|
@ -1,29 +0,0 @@
|
||||
Add the ability to load multiple project roots simultaneously.
|
||||
==============================================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
I often need to switch between different issue repositories (project-specific,
|
||||
main work repo, etc.) and have to close the current repo and open a new one.
|
||||
I would like to be able to keep multiple repositories open at the same time.
|
||||
|
||||
Implementation Notes
|
||||
--------------------
|
||||
|
||||
The interface should use tabbed panes to represent the different project roots.
|
||||
The main view will need to split into seperate MVC components. This may simplify
|
||||
the initial configuration, as the view data structures for the lists will no
|
||||
longer be initialized at application startup.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
TBD
|
||||
|
||||
Resolution
|
||||
----------
|
||||
|
||||
Date Created: 2010-02-08
|
||||
Date Resolved: YYYY-MM-DD
|
||||
Delivery: 0017
|
@ -1,27 +0,0 @@
|
||||
Add a default, "all-projects" view.
|
||||
===================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Add a tab that simply lists all issues for all project in one giant
|
||||
list to the left and a the text area on the right.
|
||||
|
||||
Implementation Notes
|
||||
--------------------
|
||||
|
||||
I will need to create a new Project implementation that contains
|
||||
arbitratily many projects and flattens all the issues under the multiple
|
||||
projects into one list.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
TBD
|
||||
|
||||
Resolution
|
||||
----------
|
||||
|
||||
Date Created: 2010-03-08
|
||||
Date Resolved: YYYY-MM-DD
|
||||
Delivery: 0018
|
@ -1,28 +0,0 @@
|
||||
Add the ability to change the Issue text size.
|
||||
==============================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
It would be good to be able to choose the size of the text for issue display.
|
||||
|
||||
Implementation Notes
|
||||
--------------------
|
||||
|
||||
This is a shared value between all project panels, so this needs to be on the
|
||||
enclosing PIT mvc, not the individual *ProjectPanel* mvcs. The ideal
|
||||
implementation is to bind the ``issueDetailTextArea.font`` property from the
|
||||
*ProjectPanel* view to the main mvc ``model.issueDetailFont``, but this fails
|
||||
and I cannot determine why.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
The ``ProjectPanelController.displayIssue`` method checks the value of
|
||||
``issueDetailTextArea.font`` against the main mvc ``model.issueDetailFont`` and
|
||||
updates it if it differs before actually displaying the issue selected.
|
||||
|
||||
Resolution
|
||||
----------
|
||||
|
||||
Delivery: 0019
|
@ -1,4 +0,0 @@
|
||||
The auto-generated pit-swing.groovy file needs to be renamed.
|
||||
=============================================================
|
||||
|
||||
Currently, when
|
@ -1,19 +0,0 @@
|
||||
The auto-generated pit-swing.groovy file needs to be renamed.
|
||||
=============================================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Currently, when
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
TBD
|
||||
|
||||
Resolution
|
||||
----------
|
||||
|
||||
Date Created: 2010-03-19
|
||||
Date Resolved: YYYY-MM-DD
|
||||
Delivery: 0020
|
@ -1,23 +0,0 @@
|
||||
Icons not displaying in the project tree.
|
||||
=========================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
There should be icons in the list to the left to decorate it a bit.
|
||||
|
||||
Implementation Notes
|
||||
--------------------
|
||||
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
How was the bug fixed?
|
||||
|
||||
Resolution
|
||||
----------
|
||||
|
||||
Date Created: 2010-04-20
|
||||
Date Resolved: YYYY-MM-DD
|
||||
Delivery: 0021
|
@ -1,35 +0,0 @@
|
||||
New 'Bugs' created are not correctly categorized.
|
||||
=================================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
If the user clicks *New Issue* and does not manually select *Bug* from the drop-down
|
||||
list, but instead leaves the default *Bug* selected, the actual issue bypasses the
|
||||
template generation phase and gets its category defaulted to *Task*.
|
||||
|
||||
Implementation Notes
|
||||
--------------------
|
||||
|
||||
It looks like this is related to the default value of the category list in the
|
||||
*New Task* dialog.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
The values from the *NewIssueDialog* are publicly visible via fields on the
|
||||
model. The view has bound properties to update the model's fields whenever the
|
||||
appropriate gui field is updated. But when the dialog is shown initially, the
|
||||
view is reset programatically, not triggering the update to the model values.
|
||||
In the case of the first new issue since launching the program, the fields on
|
||||
the model are ``null`` or have their default initialized values. In subsequent
|
||||
issues, they hold whatever was there before. If the user never changed those
|
||||
values, they held their old values. The solution was to update the model as
|
||||
well as the view when showing the dialog.
|
||||
|
||||
Resolution
|
||||
----------
|
||||
|
||||
Date Created: 2010-04-20
|
||||
Date Resolved: 2010-04-20
|
||||
Delivery: 0022
|
@ -17,11 +17,19 @@ It looks like this is related to the default value of the category list in the
|
||||
Solution
|
||||
--------
|
||||
|
||||
How was the bug fixed?
|
||||
The values from the *NewIssueDialog* are publicly visible via fields on the
|
||||
model. The view has bound properties to update the model's fields whenever the
|
||||
appropriate gui field is updated. But when the dialog is shown initially, the
|
||||
view is reset programatically, not triggering the update to the model values.
|
||||
In the case of the first new issue since launching the program, the fields on
|
||||
the model are ``null`` or have their default initialized values. In subsequent
|
||||
issues, they hold whatever was there before. If the user never changed those
|
||||
values, they held their old values. The solution was to update the model as
|
||||
well as the view when showing the dialog.
|
||||
|
||||
Resolution
|
||||
----------
|
||||
|
||||
Date Created: 2010-04-20
|
||||
Date Resolved: YYYY-MM-DD
|
||||
Date Resolved: 2010-04-20
|
||||
Delivery: 0022
|
||||
|
Loading…
x
Reference in New Issue
Block a user