Submitted by LeftEccoForIQ on 2023/09/25 03:00

Hey, trying to save some time figuring this out by picking your brains:

When an item changes from being a TLI to being a child item, e. g. because I dragged it from top level to underneath another top level item, I would IQ to clear certain fields (i. e. to make sure the item no longer has a value for some of my main grids). As I fiddle with these things so rarely, I tend to forget about most of the options - could this be done via auto-assign or would I need to script something?

Many thanks!

Comments

Hi Pierre,

Thanks for your reply!

You must mean the "Keep source field values when dragging out or demoting TLI".

The problem is that for drag and drop, removing the field value for the grid currently works only when the item is dragged to become a child item within the same grid. When I drag it to another grid but instead of dropping it as a TLI I drop it as some item's child, it retains the field value for the source grid.

Is that intentional?

 

Hi Pierre,

I just realized the issue is more complicated than it seemed:

1.  with date fields, there is no effect when demoting an item inside the grid for that field, i. e. I create a TLI with a date value, then demote it inside the grid and it retains its value. However, when I demote this date-value TLI by dragging it to become a child item in a yes/no grid, the date field value is removed.

2. starting out in a yes/no grid, the situation is practically reversed: on demoting inside the grid, the source value is removed, but when dragging to a date-value grid as a child, the yes/no source value is retained.

Hi Left,

If I understand you correctly, this may be done with a script. Two questions:
1. Do you you always want the same fields cleared when demoting the TLI?
2. Do you want this to happen every time any TLI is demoted?

Hi viking,

Thanks for offering to help!

I've been thinking whether I couldn't achieve this by using an auto-assign rule on the ItemParent field...

As for your questions,

1. I want any of a set of fields cleared, the "home" values for a handful of my main GTD-style grids. So if an item first appears in, say, my "Pending" grid and is then demoted, I want the Pending value to be erased.

2. Yes, hence my idea with ItemParent auto-assign.

Cheers

PS: Better wait and see what Pierre decides with regard to how to fix handling of that source field option before we invest any time into a custom solution?

PS: Better wait and see what Pierre decides with regard to how to fix handling of that source field option before we invest any time into a custom solution?

Yes, that is what I was thinking as well. In particular since I am not 100% clear on how you want it to behave. I was also thinking about using the ItemParent field as a trigger.

p.s. Maybe you are even better versed than me in the scripting? I have written some scripts and plan to do more. It would be nice if everyone could share their scripts here so that we could learn from each other. However, I suspect that very few here are writing scripts..?  There were many users who used scripts and Auto-Assign functions with  Ecco Extension, and I wrote a lot of LUA scripts a while ago...

Basically, for a given list of fields (say, A, B, C, and D), I want to make sure that none of these have a value when an item is demoted.

I have not done much scripting at all for InfoQube, only minor stuff in LUA for Ecco Extension back in the day, but extensive scripting in Autohotkey, much of it realted to improving Windows workflow, mouse gestures and keyboard layouts.

Over the last year and half, I've also familiarized myself with Emacs config, Org mode and Lisp - talk about a learning curve! There was a time when I thought I would end up moving all my stuff from IQ into Org mode but now I'm no longer sure that's a good idea. Looks like I'm here to stay after all.

Cheers

Basically, for a given list of fields (say, A, B, C, and D), I want to make sure that none of these have a value when an item is demoted.

OK. That is what I originally understood. I'll wait for Pierre but I am not 100% sure that it will solve your particular request because A,B,C may not be related to the current grid source.

Indeed, let me look at this next week

IIRC, the logic is that important information should not be removed when demoting

There does seem to be an issue when dragging from one grid to another. Behavior should be the same as within a grid

OK, the logic is as follows when demoting an item depending on the source field type:

  1. Date: Always keep
  2. Number: Delete value if 0 or equal to the default value
  3. Text: Delete value if " " or equal to the default value
  4. Y/N: Always delete

I'll ensure that all cases follow this rule:

  1. Move inside a grid
  2. Drag-drop inside a grid (when Ctrl key is not pressed)
  3. Drag-drop from a grid to another grid (when Ctrl key is not pressed)

Any other situation that needs to be handled?

 

Thanks for looking into this, Pierre.

I guess my best plan of action then would be just to transfer my Action field from the date-type to the Y/N type. I don't really need the date information in that field anyway. What might be the best way to achieve this? There are probably a couple of thousand items with that value.

Cheers

You can do this easily with the Properties pane:

  1. Create a Y/N field, say isAction
  2. If you want only TLI items to have this field, then in your grid, turn off Context Parents and select the first TLI item. Do Item > Select Siblings
  3. If you want all items to have this field, then show this Action field in another grid with display mode set to flat list -- no context parents. Select all items (Ctrl+A)
  4. Once items are selected, find the isAction field in the Properties pane and click on the checkbox. All items should now have the isAction field value.
  5. You can now change your main grid source from Action to IsAction
  6. Once happy with the result, you can delete the Action field

HTH!

Sorry, please ignore 'date-based'. I was still labouring under the assumption that my main action grid's source was a date-field, but as we discussed previously I've since switched it to a Y/N field.

What I think is happening is this:

Say I have a 'Pending' field and 'Action' field, both are Y/N grid sources. I want to make these fields (sort of 'labels' in this case) mutually exclusive so that when an item is moved from the one to the other, the former's field is set to N.

If, say, I create a TLI in 'Action' and drag it to be a TLI in the 'Pending' grid, the 'Action' field is set to N. So far, so good.

When I drag the same item to become a child item in the 'Pending' grid, 'Action' is also set to N, but 'Pending' is not switched to Y. I can work with that though it might be interesting to have an option to 'inherit' the 'Pending' trait from the new parent in this case. [Can this be done with tags? I have never looked into them.]

Where it gets confusing is when I create the item as a child item in the 'Action' grid, then promote it to become a TLI in the same grid. It now gets a 'Y' value for 'Action' but if I then drag it to the 'Pending' grid either as a TLI or a child, 'Action' remains true, I assume because the item did not have a Source Field Value, having been created as a child item and the 'Action' value it receives from later promotion to top level has a different status. Is that correct?

Could there be a field type that

1. Completely depends on an item being visible in the associated grid, either as a top level or a child item?

2. Is removed whenever that item is dragged out of the associated grid, regardless of the target position?

Or is this something that tags do?

Thanks!

Hi Left,

If you can reproduce it in the Welcome to IQ > Kanban grid, please send it over, with instructions

Thanks!

p.s. I just noticed that the Kanban grid no longer looks like a "kanban", some grids (such as Next and Active) have been moved to be stacked panes, perhaps move it back to something more kanban drag-drop friendly

How do I ?