* Refactor formatting logic to better calculate needed padding between
issues and sections.
* Add `list contexts` command to list all known contexts according to
the contexts configuration and the contexts defined in issues.
* Be more intentional about when the default context is used. Don't
override existing context values in issues when changing their state.
* `edit` now allows multiple issues to be edited.
* Change single-issue display to be more verbose, listing all the
properties and tags on an issue.
The REST API is simply a wrapper around the command line (and actually
invokes the command line). It relies on the command line tool validating
its input.
Currently only the `/list` endpoint is implemented, exposing the `list`
command.
The Dormant state is for tasks that are still outstanding but not of
immediate importance. The main different between Dormant and Todo is
that dormant tasks are not listed by default. You must
`pit list dormant` to see them.
* Fixed a bug in the option parsing. When no options (or unknown options) where
presented it was not properly defaulting.
* Fixed a bug when incorrect options where given. Apache Commons CLI fails
entirely when it is unable to parse an option. This means we cannot get the
`--dir` option and we default to the program's working directory. When running
on Nailgun this is not the desired behavior and can cause pit to look through
a very deep file heirarchy to find issues.
* Fixed the bug in FileIssue where it would append a blank line to the body of
an issue every time it wrote the issue to the file. Fixed by making the
parser consume a line break before the property section.
* Fixed PIT CLI -D option sorting of issues so that it will sort issues by
priority, then due date.
* The extended properties table was using the maxKeyLength for both keys and
values.
* FileIssue was not persisting the file when extended properties were updated.
PIT CLI
-------
* Added an option, `-e`, to filter by extended properties and its complement,
`-E`, to set extended properties. Format of the option argument is
`<propName>=<propValue>`.
* Added the `--title` and `--text` options to specify the title and text of an
issue on the command line.
* When a new issue is created or an issue is set to rejected or resolved status
a timestamp is added as an extended property: `created`, `rejected`, and
`resolved` are the property names respectively.
* Added support for extended properties to `Filter`. Unlike the basic
properties, which allow the caller to specify a list of acceptable values, the
extended properties only supports a map of properties, all of which must be
available on the issue and match the given value.
* Made `Issue` a concrete class. There was no reason it could not be a concrete
object. The main difference is that the extending classes all add some sort of
persistence to the issue, but having an in-memory `Issue` in its most basic
form can be useful and should be allowed.
* Changed the default priority for new issues from 9 to 5.
* Bug fix on `FileIssue.formatIssue()`. If was not properly returning its
result leading to failure if no extended properties were given.
* Reworked `FileIssue.formatIssue()` to only print the horizontal rule
seperating the issue text from the extended properties if there are extended
properties to print as well.
* Changed the `FileProject.createNewIssue()` to handle extended properties and
handle the basic properties in a manner more consistent with `Issue`. It is
now creating an `Issue` object and using the `FileIssue.formatIssue()`
function to write that to a new issue file, then loading that file back in as
a `FileIssue`. This cuts down on code duplication and makes it so that the
options map that `FileProject.createNewIssue()` expects is the same as the
options to the `Issue` constructor.
* Added the order issues option (`-o`) to pit-cli. This option allows you to
specific a sorting criteria for the issues returned. The form of the option is
`-o <property>,<property>` where the properties can be any properties of the
issues being sorted. The option supports short one-letter forms of the basic
properties (id, priority, status, and category).
* Added the daily list mode (activated with the `-D` option). This mode prints
out the tasks scheduled for today (based on the `scheduled` property, the
tasks due today (based on he `due` property), the issues which have a reminder
that is active (based on the `reminder` property), and the remaining open
issues (those which do not fall in any of the other categories). This mode
looks through all projects in the given repository and does not do any
filtering or visual seperation by project.
The individual sections can be suppressed or singled out by using the
following options.
Additive options (if none are given all sections are present).
* `--dl-scheduled`
* `--dl-due`
* `--dl-reminder`
* `--dl-open`
Negative options (these suppress a specific section).
* `--dl-hide-scheduled`
* `--dl-hide-due`
* `--dl-hide-reminder`
* `--dl-hide-open`
Additive options are useful if you only want one or two sections. Negative
options are useful if you only want to exclude one or two sections. It does
not make sense to use both additive options and negative options, but it is
allowed.
* Fixed a bug in the common build. This bug is fixed in version 1.9, but I am
patching this bug locally in 1.6 until I have evaluated 1.9 with this project.
* Moved `ExtendedPropertyHelp` to `com.jdbernard.pit` from
`com.jdbernard.pit.file`.
* Added a number of property types to `ExtendedPropertyHelp`. New additions are:
* `java.util.Calendar` *object -> string value only*
* `java.util.Date` *object -> string value only*
* `java.lang.Long` *this replaces `java.util.Integer`*
* `java.lang.Float` *object -> string value only*
* `java.lang.Double`
* Cleaned up the `matches(String)` and `matches(Class)` functions of
`ExtendedPropertyHelp`
* Modified `Filter` sorter behaviours. The `issueSorter` and `projectSorter`
fields are now allowed to be either a closure or a list of closures. A single
closure works as it did before. The list of closures allows the caller to
specify multiple sort criteria. The individual criteria closures are applied
in reverse order, so that the first item in the sorter list is the most
significant criteria. For example, if the caller set the sorter to
`[{it.category},{it.priority}]` then the issues would be sorted first by
priority and then sorted again by category, meaning that the resulting data
would be ordered first by the category of the issue and then by the priority
for issues that share the same category.
* Modified the methods in `Project` that use `Filter` objects to conform to the
above behavior regarding sorting. It may be a better idea though to move the
sort code all into `Filter` so that it is in one place.
* Cleaned up the code in `Status` for matching status based on given symbols or
partial status names.
