As far as implementation goes...

I suggest that instead of trying to define <sub-actions> as a new kind of thingy,
merely make all actions nestable - so you can add sub-actions to any action.

• Visually, how about a + icon beside every action that when clicked (similar to projects at home)
• changes to a - icon (clicking on it will re-close)
• shows all the sub-actions inside that action, with a Add-Action button/link on right to

add a sub action

• Have the check-box greyed out for any action that has incomplete sub-actions
• optionally allow a preference that allows you to turn on/off, with check-box background

or different check-icon indicating whether there's incomplete sub-actions.

• alternative option is a preference to automatically move to 'some-day' context for the project

(or similar)

• date behavior as follows:
• When a + shows the earliest date of the action or all sub-actions, perhaps in a different color
• When a - shows the date of the outer action (as date from sub-action will be visible in sub-action)
• Additional features (possibly now or future)
• allow dragging an action onto the + icon to open it's sub-actions for placement of action
• when opening for placement, will temporarily change icon to -, to allow below
• allow dragging an action onto the - icon to copy/link any action as a sub-action
• When - can make it a sub-action by dragging into sub-action-list
• reason want to copy/link is because actions for proj1_' may depend on actions from '_proj2.

This gives an easy way to automatically track waiting-for items,
so when proj2_' completes the action, '_proj1 copy/link automatically gets checked also

• Optionally have a preference for copy/link behaviour. Perhaps options like
• always ask whether to move or copy/link when dragged to action +/- icon
• always open to view sub-actions when drag-hovering over + icon
• open/collapse projects to show actions-with-sub-actions on side-bar
• dragging an action to projects/context side-bar

I don't agree that there should be sub-actions. If there are "steps" then it's a project not an action.
I hole heartedly support sub-projects. I think many of the suggestions above are great, they should be applied to projects not actions. Leave actions as a discrete unit.

Even just the simple linking of one project to another as a parent-child single layer would be a great feature for the short term while waiting for more complex project to project relationships.

I agree that sub-projects should not be called sub-actions, because that by definition an action cannot be divided. However it would make sense to be able to promote actions to sub-projects. I do fully support that adding sub-projects and think it would be a huge improvement. Is this being worked on?

Is this actively being worked on? This is one of a couple of high-priority features for me to encourage adoption within my organization, and I'm willing to do the work myself if i'm not duplicating effort.

My thought is this: projects get a nullable "parent" field. Subprojects just get that parent field assigned; to find Top-level projects (which can be thought of as areas of responsibility) you just find the projects with null parents. No "subactions" are required--actions should represent a discrete step to take, not a composition of steps.

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)

What about giving both projects and actions a "depends on" field? This way we might get a unified way of implementing both "subprojects" and "(re)orderable next actions". See also #91.

It is not the technical part that is hard. I agree on your approach. A good gui for this is the biggest problem.

Related association with ticket #300 was added

Updating tickets (#17, #47, #49, #83, #91, #97, #103, #107, #117, #125, #126, #175, #177, #183, #188, #197, #206, #211, #236, #240, #276, #294, #295, #305, #309, #312, #317, #324, #355, #357, #358, #371, #373, #393, #434, #452, #478, #503, #507, #535, #564, #565, #568, #569, #571, #572, #636, #668, #682, #686, #692, #715, #736, #741, #759, #773, #782, #783, #800, #828, #837)

Migrated to GitHub issue #373