InfoQube IM - Community

Submitted by markfoley on 2009/06/10 03:56

When entering an outline or plan, you tend to promote/demote items in the tree as you're organising it. The result (see right column of screenshot) is some being 'in the grid' and others being children because of which level you 'initially inserted' them at (root or as a child of another item). Eg 'effort estimate' was inserted at root level then moved to become a subitem so it has the flag but shouldn't.

This will probably make grid based search/filter results unpredictable. What is the best option to make this intuitive for users? My thoughts:

- This flag could change immediately whenever you promote/demote it (probably best).
- Could have an option that runs through the current visible items, setting the flag to true for 'root' items and clearing it for 'child' items. (less reliable)

Thoughts?

Comments

(Arrrrgggh. I can't seem to find anything I posted in this forum. This is so weird. Just spent 30min trying to find an old post I'm 100% sure I posted here. And it's not the first time. Pierre : are some posts deleted or what...???)

Anyhow, to come back to your comment, mark.

Yes, this is a problem I've been struggling with and I came with my own "solution" 6 months ago or so. Like I said, I'm sure I posted about it in this forum, but can't find it. Weird. Anyhow, here's my strategy (I don't find that the other ones work as well).

1- Most grids have a source based on this format :

[ a) first field which is a "no inheritance" field] OR [ b) second field with inheritance ON]

(example : Contact or AddressBook )

(of course, for some grid, this "complexity" is not necessary -- in my db, the "inbox" grid, for instance, remains with a simple source which is n)

more details about these 2 fields :

a) first field which is a "no inheritance" field -- which is related to the "item's nature or type" (in the example above : the contact field)

- special config. :

* it's a yes/no field

* the auto-assign rule is related to the "grid marker field" (addressbook field in the example above...) and will check it (YES) when contact is checked), but will not uncheck it if contact is "unchecked"

(example of autoassign rule for contact field: A:AddressBook=1

- Use : determines the true nature of an item (if it's a contact, an event, whatever -- of course, it can be multiple things. And the user gets to choose... IQ being IQ...)

b) second field with inheritance ON -- which we could call the "grid marker" field (in the example above : the AddressBook field)

- special config. : it's a yes/no field with inheritance ON + delete on item move (no auto-assign rule per se)
- Use : serves as marker to determine if an item is displayed in a grid or not. (that way : very easy to see if an item is displayed in a grid, or has been displayed in a grid, or not)

2- Special grid config (to be performed in the "manage grid" window)

in the "auto-assign ... " section of the "manage grid" window :

one has to add the name of the field which inheritance is set to ON (which I call the "grid marker" field) so that any item added to that grid will *always* be marked as being displayed in this grid. Any sub-item placed under an item with that field will also be assigned that field (because the field, remember, has the inheritance option ON)

3- Notes and usage tips :

a) The order of the fields in the source is important.

Why ? because the first field in the expression will be automatically assigned to ALL items entered in the grid when they're top level items : this is how IQ functions by design at the moment. Other items, if entered directly as subitems, will have to be manually assigned the field.

b) advantages and shortcomings :

advantages :

What are the advantages of such a method at the moment ? Well, looking for an item (through the various filters) is much, much much more easy. Why ? well, try this : in one of your grid that has a plain source (no inheritance), try to find and isolate an item that doesn't meet the source. Good luck. It's possible, but not intuitive.

If you want to see only the items that pertain to the nature of what should be in the grid, without all the notes and fluff (ie. : address book --> want to see only the contacts), just write "contact" in the filter bar. That's it. Here you go : only the contacts. If you're looking for that note you know you entered somewhere, write : item like "*whatever text you want here*". And here you go.

Potential (inexistent IMO) problem

The only potential problem with this method at the moment is that items entered through the "add item" window, will not get the same treatment as if they were entered/moved directly in a grid, and if one forgets to add the autoassign rule to the first of the 2 fields (as explained in 1- a) ). But if the rule is entered properly, it should absolutely not happen.

