[General] New contacts should inherit group settings

[GoogleCodeExporter]

Hello,
steps to reproduce:
1) Settings->Events->Ignore, disable status notifications for group XYZ
2) Main menu->Add/Search new contact->...->Add to group XYZ

What is the expected result?
New contact should inherit the ignore settings from the group

What happens instead?
New contact have no ignore settings

Peter

Original issue reported on code.google.com by Lastwebpage@gmail.com on 11 Dec 2009 at 12:24

[GoogleCodeExporter]

Original comment by sami%mir...@gtempaccount.com on 11 Dec 2009 at 2:39

• Added labels: Component-Core

[GoogleCodeExporter]

There is no such thing as ignore setting for the group. UI just computes 
"group" 
settings based on individual members.

Original comment by borkra on 11 Dec 2009 at 2:41

• Changed state: WontFix

[GoogleCodeExporter]

But the "Design" of this dialog suggests this. Imagine I have a group with 
players 
for an online game, or something similar. This group produce a lot of 
Offline/Online 
status messages. I would expect that new added member inherit the group 
settings, 
especially because the group flag is still set. Remember:

Group A..__X__
Member 1.__X__

Now I add a new one:
Group A..__X__
Member 1.__X__
Member 2.__.__

Either Member 2 should get __X__ too (I prefer this) OR the Group setting 
should 
work like a one time push-button not a switch. 

Original comment by Lastwebpage@gmail.com on 11 Dec 2009 at 3:02

[GoogleCodeExporter]

Its a good idea - instead of going to the settings and ignore every new 
contact. I 
prefer to be notified only for events related to few of my contacts that's why 
most 
of the contacts are ignored (at least the online notifications) because i would 
not 
like to listen the symphony produced by my contacts (some people use away 
options 
that changes their status like every 5 minutes). I mean there are few people 
that i 
am mostly interested in knowing if they are on or offline and will be easier if 
there 
is no need to go through the whole list and ignore the newly added contacts 
every 
month. Its a small and unnoticeable change but a handy one at least it will be 
for 
me. If there isn't such group option then what about a option to select default 
ignore settings for new contacts?

Original comment by neohidra on 11 Dec 2009 at 8:48

[GoogleCodeExporter]

Ok, it's a feature request, if somebody interested in this feature, they can 
implement 
it.

Original comment by borkra on 12 Dec 2009 at 1:20

• Changed state: New
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Bug

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I think this can be more deeply thought, and I'm aware that what I'm going to 
suggest
is a heavy core change.

Currently the only entity present in the Miranda database are Contacts, and all 
flags
and settings can generally be set only in that entity instances. It would be 
very
powerful if more levels were added as entities (Protocol, Account, Group,
Metacontact), so any flag/setting/customization (ignoring, status notifications,
sounds, etc.) could be added at any of these levels' instances.

Additionally, maybe the ability of meta-grouping any entities in another entity 
(tree
algorithm needed here) should put Groups, Metacontacts and Contacts at the same
level, and also Protocols and Accounts will be at the same level. That should 
leave
only two levels to treat, with one "metagroups" tree in both them.

As a lateral effect, the Metacontacts plugin will not be needed anymore. The 
contact
list will simply behave as a tree of meta-grouped entities, and settings could 
be set
in any of them.

Of course that's only a suggestion for the very very very long term. I think the
creation/deletion of these entities should not be difficult to implement, as 
there
are currently single "hookable" points in code for protocol, account and group
maintenance. But it means additional changes in the core to treat these
filtering-by-level settings and changes in almost all plugins to set these
options-by-level, and that's not a fast pass.

Original comment by malver...@gmail.com on 17 Dec 2009 at 6:40

[GoogleCodeExporter]

Good point, so if contact a member of 3 groups and this is coming, setting of 
which 
group it should inherit ?

Original comment by borkra on 17 Dec 2009 at 1:28

[GoogleCodeExporter]

@malversan, there is a new dbx plugin, named dbx_tree, http://forums.miranda-
im.org/showthread.php?t=20491& it can handle things like this.

Original comment by Lastwebpage@gmail.com on 17 Dec 2009 at 1:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> setting of which group it should inherit ?

Good question. When customizing, the logic says that the most nested setting has
precedence, but I haven't such a clear image when talking about "ignores" or
"triggers", for instance.

Maybe generic rules can be defined, or maybe every plugin itself could decide 
the
"most nested" or "most general" precedence of its settings, depending on its own
logic behaviour. Triggers are a good example that this can be a good thing to 
make
definable (maybe in a "this-setting-always-has-this-precedende-order" basis), 
but I
recognize that the idea increases its complexity with this in mind.

> there is a new dbx plugin, named dbx_tree

I didn't know that was already done. Apparently, this plugin implements the
meta-grouping tree for Contact/Metacontact/Group entities. I'm really glad that
someone had partially the same idea before.

Anyway, I saw its development is temporarily (and understandably) paused due to 
lack
of core support. I think heavy changes are needed in other parts, and that's 
not an
easy pill to swallow. Although the idea is a very powerful improvement, in my 
opinion.

And returning to the post that started this thread, plugins' settings should be 
also
able to be applied to a Protocol/Account entities tree. Now, thinking about the
precedence question made by Borka, I really see no easy way to handle this tree
duplicity.

To generalize, if we let the mind fly, we could also think about more groupable
entities that wouldn't fit in any tree: entities by age, entities from Russia,
entities that have webcam support (in a distant future), etc. Perhaps the
entities-tree thing might be a generalizable implementation. I'm thinking about 
the
database as a graph of entities and relationships, being relationships not
distinguible from entities, as they would also be entities that could respond to
plugins' settings and be grouped with other entities. And maybe (or maybe not) 
only
the Contact/Metacontact/Group tree should be visible in the contact list. But 
in the
middle of this idea, the precedence question appears again to torment me.

I'm pretty sure this is a thing to think about for months before even thinking 
about
typing a single line of code.

Original comment by malver...@gmail.com on 25 Dec 2009 at 11:35

[GoogleCodeExporter]

It's more or less easy in my opinion.

a) At the moment, miranda not allow duplicate contacts, new contacts should 
inherit 
the ignore settings from the groups.
The only special case here could be a metacontact with contacts from different 
groups. (Okay, this very often produce strange bugs in the metacontact plugin, 
but 
that's another question), in this case I guess the users await a similiar 
behavior, 
new added contacts to the metacontact get the ignore-settings for the 
metacontact.
(I must admit, I am not sure how the metacontact plugins handle the ignore 
settings)

b) With dbx_tree (or whatever) there are two possible ways for the ignore 
settings.
1) The first created contact is below a group, this contact should inherit the 
group 
settings.
2) Now I create a duplicate contact. The user would await, in my opinion, that 
the 
second contact, inherit the settings from the first contact, in this case not 
from 
the group settings, because the user have changed the setting for a contact 
within 
the groups already.

Peter

Original comment by Lastwebpage@gmail.com on 26 Dec 2009 at 9:39

[GoogleCodeExporter]

Any news? At least plans for the future?

Original comment by ROBYER on 9 Jun 2010 at 10:11