BUG: Drag&Drop Outlook message > inherit parent value(s) for field feeding when importing

[G-Eric]

Hi Dan,

Hi Dan,

I use to { drag and drop + holding the ALT key } Outlook messages on tasks to have the history as subtasks of the original parent record.

When doing this, there is a popup window coming in front, where it offers to direct each field of the message to a specific field of the task record.
In my usage, I direct all fields to 'Comment' except:
- creation time > creation date
- entry ID > file link
- sent date > start date
- subject > title.

The result is that all other fields of the Outlook message are in the 'Comments', as expected = ok.
My question: is it either by design or a bug that non-import fed fields { being marked in TDL settings as to be inherited from parent } are not filled in with parent value?

Example: TDL setting is set to inherit 'Category' from parent for subtasks when they are created (i.e. 'Attribute Inheritance').
Let's suppose I have a parent with 'Category' value set to 'For Action'.
I { drag and drop + holding ALT key } an Outlook message on this parent, and get the import popup window.
I set the import window parameters to push Outlook field 'Categories' to Task Attribute 'Comments'.
Therefore, task attribute 'Category' is left empty by the import process.
As it is a new subtask created where no value in forced by the import, I would have expected the newly created subtask to inherit the field 'Category' value 'For Action' from the parent (as defined in the settings).

Is this expectation wrong because the tool is not designed with this intention, or is there a bug that causes the field not being fed?

Thanks for your advise
Eric

[.dan.g.]

Short answer: It's a bug/omission.

>> As it is a new subtask created where no value in forced by the import, I would have expected the newly 

>> created subtask to inherit the field 'Category' value 'For Action' from the parent (as defined in the settings).

I think it might be trickier than this but first let me summarise how the inheritance currently operates because I think it is far from consistent:

1. Modifying an inherited parent attribute will update its subtasks even if the change cleared the parent attribute - CORRECT

2. Creating a new subtask will overwrite any default task attributes with its inherited parent attributes even if they are not set - CORRECT

3. Dragging a task on to another task (with or without 'Ctrl') will only update the subtask's attributes if the parent value is set - NOT SURE

4. 'Copy/Cut + Paste' of a task on to another task will only update the subtask's attributes if the parent value is set - NOT SURE 

5. 'Tools > Import' importing a task on to another task does not inherit its parent attributes even if they are set - INCORRECT

6. 'Alt+Drag/drop' importing a task on to another task does not inherit its parent attributes even if they are set - INCORRECT

Okay, so your suggestion would have 3/4 as being CORRECT and fixing 5/6 to operate similarly.

However, I'm not entirely happy about the subtle difference in behaviour between 1/2 and 3/4. My preference would be to fix 3/4/5/6 to operate like 1/2, but this would give a different outcome for you.

Happy to debate it more...

ps. I also noticed that undoing operations 3/4 does not undo the inheritance. I believe it should ie. Inheritance is part of the operation itself so this is a bug

[G-Eric]

Oh oh... it is indeed much trickier than I simply though.

I read your detailed explanation, and realized that it sounds like an iceberg.
I saw the small part I was using and just lost the view on other cases.

After a first time, I was thinking that your proposal was not optimal for import because you can have conflict with the user defined setting in the import popup window and the final values applied after inheritance process.
But then I adjusted my mind, and think currently that your view is (more) logical in the sense of the inheritance process - therefore, it should be applied for 3/4/5/6 as it is for 1/2 ; and if I am not happy with a field being overwritten by inheritance during import, I just have to inactivate the inheritance for the field on which I need again the control 'user's choice'.

However, for 5/6 (i.e. where the user has an intermediate potential action - e.g. my initial case for ALT+Drag/Drop), I think that (in an ideal world...) the offer of possible actions in the import window should then be limited to what will have a real effect.
What I mean is for example as follows: if inheritance is activated for 'Category' in TDL setup, when using ALT+Drag/Drop of an Outlook message on this parent, the import popup window should have the 'Category' item in the right side drop list (= 'Task Attributes' side) being greyed and not usable as target field because it is not a valid choice as the inheritance will anyway either overwrite an imported value or clear an imported value (according to the parent category state of the 'Category' field) - I hope my words are clear enough (long sentence, sorry).
In my last example, I could then direct the imported 'Category' to e.g. 'Comments' or even '{blank} to skip the import of this value if it is not relevant - so there are only solutions, no problem...  :-)

Note: IMHO this last 'nice to have' (greying a drop list element) could/should be a second stage (i.e. not blocking) ; implementing the coherence of behavior from 1/2 on 3/4/5/6 sounds to me a necessary first step to make the import more efficient according to features already in place.

Thanks for your open mind by accepting debate - appreciated.

[.dan.g.]

Thx for your response, you raise some good points.

>> implementing the coherence of behavior from 1/2 on 3/4/5/6 sounds to me a necessary first step to make the import more efficient according to features already in place.

I think there are two specific issues here that I just want to clarify again:

1. Making 5/6 consistent with 3/4 would mean that inherited attributes would overwrite imported attributes only if the inherited attributes have values in the parent.