Try it, tell me what you think. To try easily, you can just create a new field for each grid (what I did is prefix all these new fields with "zz" so that they're clearly identified as "grid marker" fields). Don't forget to set inheritance on for these. And don't forget to : 1- put them in the right order in the source bar + right autoassign rules for fields 2- add the field with inheritance in the auto-assign box of the grid management window.)

Seems complicated, but it's actually very very simple.

I actually find the other post, very similar. But a bit outdated as I have refined my strategy a bit.

http://www.sqlnotes.net/drupal5/index.php?q=node/488 .

(Don't know why it was so hard to find. Interrestingly, a search doesn't show my post but somebody else's post in the same thread... Not very convenient, IMO. Pierre?)

Wow! I'll print that off and work through it, but I don't see it being easy to explain (lets face it - it wasnt!)

The simplest solution to me would be changing the flag for the 'grid source field' to true if you promote it to 'top level', and change it to false if you demote it. I'm not sure if others set subitems manually to have the 'grid source field' true when it isn't a root level item- if they do, this approach would overwrite their change.

However I can't think of any cases where you'd want subitems marked in this way anyway, if you want filters etc to work as you want. But I wouldn't be surprised if there were some!

Thanks mate

It's actually not that complicated mark... Only long to explain properly.

Basically, a grid source is composed of 2 fields. 1- One with inheritance ON (which is used to mark ALL items in a grid) and set to be assigned to any an all items entered in that grid, 2- another with inheritance OFF (which is used to mark only items which are really of the type corresponding to the actual grid : eg. : contacts in an address book grid...). To filter it becomes easy as all items from a particular grid share at least one field, the one with inheritance ON.

Here you go. 4 lines.

[quote=Armando]

I put the info from your other post in a table to help me see it clearer so I may as well show that too

[ a) first field which is a "no inheritance" field]	[ b) second field with inheritance ON
e.g. `Contact`	e.g `AddressBook`
1A) first field which is a "no inheritance" field -- which is related to the "item's nature or type" (in the example above : the `contact` field) - special config. : * it's a yes/no field * the auto-assign rule is related to the "grid marker field" (`addressbook` field in the example above...) and will check it (YES) when contact is checked), but will not uncheck it if contact is "unchecked" (example of autoassign rule for `contact` field: `A:AddressBook=1` - Use : determines the true nature of an item (if it's a contact, an event, whatever -- of course, it can be multiple things. And the user gets to choose... IQ being IQ...) 3- Notes and usage tips : a) The order of the fields in the source is important. Why ? because the first field in the expression will be automatically assigned to ALL items entered in the grid when they're top level items : this is how IQ functions by design at the moment. Other items, if entered directly as subitems, will have to be manually assigned the field.	1B) second field with inheritance ON -- which we could call the "grid marker" field (in the example above : the AddressBook field) - special config. : it's a yes/no field with inheritance ON + delete on item move (no auto-assign rule per se) - Use : serves as marker to determine if an item is displayed in a grid or not. (that way : very easy to see if an item is displayed in a grid, or has been displayed in a grid, or not) 2- Special grid config (to be performed in the "manage grid" window) in the "auto-assign ... " section of the "manage grid" window : one has to add the name of the field which inheritance is set to ON (which I call the "grid marker" field) so that any item added to that grid will always be marked as being displayed in this grid. Any sub-item placed under an item with that field will also be assigned that field (because the field, remember, has the inheritance option ON)

so to help me get my head around this - (I can see it's simple but it's only sinking in now!) correct me if I'm wrong here below:-

Source in the above example is:- Contact or Addressbook
Now normally in a grid, TLI's get the source field automatically ticked - in your example, a new top-level item gets Contact field ticked. This would probably be the field we see if we look at this grid in 'Manage Grids' (or as you say it would have to be first field listed in source-box)

Then the following line in 'Manage Grids' [Auto assign the following fields] will have AddressBook; and, if we look at AddressBook field it will have inheritance turned on.

