Request: configurable advanced visibility
If you do add recurring events to a future version, could I also request an advanced visibility period for items? This would help prevent the summary being cluttered with low-priority items that aren't due for a long time.
e.g. For birthday items I'd generally only want them to be visible a few days head of their due date, for posting cards. For car servicing, I'd like to see them a few weeks ahead instead to allow for booking delays.
e.g. For birthday items I'd generally only want them to be visible a few days head of their due date, for posting cards. For car servicing, I'd like to see them a few weeks ahead instead to allow for booking delays.
Leave a comment
This is what I'd like to see regarding this feature:
A next action is "actionable" if not ("pending" or "incubate")
I had some interface layout ideas for this functionality. Let me know if you're interested.
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:
Now just do that Rails magic, and we're done!
"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.
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.