edavis10 / redmine_issue_due_date
- Source
- Commits
- Network (1)
- Issues (0)
- Downloads (0)
- Wiki (1)
- Graphs
-
Branch:
master
Redmine plugin that will automatically set an Issue's due_date based on the Version and / or Deliverable due date.
| name | age | message | |
|---|---|---|---|
 |
COPYRIGHT.txt | Sat Jul 18 13:50:32 -0700 2009 | |
| |
CREDITS.txt | Sat Jul 18 13:50:32 -0700 2009 | |
| |
GPL.txt | Sat Jul 18 13:50:32 -0700 2009 | |
| |
README.rdoc | Sat Jul 18 17:09:55 -0700 2009 | |
| |
Rakefile | Wed Oct 14 14:16:41 -0700 2009 | |
| |
VERSION | Loading commit data...  |
|
| |
init.rb | Wed Oct 14 14:16:41 -0700 2009 | |
 |
lib/ | Fri Sep 25 14:12:39 -0700 2009 | |
| |
rails/ | Wed Oct 14 14:16:41 -0700 2009 | |
| |
redmine_issue_due_date.gemspec | Wed Oct 14 14:16:44 -0700 2009 | |
| |
spec/ | Fri Sep 25 14:12:39 -0700 2009 |
Issue Due Date
Issue Due Date will set the Issue due dates to the due dates of versions or deliverables. It will also track due date so if a Version’s due date is changed, all of it’s issues with the same due date will also be changed.
Getting the plugin
A copy of the plugin can be downloaded from Little Stream Software or from GitHub
Installation and Setup
- Follow the Redmine plugin installation steps at: www.redmine.org/wiki/redmine/Plugins
- Restart your Redmine web servers (e.g. mongrel, thin, mod_rails)
- (optional step) If you would like to convert of the existing issues, backup
your database and run the rake task:
rake issue_due_date_plugin:update_due_dates RAILS_ENV=production
Usage
The plugin entirely works in the background when Issues, Versions, or Deliverables are saved. The plugin handles three separate states:
Issue edits
When an issue is edited, the plugin will check:
- If the issue’s due date has been set on the Issue or
- the deliverable has a due date or
- the version has a due date
If any of those are true, the issue will have it’s due date updated. If multiple of them are true, the first one will be used.
Version or Deliverable edits
The plugin will also hook into Versions so when the version’s due date is updated, all issues assigned to the Version will be updated if the issues:
- Do not have a due date or
- Have a due date equal to the Version’s old date
Example:
- Version X with a due of 2008-01-01 and issues of
- Issues A (due on 2008-01-01)
- Issue B (due on 2008-02-01)
- Issue C (no due date)
Changing Version X’s date to 2008-01-15 will update the due date of:
- Issue A to 2008-01-15. It has the same due date as the version, so it’s "following" the version.
- Issue C to 2008-01-15. It did not have a due date so it was given the version’s due date.
- Issue B’s due date will stay 2008-02-01.
Deliverables follow the exact same behavior.
Version or Deliverable reassignments
When reassigning an issue to a different version, if the issue due date matched the old version date, the issue will change it’s due date to match the new version.
Example:
- I have an issue assigned to Version A with a date that matches Version A
- If I change the issue to be assigned to Version B, then the date should change to version B’s due date.
Deliverables follow the exact same behavior.
License
This plugin is licensed under the GNU GPL v2. See COPYRIGHT.txt and GPL.txt for details.
Project help
If you need help you can contact the maintainer at the Bug Tracker. The bug tracker is located at projects.littlestreamsoftware.com