eg. Importing "Task 2, status = delayed" on to "Task 1, status = ''" would produce:

Task 1, status = ''

  | 

  + Task 2, status = 'delayed'

but importing "Task 2, status = delayed" on to "Task 1, status = 'started'" would produce:

Task 1, status = 'started'

  | 

  + Task 2, status = 'started'

2. However making 3/4/5/6 consistent with 1/2 would mean that inherited attributes would overwrite imported attributes even if the inherited attributes had no values in the parent.

eg. Importing "Task 2, status = delayed" on to "Task 1, status = ''" would produce:

Task 1, status = ''

  | 

  + Task 2, status = ''

ie. blank parent values would overwrite non-blank subtask values.

But the more I think about it the more uncomfortable I am in just changing this behaviour, because I don't doubt that the current behaviour of 3/4 was implemented to meet a specific user need.

So, I'm going to back-peddle a bit and say that to start with I will just make 5/6 consistent with 3/4 which still means that imported attributes will get overwritten by inherited parent attributes but only if the parent actually has a value.

Said in another way: when importing, if the parent has a value that's what the subtask will get, otherwise it gets the imported value.

Then in 7.3, we have the option to add some preferences to control these behaviours better.

>> being greyed and not usable as target field because it is not a valid choice as the inheritance will anyway either overwrite an imported value or clear an imported value

If I was going to make 3/4/5/6 fully consistent with 1/2 as I first suggested then I would absolutely agree with you on this this, but my back-peddle rather changes things because the inherited attribute is still a valid target where the parent does not have a value.

And so it goes on... ;)

[G-Eric]

Thanks for the detailed explanation - I totally share your views, and believe that the back-peddle is the least

To be honest, my original (selfish) expectation was to have 5/6 aligned on 3/4 ; but then I kept calm and refocus my thoughts at an app global level where it is ideally "normal" to have 1/2/3/4/5/6 aligned.
Now, if you propose to adjust 5/6 by aligning with 3/4 as a next state of evolution, and later (7.3+) to enlarge with 1/2 alignment together with new options to fine tune the behavior where / if possible, I am more than happy as it give (me) all possible answers at the end.

In fact, my current usage really matches the flexibility power of either { inherit a parent value if there is one } or { to keep the imported value is the parent value is empty } - currently, I do this manually.
And of course, the suggestion of having greyed value in the 'task attributes' has no more sense in this approach - it makes it "easier" to evolve to an enhancement as this does not more need to be taken into account.

Well... nice perspective on the horizon  :-)

[.dan.g.]

Fixed in 7.2.3

On Wednesday, 16 January 2019 08:04:59 UTC+11, G-Eric wrote:

[G-Eric]

Tested and found ok in v7.2.3
Thanks a lot Dan.

[G-Eric]

Ooops... side effect  :-)

I have a list where the category is inherited from parent - ok so far.
I copy another task, and past it on the parent using the right-click menu option 'Paste as Reference' - ok so far.
The new task is created, being a reference of the original tak - ok so far.
And then I notice that the reference task has inherited of the paalicable category of the parent it was pasted on - logical, but...
And because the record 'reference' got this inherited category, the original (source) task had its category change - logical, but...

Well, what is the solution?
Could it be technically possible to inactivate inheritance for reference tasks?
If yes, does it makes sense? For the cases I reveiwed, yes - but the possibilities are so wide that I prefer to raise the point and make a "draft" proposal to be reviewed.

Thanks for you comment on this.
In the meantime, I will adjust manually the task references created when applicable.

[.dan.g.]

>> Could it be technically possible to inactivate inheritance for reference tasks?

Absolutely. Updating references doesn't make any sort of sense :)

[G-Eric]

Hi Dan,

I tested this with new v7.2.4.1 release, and report the following findings.

When the parent is updated, a child other than a reference is updated = ok.
When the parent is updated, a child being a reference is updated = ok.

When you have a mix of children (e.g. a set of 2 children 'not reference' then 1 child 'reference' then another set of 2 children 'not reference'): when the parent is updated...
/  the set of 2 children located between { the parent } and { the child being a reference } are updated = ok
|  the child being a reference is not updated = ok
\  the set of 2 children located after { the child being a reference } are not updated = not ok.

My understanding is that the update process is interrupted as soon as it encounter a reference.
In my humble opinion, it should not be interrupted at this point but should just skip the reference record to process each of the children (either to updateit or to skip it if it is a reference).

To document my findings, you will find 'Introduction.TDL' attached.
You can change the category of record '28', that will update records '29' and '30' but not record '34 (33)' = ok and not records '32' and '31' = not ok.

Is there an usage I forgot or a setting I missed to explain this behavior?
I thank you for your comment on this.

Have a nice day - Eric

[.dan.g.]

>>  it should not be interrupted at this point but should just skip the reference record

Yes, you are right.

[.dan.g.]

Fixed in 7.2.5?

On Tuesday, 5 February 2019 10:02:15 UTC+11, G-Eric wrote:

[G-Eric]

Yes, fixed in v7.2.5 - Thanks a lot!

[.dan.g.]

Hooray!