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:
Jonathan Bernard
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
|
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
|
Resolution
|
||||||
----------
|
----------
|
||||||
|
|
||||||
Date Created: 2010-04-20
|
Date Created: 2010-04-20
|
||||||
Date Resolved: YYYY-MM-DD
|
Date Resolved: 2010-04-20
|
||||||
Delivery: 0022
|
Delivery: 0022
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user