Class AssociateMDOProviderBase

Base class for the MDO providers that use the associate table as the source for their data.

Inheritance
object
MDOProviderBase
AssociateMDOProviderBase
AssociateMDOProvider
AssociateRestrictionsMDOProviderBase
DiaryOwnerMDOProvider
ProjectAssociateMDOProvider
QuoteApprovalAssociateMDOProvider
ResourceMDOProvider
ServiceAssociateMDOProvider
VisibleForAssociateMDOProvider
Inherited Members
Namespace: SuperOffice.CRM.Lists
Assembly: SoDataBase.dll
Syntax
[MDOAdditionalInfoSeparator(";")]
[MDOAdditionalInfo("heading_id", "Associates linked to this heading", 2)]
[MDOAdditionalInfo("group_idx", "Associates belonging to this user group (primary or secondary groups)", 2)]
[MDOAdditionalInfo("project_id", "Associates that are members of this project", 231)]
[MDOAdditionalInfo("get_deleted", "Associates that are retired", false)]
public abstract class AssociateMDOProviderBase : MDOProviderBase, ISoListProvider, ISoList, IEnumerable<ISoListItem>, IEnumerable
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

Constructors

AssociateMDOProviderBase(AssociateMDOProviderType)

Initialize the class

Declaration
public AssociateMDOProviderBase(AssociateMDOProviderType type)
Parameters
Type Name Description
AssociateMDOProviderType type
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

Fields

_AdditionalInfo

Any additional parameters to be used in the associate search

Declaration
protected Dictionary<string, string> _AdditionalInfo
Field Value
Type Description
Dictionary<string, string>
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

_additionalInfo_GetDeleted

Base class for the MDO providers that use the associate table as the source for their data.

Declaration
public const string _additionalInfo_GetDeleted = "get_deleted"
Field Value
Type Description
string
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

Properties

HistoryInfo

History information for the supported list

Declaration
public override HistoryInfo HistoryInfo { get; }
Property Value
Type Description
HistoryInfo
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

PersonTableInfo

Base class for the MDO providers that use the associate table as the source for their data.

Declaration
protected PersonTableInfo PersonTableInfo { get; }
Property Value
Type Description
PersonTableInfo
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

Methods

AcceptHistoryRow(ListTableRow)

Test if a history row is to be accepted into the collection

Declaration
protected override bool AcceptHistoryRow(ListTableRow row)
Parameters
Type Name Description
ListTableRow row
Returns
Type Description
bool
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

Construct(string, string, int[], bool, string, bool)

Phase two of the two-phase construction

Declaration
public override void Construct(string tableName, string additionalInfo, int[] historyIDs, bool onlyReadHistory, string searchValue, bool forceFlatList)
Parameters
Type Name Description
string tableName
string additionalInfo
int[] historyIDs
bool onlyReadHistory
string searchValue
bool forceFlatList
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

ExecuteQuery(Select, List<int>)

Execute the query in the database.

Declaration
protected void ExecuteQuery(Select sql, List<int> resultIds)
Parameters
Type Name Description
Select sql

The query to execute in the database.
List<int> resultIds

Collection holding the results of the query.
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

ExecuteReader(SoCommand)

Perform the execute reader on the command fetching the first 500 items.

Declaration
protected SoDataReader ExecuteReader(SoCommand cmd)
Parameters
Type Name Description
SoCommand cmd

The command toe perform the execute reader on.
Returns
Type Description
SoDataReader

The reader resulted from the execute reader method.
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GenerateCommonQuery(CustomSearch, ListInfo)

Base class for the MDO providers that use the associate table as the source for their data.

Declaration
protected virtual void GenerateCommonQuery(ListTableRows.CustomSearch query, ListInfo li)
Parameters
Type Name Description
ListTableRows.CustomSearch query
ListInfo li
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetAssociateFlatList()

Base class for the MDO providers that use the associate table as the source for their data.

Declaration
protected ListTableRows.CustomSearch GetAssociateFlatList()
Returns
Type Description
ListTableRows.CustomSearch
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetAssociateHeadingAndItems()

Associate headings are located in group

Declaration
protected ListTableRows.CustomSearch GetAssociateHeadingAndItems()
Returns
Type Description
ListTableRows.CustomSearch
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetHeadingIconHint(ListTableRow)

Get the icon hint text for a heading item

