[Preferences] Unchecking 'Treat subtasks of 'Locked' tasks as also being locked' does not unlock some subtask actions

[Ryan]

TDL 8.3.3
.tdl and .ini attached

1) Note that !Task1 is locked but !Task2 is not locked.

2) Note that 'Treat subtasks of 'Locked' tasks as also being locked' in 'Preferences' is NOT checked. (see Image #1 below)

3) Attempt to archive !Task2. It archives but it does not delete from the original task file.

4) Attempt to delete !Task2. It cannot be deleted.

5) Attempt to drag !Task2 to another position. It cannot be dragged.

Conclusion:
Although the preference in 2) is not set, and the lock icon is not present, it appears that some actions on the subtask which are not expected to be locked are in fact locked. (there may be other actions which are locked, these are just examples).

As always not sure it is a bug or I am missing something. Thanks for taking a look!

Image #1

[abstr]

Hi @Ryan

There was a discussion some time ago (I vaguely recall) regarding the how locking should impact the structure of the tasklist (as opposed to simple attribute changes) and I decided that if a parent was locked then it shouldn't be possible to add or remove subtasks because the 'structure of its subtasks' is an attribute of the parent and is thus affected by the lock-status of the parent.

In contrast, a locked subtask can be moved around freely because its location in the tasklist is not one of its attributes, it's defined outside of the subtask.

It's something of a philosophical debate as to where to draw the line and I'm open to further discussion.

[Ryan]

Thanks Dan. That's interesting. I had considered that might be the case as I can see the point.

The difficult part is when you have multiple parents that are locked and need to make a change on a subtask that is deep into the structure. You have to switch to the tree view and then trace the structure all the way up manually unlocking each locked level, go down the chain and make the changes, and then remember everything that was locked and relock it.

It's extremely cumbersome and subject to error.

Not sure what the answer is. But I'll keep the thought on the back burner and maybe have a helpful idea at some point.

Thank you for explaining.

UPDATE:
Sometimes the change I want to make is as simple as marking a subtask completed. But it becomes a challenge just to do that.

I think I mentioned that the program I previously used allowed overriding the lock by simply depressing the Ctrl key. I found this to be extremely useful and quick but I assume you heard that suggestion before and decided against it. Understood if that is the case.

[abstr]

Can I ask: what is your intended goal when locking parents?

[Ryan]

The main reason I use the lock on parent tasks is to prevent accidental deletion. Yes there is a dialogue where you need to confirm deletion, but it's not unheard of, particularly if you are in a hurry or concentrating on something else to accidentally click okay to that dialogue out of habit. Then you can try and undo, but it may not always be successful.

In the worst case scenario you may have to go to a backup and reconstruct things which is something that can potentially be daunting.

This is especially important on the larger trees that have many complicated branches because they are of course the most difficult to reconstruct in the event of accidental deletion.

But on the other hand, the larger trees with more branches are the same ones that have the problem I described above... difficulty making changes on tasks that are deep within the structure.

So it's a catch-22.

The locks are needed on the more complicated branches, but the more complicated branches are exactly the place where the locks present the most difficulty for everyday use.

Of course the lock is also applied to make sure there's no accidental changes to attributes on some of the critical tasks. So there is often more than one reason.

By depressing and holding the Ctrl key while clicking to do things such as checking a completion checkbox, you can select any level of task to override the lock until the Ctrl key is released. That was a real game changer on the program I used before I discovered TDL.

[Ryan]

The main reason I use the lock on parent tasks is to prevent accidental deletion. Yes there is a dialogue where you need to confirm deletion, but it's not unheard of, particularly if you are in a hurry or concentrating on something else to accidentally click okay to that dialogue out of habit. Then you can try and undo, but it may not always be successful.

In the worst case scenario you may have to go to a backup and reconstruct things which is something that can potentially be daunting.

This is especially important on the larger trees that have many complicated branches because they are of course the most difficult to reconstruct in the event of accidental deletion.

But on the other hand, the larger trees with more branches are the same ones that have the problem I described above... difficulty making changes on tasks that are deep within the structure.

So it's a catch-22.

The locks are needed on the more complicated branches, but the more complicated branches are exactly the place where the locks present the most difficulty for everyday use.

Of course the lock is also applied to make sure there's no accidental changes to attributes on some of the critical tasks. So there is often more than one reason.

On the old program, by depressing and holding the Ctrl key while clicking to do things such as checking a completion checkbox, you could select any level of task to override the lock until the Ctrl key is released which would automatically relock it. That was a real game changer on the program I used before I discovered TDL.

[abstr]

I'm open to adding a single well-named preferences to alternate between the current behaviour and something closer to what you are looking for because I can see that the decision I made was considered but still somewhat arbitrary.

Could you possibly have a think about it and then post a new suggestion along those lines together with some suggested wording?

Then we can debate the behaviour and wording and come up with a plan for 9.0.

[Ryan]

Sure Dan. Another option for me is just to unlock everything. So I'll give that some thought too. It's not a critical feature for me, but it does give me some sense of security that data won't be accidentally changed or deleted especially on critical tasks with a lot of carefully assigned data.

I'll give it some thought for a while and if I come up with something I think might be useful I'll start a new suggestion.

Thanks again for helping me think this through. I also get a lot of benefit from bouncing ideas off of you and hearing your thoughts.