Sure. When I add the 'hide until [date]' feature (see #78), I can just expand it to work with recurring items too.

This is what I'd like to see regarding this feature:

A next action is "actionable" if not ("pending" or "incubate")

• *actionable*: The action shows up normally in context lists.
• *pending*: Has a relationship to another action. If the other action is not completed, this action will not be available in contexts. It should be listed on the project page in a separate section of pending actions. Instead of a checkbox, a little clock icon can show a hover tooltip to indicate what action it's dependent on.
• An action can be dependent on more than one other action. It will only become actionable when all dependencies are fulfilled.
• Using single dependencies, a chain of next actions can be planned out in a project, instead of having to enter them only as previous actions are completed.
• *incubate*: An action can have an optional start date. If the date hasn't been reached, the action will not show in contexts. It should show on the project page in a separate section of incubated actions.
• The start date should be settable as a fixed date, or relative to the due date.

I had some interface layout ideas for this functionality. Let me know if you're interested.

There was some minimal discussion on dependencies in Ticket #105. I think the previous comment is on the right track. One might wonder how to indicate an action that is both incubate_' and '''pending'''. Or an action that was dependent on an '''incubate''' action (perhaps any actions depending on an '''incubate''' action would be forced '_incubate themselves?). There are definitely some combinations that could be interpretted differently, so a set of rules would need to be defined to handle such cases...

To clarify my suggestion:

"One might wonder how to indicate an action that is both incubate and pending."

These should be two independent criteria and the user could set one or both. Only if both are satisfied should the action become actionable. To rephrase what I wrote above: a next action is actionable if ( (NOT pending) AND (NOT incubating) ).

"Or an action that was dependent on an incubate action (perhaps any actions depending on an incubate action would be forced incubate themselves?)"

Yes. You shouldn't be able to mark an incubated action as complete, so dependent actions wouldn't show up until their dependencies are both "hatched" (no longer incubated) AND completed.

This multiple dependency structure would require a new database table such as:

CREATE TABLE `dependencies` (
  `id` int(11) NOT NULL auto_increment,
  `todo_id` int(11) NOT NULL,
  `pending_id` int(11) NOT NULL,
  FOREIGN KEY (todo_id) REFERENCES todos(id) ON DELETE CASCADE,
  FOREIGN KEY (pending_id) REFERENCES todos(id) ON DELETE CASCADE
) TYPE=InnoDB;
}}}

Incubation would just require a new column in todos:

{{{
  `start` date default NULL,

Now just do that Rails magic, and we're done!

Some interesting ideas here, but they are actually quite complicated to implement (or at least, to implement well). The main problem as I see it with adding any complexity is changing the user interface without making it cluttered and difficult to navigate.

I'm certainly going to try to add a start date (as that's the thing I most miss myself in Tracks), but I'll have to think more about dependencies.

Updating tickets (#373, #105, #107, #117, #125, #126, #147, #177, #182, #183, #185, #197, #202, #206, #220, #236, #240, #276, #283, #294, #300, #305, #309, #312, #317, #324, #337, #357, #358, #360, #433, #452, #462, #17, #74, #82, #92, #123, #265, #431, #440, #475, #94, #256, #258, #464)

tickler and dependencies can be used for this. closing