Declaration
protected override string GetHeadingIconHint(ListTableRow row)
Parameters
Type Name Description
ListTableRow row
Returns
Type Description
string
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetHeadingType(ListTableRow)

Get the type of the heading

Declaration
protected override string GetHeadingType(ListTableRow row)
Parameters
Type Name Description
ListTableRow row
Returns
Type Description
string
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetHistoryCollection()

Get History collection for associate list. History is both resource and associates, and field extra_id in history table indicate that the history is for the associatechooser.

Declaration
protected override ListTableRows.CustomSearch GetHistoryCollection()
Returns
Type Description
ListTableRows.CustomSearch

ListTableRows.CustomSearch
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetHistoryIconHint(ListTableRow)

Get the icon hint for a history item

Declaration
protected override string GetHistoryIconHint(ListTableRow row)
Parameters
Type Name Description
ListTableRow row
Returns
Type Description
string
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetItemIconHint(ListTableRow)

Get the icon hint for an item

Declaration
protected override string GetItemIconHint(ListTableRow row)
Parameters
Type Name Description
ListTableRow row
Returns
Type Description
string
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetItemName(ListTableRow)

Get the name of an item

Declaration
protected override string GetItemName(ListTableRow row)
Parameters
Type Name Description
ListTableRow row
Returns
Type Description
string
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetItemTooltip(ListTableRow)

Use dynamic tooltips for associates, since that gives more information; use static tooltip text for other types

Declaration
protected override string GetItemTooltip(ListTableRow row)
Parameters
Type Name Description
ListTableRow row
Returns
Type Description
string
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetItemType(ListTableRow)

Get the type of an item

Declaration
protected override string GetItemType(ListTableRow row)
Parameters
Type Name Description
ListTableRow row
Returns
Type Description
string
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetItemsAndHeadingsQuery()

Get the query for the resources (associates are fetched separately)

Declaration
protected override ListTableRows.CustomSearch GetItemsAndHeadingsQuery()
Returns
Type Description
ListTableRows.CustomSearch
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

GetSimpleListQuery()

Get a query to return a flat list if preference grouping allowed == false. This might happen for the associate chooser list if Admin Grouped list/Associate/Resources" is set to No.

Declaration
protected override ListTableRows.CustomSearch GetSimpleListQuery()
Returns
Type Description
ListTableRows.CustomSearch

CustomSearch query for the simple list
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

OnAddHeadingElementToCollection(SoListHeading)

Called when a heading item is added to the final collection

Declaration
protected override void OnAddHeadingElementToCollection(SoListHeading heading)
Parameters
Type Name Description
SoListHeading heading
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

OnAddHistoryElementToCollection(SoListItem)

Called when a history element is added to the final collection

Declaration
protected override void OnAddHistoryElementToCollection(SoListItem item)
Parameters
Type Name Description
SoListItem item
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

OnAddSubItemToCollection(SoListItem, List<ISoListItem>)

Called when an item is added to the item list of a heading

Declaration
protected override void OnAddSubItemToCollection(SoListItem item, List<ISoListItem> headingItemsCollection)
Parameters
Type Name Description
SoListItem item
List<ISoListItem> headingItemsCollection
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

ReadItemsAndHeadings()

Read heading and items. Special for associate is the combination of associates and resources in the same list. This means there will have to be two queries to get the items for the list.

Declaration
protected override void ReadItemsAndHeadings()
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

ReadSimpleList()

For diaryowner list, get the associate list and return it as a flat list if Admin Grouped list/Associate/Resources" is set to No.

Declaration
protected override void ReadSimpleList()
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

ResortFlattenedList()

Override sorting of the associate list if it has been flattened

Declaration
protected override void ResortFlattenedList()
Overrides
Remarks

The one thing to understand here is that, basically, associates are fetched by this class, while resources are fetched by the base class, and we try to combine those queries as well as possible. In fact, usually both queries are executed, but if we don't want resources then the resource query is 'sabotaged' by including a restriction that is always false, thereby making it collapse... and vice versa for associates. This design was reasonable enough when the provider was simple, but has now outlived its usefulness... however there is no time to fix it now, so we'll live with it for a while.

We should probably split into type-specific subproviders, not use the MDOProviderBase at all, and instead do some creative merging similar to what the archives do. Suggestions welcome to marek.

AdditionalInfo group_idx=-1 will retrive the MDO list for the logged on users main group.

Implements

Extension Methods