InfoQube IM - Community

Submitted by Armando on 2015/12/04 13:33

I know it's not a bug per se, but for me it acts like one.

Most of the time when an item is created as TLI, IQ assigns it the corresponding grid source field (I'm simplifying).

However, when the TLI is moved down the hierarchy (moved under another TLI), that field/source assignation is cancelled/deleted.

This can have annoying consequences -- it often does here! -- since this doesn't happen in any obvious way and what was there (the field) isn't anymore just because the item was moved.

E.g. A task moved under another item will arbitrarily stop being a task just because it was moved (no rule says that a task isn't allowed to be moved under another item in the same grid...) and might be disappear from some other grid where it should absolutely remain. This task might obviously be missed etc.

(The "auto-assign" field for all items added in this grid" option from the "manage grids" dialog can help alleviate this problem but it creates another problem while solving : now all items are "tasks" (following my previous example), and items need to be manually unchecked so that they aren't all tasks.)

Maybe an option to keep the TLI assignment? Don't know what the best solution is, but certainly, loosing the field assignment by moving it often not a good idea -- and not coherent with the idea that "all items are equal" (in that case TLIs and SLIs aren't equal : SLIs are lower grade... : - ) )

Comments

This got passed by but it's a real problem with real consequences (like missed tasks, forgotten items). Maybe a lack of clarity?

[quote]

Most of the time when an item is created as TLI, IQ assigns it the corresponding grid source field (I'm simplifying).

However, when the TLI is moved down the hierarchy (moved under another TLI), that field/source assignation is cancelled/deleted.

This can have annoying consequences -- it often does here! -- since this doesn't happen in any obvious way and what was there (the field) isn't anymore just because the item was moved.

[/quote]

An example of possible consequences, as suggested above:

A task moved under another item will arbitrarily stop being a task just because it was moved, even if no rule says that a task isn't allowed to be moved under another item in the same grid. That task might disappear from another grid where it should absolutely remain as a task. (And like I said : this task might be forgotten, missed etc.)

I don't mind using a workaround (but the grid option to assign some fields to all items won't do it). Any ideas?

-------------------------------------------------------

Windows 8.1

Sony Vaio S Series 13 (SVS131E21L)

Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Humm... I don't see this happening here. Items keep their values when moved from TLI to SLI

In Ecco Pro, which IQ is inspired from, moving an item from TLI to sub-item caused the field assignment to be lost, be it a text, date, yes/no or date field.

In IQ, only yes/no fields work this way, as it was thought that losing precious text / dates / number values was not a good idea

Which type of field are the issue here ?

[quote=Pierre_Admin]

In IQ, only yes/no fields work this way, as it was thought that losing precious text / dates / number values was not a good idea

Which type of field are the issue here ?

[/quote]

As you said : the boolean fields.

We've had that conversation in the past : to me Y/N fields data isn't less precious than other data.

I'd understand that some fields could be disposable if there was a special field category called "source fields", strictly used for item/grid pairing. But since IQ items' don't belong to grids, I think that removing data from an item, even if it's been applied automatically when it the item was added to the grid is somewhat hazardous (see my example above).

As I suggested above, the risk comes from the fact that the data loss is unexpected (as it's not applied equally for all data type and it doesn't happen in any obvious way -- nothing tells the user that data has been deleted).

In my case -- echoing the thread about orphan items -- that's how some of my items got lost into oblivion. Not that they can't be found again, but when you don't remember they existed in the first place, it's hard to go after them.

Disclaimer: "Testing IQ with the most advanced/complicated IQBase in the world". I.e. slower than average.

Windows 8.1

CPU: Intel i5 2.6ghz

The opposite is also true...

Say you create an a sub-item, it will not have the source field

But if another sub-item was initially created as as TLI, it would have the source field

Would that not be confusing

Best is probably to have this as a grid setting: Keep source fields when demoting Top level items...

In v63, added "Keep source field values when demoting TLI"

[quote=Pierre_Admin]

In v63, added "Keep source field values when demoting TLI"

[/quote]

Many thanks! That should do it.

Disclaimer: "Testing IQ with the most advanced/complicated IQBase in the world". I.e. slower than average.

Windows 8.1

CPU: Intel i5 2.6ghz

[quote=Pierre_Admin]

The opposite is also true...

Say you create an a sub-item, it will not have the source field

But if another sub-item was initially created as as TLI, it would have the source field

Would that not be confusing

[/quote]

It's true, but i think the convention is clear enough to avoid confusion: unless you set it in the "grids setting" to apply certain fields to all items, all TLIs get to be assigned the source field, and SLIs don't.

I think it feels logical that -- for example -- a contact (say Bozzo) created as TLI in a Contacts grid would/should remain a contact when moved in that grid -- unless the user explicitly changes that status by unchecking the contact field. If Bozzo is a person and you move it under a "friends" category under another contact item (e.g. Sam), why should it stop being a contact? It's not very intuitive as it requires attention to not forget to recheck the contact satus of that item if it's removed. It's however easy to remove the contact status if it's unwanted, like for other field types that are kept (text, datetime, numbers)

It also seems logical and easy to understand (as a convention) that an item created under a contact shouldn't/wouldn't necessarily be a contact (as it could be a subcategory, a comment,...), so it isn't set by default. However, if a contact was needed as SLI, it's easy enough to achieve : the user marks the item as a contact.

Basic convention: Items created as TLI have the source fields automatically assigned (when possible), others don't (unless other grid settings apply).

Disclaimer: "Testing IQ with the most advanced/complicated IQBase in the world". I.e. slower than average.

Windows 8.1

CPU: Intel i5 2.6ghz