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, IArchiveProviderExtensibleConstructors
SelectionCombinedContactPersonExtenderBase()
Contact extender for dynamic selection, containing the special handling needed for the STOP and NO DM modifiers
Declaration
public SelectionCombinedContactPersonExtenderBase()SelectionCombinedContactPersonExtenderBase(Features)
Contact extender for dynamic selection, containing the special handling needed for the STOP and NO DM modifiers
Declaration
public SelectionCombinedContactPersonExtenderBase(ContactExtenderBase.Features features)Parameters
| Type | Name | Description |
|---|---|---|
| ContactExtenderBase.Features | features |
SelectionCombinedContactPersonExtenderBase(Features, string)
Contact extender for dynamic selection, containing the special handling needed for the STOP and NO DM modifiers
Declaration
public SelectionCombinedContactPersonExtenderBase(ContactExtenderBase.Features features, string context)Parameters
| Type | Name | Description |
|---|---|---|
| ContactExtenderBase.Features | features | |
| string | context |
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 |
|---|---|
| bool |
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 QueryProviderBase to eat all but the first instance of each contact.
Declaration
public FieldInfo PrimaryKey { get; }Property Value
| Type | Description |
|---|---|
| FieldInfo |