Class SelectionCombinedContactPersonExtenderBase
Contact extender for dynamic selection, containing the special handling needed for the STOP and NO DM modifiers
Inheritance
Implements
Inherited Members
Namespace: SuperOffice.CRM.ArchiveLists
Assembly: SoDataBase.dll
Syntax
public class SelectionCombinedContactPersonExtenderBase : ContactWithPersonExtenderBase<SelectionContactPersonExtender>, IArchiveProviderQueryMapping, IArchiveExtender, IArchiveProviderDoesExtend, IArchiveProviderHasColumns, IArchiveProviderExtensible, IPlugin, ICombinedWithPossiblePersonFirstConstructors
SelectionCombinedContactPersonExtenderBase()
Declaration
public SelectionCombinedContactPersonExtenderBase()SelectionCombinedContactPersonExtenderBase(ContactExtenderBase.Features)
Declaration
public SelectionCombinedContactPersonExtenderBase(ContactExtenderBase.Features features)Parameters
| Type | Name | Description |
|---|---|---|
| ContactExtenderBase.Features | features |
Properties
NeedComplexPrimaryKey
Does the contact+person query need a complex (both contact AND person) key? This is true in one special, but useful, case: A search purely on contact criteria, but with the ALL option on persons. Then, we cannot either EITHER contactId OR personID, but have to use both in combination.
Declaration
public bool NeedComplexPrimaryKey { get; }Property Value
| Type | Description |
|---|---|
| Boolean |
PrimaryKey
Get the primary key field for the query: if it is a contact, it's the contact.contact_id; but if the person extender thinks
its query is needed, then it's the person.person_id that should be the primary key - except if we're running in the
'include first person' mode, where only the first person should be included, and all the rest dumped. A good way to do that
is to leave the contact as the primary key field, causing the duplicate eliminator in
Declaration
public FieldInfo PrimaryKey { get; }Property Value
| Type | Description |
|---|---|
| FieldInfo |