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 :

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.