I guess my only query is re the Contact field - you must have to apply this manually at times?

Question: what happens if you move a TLI to be a sub-item - wont it lose the filled Contact field according to Pierre's post of 2009-06-12 18:34.
> Fields are unassigned as an item is moved to be a sub of a TLI item
(just testing that & it doesnt seem to happen here - e.g. inbox item, when moved to become sub-item keeps Inbox ticked)
Would that be a problem for you Armando if it did work that way?

I can certainly see the advantage of this for filtering (which I have to admit I still almost completely avoid)

>I guess my only query is re the Contact field - you must have to apply this manually at times?

Yes, exactly.

Using icons makes it easy to see what's the "main nature" of an item -- if it does have a main nature...

See : -- link to nonexistent node ID 738 --

>Question: what happens if you move a TLI to be a sub-item - wont it lose the filled Contact field according to Pierre's post of 2009-06-12 18:34.
> Fields are unassigned as an item is moved to be a sub of a TLI item
>(just testing that & it doesnt seem to happen here - e.g. inbox item, when moved to become sub-item keeps Inbox ticked)
>Would that be a problem for you Armando if it did work that way?

Yes, it could be a problem. I discussed that with Pierre a while ago -- not sure if he remembers... ?

I think that TLI should not have their field "unassigned" when moved to be a sub of a TLI (especially that this works only with simple sources, not with complex ones) . Subs should be created without the field assignation though, that's logical. Then the user can decide to (re)assign the field or not.

One way of getting around that is having a popup dialog (with an option to eliminate the pop up and chose an option for future behavior) asking for permission to unassign field. That way, everybody would be happy. Of course, that might create an extra layer of complexity.

Example :

Let's say I create a contact under another contact, tick the "contact" field (YES).

Then, one day I just reorganize my hierarchies, decide promote that item (it becomes a TLI, no problem), and then demote it after. It would loose then its contact status in the address book (contact --> NO), hence could become hard to find and, in the future when syncing will become a reality, might be synched away from all other devices.

Conclusion... The way it is now is the best for me, and it feels logical.

I must say that I'm not a fan of the the Ecco way in IQ's context (Ecco doesn't have multiple parents, etc., IQ does, and so the idea of having only TLI -- by default -- meeting the source or part of it, is a bit weird).

There was a bug (now fixed). Unless the field has inheritance, the source of the grid is automatically assigned / unassigned to items as you move them in the grid

Fields are assigned is an item is move to be a TLI (context parents don't count)
Fields are unassigned as an item is moved to be a sub of a TLI item

Item (2) above was not being done

As for the use of the Add Item dialog, auto-assignment of grid source field is made, as it should

>Fields are unassigned as an item is moved to be a sub of a TLI item

Are you sure that was a bug ? It seems to me that you made that modification a while ago (I think I was the one who asked) because that was causing problems : when you were moving an item that's meeting the source down the hierarchy, it looses it's source adequation...

Changing the behaviour would oblige the user to reassign fields to all of these fields which meet the source but which are moved down the hierarchy. Seems counter intuitive to me... Personnaly, I prefer to de-assign fields, then to think about assigning them all the time. Easier to see what shouldn't be there, then to remember about what should be there but is not... IMO

If you want a field to be automatically checked and stay checked, you can use the Grid>>Properties>>Data>>Auto-Assign the following fields, and enter the grid source field(s) there.

Otherwise, depending if the item was created as a sub, or as a TLI and then moved as a sub, you'll get different field values, and that is not good. So Grid source fields automatically get assigned / unassigned as items are moved from TLI to subs, but this can be overwritten by:

Field inheritance (defined at the field level, applicable to all grids)
Auto-assign (defined at the grid level, applicable to a specific grid)

Now, this was not working very well in previous versions. Version 0.9.24D, to be released early next week, has this implemented in a more robust way

That makes sense to me Pierre, many thanks. I will see how that pans out in the next build but that seems the simplest method. Thanks Armando for your explanation, too!