Hi Сhuck,
Thanks for your thoughtful post. Still thinking about it.
I would not add any restrictions to MLO. User may have a reason to
hide in todo a branch of tasks for some time even with dominant tasks
inside it. I agree though that MLO still needs to inform user that it
happens somehow.
So I implemented it this way for now:
If a task in the dependency list cannot be visible in Active Actions
for some reasons it is marked with red sign (!) and the hint with
these reasons displayed for this task.
The following is now verified:
1) Task depends on folder (folder sign is shown in dependency)
2) Task depends on its parent task
3) Task depends on hidden in todo task
4) Task depends on task with completed parent
5) Dependency cycling.
I.e.:
task1 depends on task2;
task2 depends on task3
task3 depends again on task1
As a result all three tasks are hidden in todo due to cycling
dependency.
Look at it in new beta soon.
Andrey.
On Jan 7, 1:29 pm, chuckdevee <[email protected]> wrote:
> Hi Andrey, ah yes.. I hadn't though of all these instances. Seems to
> me that the Dependencies functionlity could potentially cause lots of
> problems for people and if it is unintentionally misused. Indeed, it
> may undermine a users reliance on MLO if it resulted in tasks
> seemingly inexplicably disappearing from the ToDo list. I really think
> this is a very important issue to resolve.
>
> To my mind,dependencycrucially only works if the dominant task is
> not prohibited from being shown in the ToDo view. A conflict occurs
> either when the dominant task is hidden from ToDo at the outset, or is
> subsequently hidden in some way.
>
> The optimal solution, in my opinion, is that conflicts are prohibited:
> that MLO point blank refuses to allow any change to the outline if it
> results in a conflict with dependencies, and additionally throws up a
> warning/explanation. This prevents dependencies being unintentionally
> misused and forces the user to change permissions (outline structure
> or existing dependencies) in some way before MLO will allow the
> change.
>
> Eg:
> A user sets a folder as a dominant task:
> "ACTION REFUSED. Reason: You have selected a dominant task that cannot
> be completed."
>
> A user sets a parent as a dominant task:
> "ACTION REFUSED. Reason: You have selected a dominant task that cannot
> be completed."
>
> A user tries to hide a branch with a dominant task embedded within:
> "ACTION REFUSED. Reason: You have a dominant task in the branch."
>
> A user sets a subordinate task as a dominant task:
> "ACTION REFUSED. Reason: You cannot select a dominant task as adependency."
>
> A user tries to move a dominant task to a hidden branch:
> "ACTION REFUSED. Reason: You cannot hide a dominant task"
>
> A user tries to move a branch with dominant task to a hidden branch:
> "ACTION REFUSED. Reason: You cannot hide a dominant task"
> etc etc.
>
> As you say, this isn't a trivial change as it means that you would
> have to monitor whether a task is dominant. If a task has a property
> which shows:-
> a) if it is dominant (ie has other tasks that depend on it - doesn't
> matter which) and
> b) if it is NOT able to be visible in the to-do view.
> Then it could be as simple as preventing changes in MLO if they result
> in both of these conditions being true for any task in the outline, as
> a result of any given change.
>
> As an alternative for a short-term solution, would it be possible to
> have an icon indicating whether a task has a dominant task that cannot
> be completed?
> Your suggestion of indicating this in theDependencyBox would also be
> welcome, It wouldn't be that visible but at least a user would have
> some indication of what
> was going on.
>
> Chuck
--
You received this message because you are subscribed to the Google Groups
"MyLifeOrganized" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mylifeorganized?hl=en.
