-
Followers
lrbalt (Assigned To) , bsag
AttachmentsNo attachmentsActivity
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
- 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
- alternative option is a preference to automatically move to 'some-day' context for the project
- 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.
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 (#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)Time ExpenditureLoading