Impossible to move a subask being a reference of a locked task Topic is solved

[G-Eric]

Hi Dan,

Assume:
- a Task1 with 3 subtasks
- a Task2 which is locked
Then
- copy the Task2 to clipboard
- paste the clipboard as a reference (source = Task2) i.e. as a subtask of Task1
>> you can't move the reference task to manually reorder subtasks of Task1 as it is locked (as the source Task2)

I would have expected to be able to move the reference (to reorder these subtasks).
Is it intentional or a bug?

Thanks for your comment - Eric

[abstr]

Thx Eric, sounds like a bug.

[abstr]

Fixed in 7.2.21

[G-Eric]

Thanks for the fix ; however...

• moving the record 'reference of locked task' with mouse works as expected = ok
• moving the record 'reference of locked task' with keyboard does not work = not ok
  (not movement at all > reference record seems to be locked as its source is)

Is it intentional?
Or a technical restriction?

If not, maybe should the fix be reviewed.

[abstr]

I just missed the keyboard handling... :(

[abstr]

Actually it's a lot more complicated than I first imagined. Might be useful if we can figure out the rules between us...

Consider the following arrangement (work in progress):

Task 1 - LOCKED
|
|__Task 1.1
| |
| |__Task 1.1.1
| |
| |__Task 1.1.2 - REF to Task 1.3
|
|__Task 1.2 - LOCKED
| |
| |__Task 1.2.1 - REF to Task 1.3
| | |
| | |__Task 1.2.1.1 - REF to Task 1.1
| |
| |__Task 1.2.2
|
|__Task 1.3
| |
| |__Task 1.3.1 - REF to Task 1.2
| |
| |__Task 1.3.2


Behaviour:

1. Tasks 1.1/1.2/1.3 are NOT movable because their immediate parent (Task 1) is locked
2. Tasks 1.1.1/1.1.2 are movable because neither they nor their immediate parent (Task 1.1) is locked
3. Tasks 1.2.1/1.2.2 are NOT movable because their immediate parent (Task 1.2) is locked
4. Task 1.2.1.1 is movable because it is not locked and its immediate parent (Task 1.2.1) is a reference
5. Task 1.3.1/1.3.2 are movable because their immediate parent (Task 1.3) is not locked

[G-Eric]

Well, to be honest, I saw it much more simplified.

1. The current setting text related to 'Lock' in the 'Preferences' (v7.2.21) says:
   Treat subtasks of 'Locked' tasks as also being locked
   .
2. So, in my understanding of this setting, all subtasks of 'Task 1' (in your example below) are locked by parent inheritance.
   And this, whatever their nature is (i.e. item "task" or item "reference").
   .
3. Next to that, I think that an item "reference" should not inherit of the 'Lock' status of its source item "task".
   An item "reference" has its own 'Lock' life, either (un)locked by itself (as item) or by (in)direct parent inheritance (no upper level limit).
   .
4. In your example below, it is indeed very difficult to know what is the final 'Lock' status of some items.
   Having the 'Lock' rule potentially differentiated by 'the parent being direct or not' opens a space for complex / unpredictable conflicts.
   I am not sure it will help users for a smooth and efficient usage (i.e. risk to raise questions or inappropriate usage).

[abstr]

>> Treat subtasks of 'Locked' tasks as also being locked

Unfortunately I have to also handle the situations when this is not set...

Nevertheless it will be very helpful, once I have it working, for you to test the common usage you highlighted above...

[abstr]

Fixed in 7.2.22.

[G-Eric]

Tested with my previous issue item, and now found ok - many thanks for the fix, Dan.