Class AppointmentMatrix

Matrix holding information about repeating appointment and participants.

Inheritance

Object

NestedPersist

AppointmentMatrix

Implements

INestedPersist

Inherited Members

NestedPersist._saveOwner

NestedPersist._isSaving

NestedPersist.SetSaveOwner(INestedPersist)

NestedPersist.INestedPersist.OnPreIdUpdate()

NestedPersist.INestedPersist.OnPrimaryKeyRequest(PKContainer)

NestedPersist.INestedPersist.OnPrimaryKeyUpdate(PKContainer)

NestedPersist.INestedPersist.OnIdUpdate()

NestedPersist.INestedPersist.OnSave(BatchSave)

NestedPersist.INestedPersist.OnSaved(Boolean)

NestedPersist.add_OnElementSaved(OnSaved)

NestedPersist.remove_OnElementSaved(OnSaved)

NestedPersist.add_OnElementIdUpdate(OnIdUpdate)

NestedPersist.remove_OnElementIdUpdate(OnIdUpdate)

NestedPersist.IsSaving

NestedPersist.IsMarkedForDelete

NestedPersist.OnElementSaved

NestedPersist.OnElementIdUpdate

Namespace: SuperOffice.CRM.Entities

Assembly: SoDataBase.dll

Syntax

public sealed class AppointmentMatrix : NestedPersist, INestedPersist

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Constructors

AppointmentMatrix(Appointment, RecurrenceUpdateMode)

Create new instance of the appointment matrix

Declaration

public AppointmentMatrix(Appointment appointment, RecurrenceUpdateMode recurrenceUpdateMode)

Parameters

Type	Name	Description
Appointment	appointment
RecurrenceUpdateMode	recurrenceUpdateMode

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AppointmentMatrix(AppointmentRow, RecurrenceUpdateMode)

Matrix holding information about repeating appointment and participants.

Declaration

public AppointmentMatrix(AppointmentRow appointment, RecurrenceUpdateMode recurrenceUpdateMode)

Parameters

Type	Name	Description
AppointmentRow	appointment
RecurrenceUpdateMode	recurrenceUpdateMode

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AppointmentMatrix(Int32, RecurrenceUpdateMode)

Create an AppointmentMatrix based on an appointment ID. If the ID is 0, a new appointment entity is created, otherwise we try to read it from the database.

Declaration

public AppointmentMatrix(int appointmentId, RecurrenceUpdateMode recurrenceUpdateMode)

Parameters

Type	Name	Description
Int32	appointmentId	ID of appointment to process
RecurrenceUpdateMode	recurrenceUpdateMode	How recurrence updates should be handled

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Fields

_sendNewInvitations

Matrix holding information about repeating appointment and participants.

Declaration

public readonly List<ParticipantInfo> _sendNewInvitations

Field Value

Type	Description
List<ParticipantInfo>

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Properties

Agenda

Matrix holding information about repeating appointment and participants.

Declaration

public TextRow Agenda { get; }

Property Value

Type	Description
TextRow

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AppointmentText

Matrix holding information about repeating appointment and participants.

Declaration

public TextRow AppointmentText { get; }

Property Value

Type	Description
TextRow

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

BookingType

Matrix holding information about repeating appointment and participants.

Declaration

public BookingType BookingType { get; }

Property Value

Type	Description
BookingType

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

CurrentAppointmentRow

Matrix holding information about repeating appointment and participants.

Declaration

public AppointmentRow CurrentAppointmentRow { get; }

Property Value

Type	Description
AppointmentRow

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

CustomFields

Matrix holding information about repeating appointment and participants.

Declaration

public EntityCustomFieldsHelper CustomFields { get; }

Property Value

Type	Description
EntityCustomFieldsHelper

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

ExtraFields

Matrix holding information about repeating appointment and participants.

Declaration

public EntityExtraFieldsHelper ExtraFields { get; }

Property Value

Type	Description
EntityExtraFieldsHelper

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

ForceChildProcessing

Matrix holding information about repeating appointment and participants.

Declaration

public bool ForceChildProcessing { get; }

Property Value

Type	Description
Boolean

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

InnerMatrix

Matrix holding information about repeating appointment and participants.

Declaration

public KeyedMatrix<ParticipantInfo, RecurrenceDate, AppointmentRow> InnerMatrix { get; }

Property Value

Type	Description
KeyedMatrix<ParticipantInfo, RecurrenceDate, AppointmentRow>

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

InnerRemovedMatrix

Matrix holding information about repeating appointment and participants.

Declaration

public KeyedMatrix<ParticipantInfo, RecurrenceDate, AppointmentRow> InnerRemovedMatrix { get; }

Property Value

Type	Description
KeyedMatrix<ParticipantInfo, RecurrenceDate, AppointmentRow>

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

InternalNotes

Matrix holding information about repeating appointment and participants.

Declaration

public TextRow InternalNotes { get; }

Property Value

Type	Description
TextRow

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

IsBooking

Matrix holding information about repeating appointment and participants.

Declaration

public bool IsBooking { get; }

Property Value

Type	Description
Boolean

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

IsBookingMaster

Matrix holding information about repeating appointment and participants.

Declaration

public bool IsBookingMaster { get; }

Property Value

Type	Description
Boolean

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

IsDeleted

Matrix holding information about repeating appointment and participants.

Declaration

public override bool IsDeleted { get; }

Property Value

Type	Description
Boolean

Overrides

NestedPersist.IsDeleted

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

IsDirty

Is the object dirty?

Declaration

public override bool IsDirty { get; }

Property Value

Type	Description
Boolean

Overrides

NestedPersist.IsDirty

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

IsExternalInvitation

Matrix holding information about repeating appointment and participants.

Declaration

public bool IsExternalInvitation { get; }

Property Value

Type	Description
Boolean

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

IsRecurring

Matrix holding information about repeating appointment and participants.

Declaration

public bool IsRecurring { get; }

Property Value

Type	Description
Boolean

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

LinksHelper

Matrix holding information about repeating appointment and participants.

Declaration

public ActivityLinksHelper LinksHelper { get; }

Property Value

Type	Description
ActivityLinksHelper

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

MainBooking

Returns Main or Current Appointment entity.

Declaration

public Appointment MainBooking { get; }

Property Value

Type	Description
Appointment

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

MainBookingRow

Matrix holding information about repeating appointment and participants.

Declaration

public AppointmentRow MainBookingRow { get; }

Property Value

Type	Description
AppointmentRow

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

OnNotifyCentralServicesForVideoMeetings

Matrix holding information about repeating appointment and participants.

Declaration

public static Action<bool> OnNotifyCentralServicesForVideoMeetings { get; set; }

Property Value

Type	Description
Action<Boolean>

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Ownership

Get the ownership to the data in the matrix. OwnershipIndex.None is returned if the currently logged in user does not have rights to the _currentAppointment record. OwnershipIndex.Unknown is returned if the matrix is in a state where _mainbooking or _currentAppointment is null (VB: Nothing).

Declaration

public AppointmentMatrix.OwnershipIndex Ownership { get; }

Property Value

Type	Description
AppointmentMatrix.OwnershipIndex

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

PublishHelper

Matrix holding information about repeating appointment and participants.

Declaration

public EntityPublishHelper PublishHelper { get; }

Property Value

Type	Description
EntityPublishHelper

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Recurrence

Matrix holding information about repeating appointment and participants.

Declaration

public RecurrenceInfo Recurrence { get; set; }

Property Value

Type	Description
RecurrenceInfo

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

RecurrenceUpdateMode

Matrix holding information about repeating appointment and participants.

Declaration

public RecurrenceUpdateMode RecurrenceUpdateMode { get; }

Property Value

Type	Description
RecurrenceUpdateMode

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SendMailFunction

Matrix holding information about repeating appointment and participants.

Declaration

public AppointmentMatrix.SendMails SendMailFunction { get; set; }

Property Value

Type	Description
AppointmentMatrix.SendMails

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SendPushMessageToOurself

If true, we will also send push messages to logged in user if specified as recipient If false, we will filter out logged in user

Declaration

public bool SendPushMessageToOurself { get; set; }

Property Value

Type	Description
Boolean

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Task

Matrix holding information about repeating appointment and participants.

Declaration

public TaskRow Task { get; }

Property Value

Type	Description
TaskRow

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Title

Matrix holding information about repeating appointment and participants.

Declaration

public TextRow Title { get; }

Property Value

Type	Description
TextRow

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

UdefHelper

Matrix holding information about repeating appointment and participants.

Declaration

public EntityUdefHelper UdefHelper { get; }

Property Value

Type	Description
EntityUdefHelper

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

VisibleForHelper

Matrix holding information about repeating appointment and participants.

Declaration

public EntityVisibleForHelper VisibleForHelper { get; }

Property Value

Type	Description
EntityVisibleForHelper

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Methods

Accept()

Accept all occurrences for the current appointment. If only one occurrence exist, then only this one is accepted (not a recurring booking appointment)

Declaration

public void Accept()

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Accept(ParticipantInfo)

Accept all occurrences of the appointment for the participant. If only one occurrence exist, then only this one is accepted (not a recurring booking appointment)

Declaration

public void Accept(ParticipantInfo participantInfo)

Parameters

Type	Name	Description
ParticipantInfo	participantInfo	Participant that accepts all occurrences of the appointment

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Accept(ParticipantInfo, RecurrenceDate)

Accept the appointment for the provided participant at the given date

Declaration

public void Accept(ParticipantInfo participantInfo, RecurrenceDate date)

Parameters

Type	Name	Description
ParticipantInfo	participantInfo	Participant that accepts the appointment
RecurrenceDate	date	The date of the accepted appointment

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Accept(Int32, RecurrenceUpdateMode)

Accept all occurrences for the current appointment. If only one occurrence exist, then only this one is accepted (not a recurring booking appointment). The result of the rejection is saved to the database.

Declaration

public static void Accept(int appointmentId, RecurrenceUpdateMode recurrenceUpdateMode)

Parameters

Type	Name	Description
Int32	appointmentId	AppointmentId of Invitation or Assignment to be set to accepted.
RecurrenceUpdateMode	recurrenceUpdateMode	How recurrence updates should be handled

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AcceptRejectedAppointment()

Booking owner can accept that a participant has rejected an invitation. The rejected invitation will then NOT appear in the booking owner's Invitation dialog anymore.

Declaration

public void AcceptRejectedAppointment()

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AcceptRejectedAppointment(ParticipantInfo, RecurrenceDate)

Booking owner can accept that a participant has rejected an invitation. The rejected invitation will then NOT appear in the booking owner's Invitation dialog anymore.

Declaration

public void AcceptRejectedAppointment(ParticipantInfo participantInfo, RecurrenceDate date)

Parameters

Type	Name	Description
ParticipantInfo	participantInfo	Participant that accepts the appointment
RecurrenceDate	date	The date of the accepted appointment

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AcceptWithEmailConfirmation()

... ... send emails

Declaration

public void AcceptWithEmailConfirmation()

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AddDate(RecurrenceDate[])

Add a date to the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.

Declaration

public void AddDate(params RecurrenceDate[] dates)

Parameters

Type	Name	Description
RecurrenceDate[]	dates	Date to add to the repeating appointment.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AddDate(DateTime[])

Add a date to the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.

Declaration

public void AddDate(params DateTime[] dates)

Parameters

Type	Name	Description
DateTime[]	dates	Date to add to the repeating appointment.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AddParticipant(ParticipantInfo[])

Matrix holding information about repeating appointment and participants.

Declaration

public void AddParticipant(params ParticipantInfo[] participants)

Parameters

Type	Name	Description
ParticipantInfo[]	participants

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AssignTo(ParticipantInfo)

Assign the booking to the participant given as parameter. If booking is a recurrence then the participant is assigned as booking owner for all instances.

Declaration

public void AssignTo(ParticipantInfo participantInfo)

Parameters

Type	Name	Description
ParticipantInfo	participantInfo	Participant to assign the booking to (will become the owner)

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

AssignToExternalOrganizer(ParticipantInfo)

Assign the booking to the participant given as parameter. If booking is a recurrence then the participant is assigned as booking owner for all instances.

Declaration

public void AssignToExternalOrganizer(ParticipantInfo newOwner)

Parameters

Type	Name	Description
ParticipantInfo	newOwner	Participant to assign the booking to (will become the owner)

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

CalculateDays()

Calculate the days according the the recurrence pattern described.
Nothing will be performed if RecurrenceUpdateMode is OnlyThis.

Declaration

public void CalculateDays()

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Cancel(ParticipantInfo)

Matrix holding information about repeating appointment and participants.

Declaration

public void Cancel(ParticipantInfo participantInfo)

Parameters

Type	Name	Description
ParticipantInfo	participantInfo

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Delete()

Delete items in the appointment matrix.

Declaration

public void Delete()

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

DeleteCancelled(Int32, RecurrenceUpdateMode)

Deletes appointment if it is cancelled.

Declaration

public static void DeleteCancelled(int appointmentId, RecurrenceUpdateMode recurrenceUpdateMode)

Parameters

Type	Name	Description
Int32	appointmentId	.
RecurrenceUpdateMode	recurrenceUpdateMode	How recurrence updates should be handled

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

DeleteUnusedInvitationMatrix(Boolean)

Matrix holding information about repeating appointment and participants.

Declaration

public void DeleteUnusedInvitationMatrix(bool allowCheckOnMainBooking = false)

Parameters

Type	Name	Description
Boolean	allowCheckOnMainBooking

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

DeleteWithEmail()

Matrix holding information about repeating appointment and participants.

Declaration

public void DeleteWithEmail()

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

DemandOwnership(AppointmentMatrix.OwnershipIndex)

Demand that the logged in user has the the required ownership requested.
If the required is less than the Ownership, a SoSentryException is thrown.

Declaration

public void DemandOwnership(AppointmentMatrix.OwnershipIndex minimumRequiredOwnership)

Parameters

Type	Name	Description
AppointmentMatrix.OwnershipIndex	minimumRequiredOwnership	The mimimum required ownership index required.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

EmailWasQueued()

Matrix holding information about repeating appointment and participants.

Declaration

public bool EmailWasQueued()

Returns

Type	Description
Boolean

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

GetAllAppointmentRows()

Matrix holding information about repeating appointment and participants.

Declaration

public IEnumerable<AppointmentRow> GetAllAppointmentRows()

Returns

Type	Description
IEnumerable<AppointmentRow>

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

GetDates()

Matrix holding information about repeating appointment and participants.

Declaration

public RecurrenceDate[] GetDates()

Returns

Type	Description
RecurrenceDate[]

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

GetIncludedAppointmentRows()

Matrix holding information about repeating appointment and participants.

Declaration

public IEnumerable<AppointmentRow> GetIncludedAppointmentRows()

Returns

Type	Description
IEnumerable<AppointmentRow>

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

GetMailBodyFromMailBody(TemplateVariables, String, ParticipantInfo)

Matrix holding information about repeating appointment and participants.

Declaration

public string GetMailBodyFromMailBody(TemplateVariables templateVariables, string mailBody, ParticipantInfo participant)

Parameters

Type	Name	Description
TemplateVariables	templateVariables
String	mailBody
ParticipantInfo	participant

Returns

Type	Description
String

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

GetParticipant(Int32, Int32, Int32, Int32, AppointmentStatus, Boolean)

Matrix holding information about repeating appointment and participants.

Declaration

public static ParticipantInfo GetParticipant(int associateId, int personId, int contactId, int emailId, AppointmentStatus appointmentStatus, bool sendEmail)

Parameters

Type	Name	Description
Int32	associateId
Int32	personId
Int32	contactId
Int32	emailId
AppointmentStatus	appointmentStatus
Boolean	sendEmail

Returns

Type	Description
ParticipantInfo

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

GetParticipantFullName(ParticipantInfo)

Matrix holding information about repeating appointment and participants.

Declaration

public string GetParticipantFullName(ParticipantInfo info)

Parameters

Type	Name	Description
ParticipantInfo	info

Returns

Type	Description
String

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

GetParticipants()

Matrix holding information about repeating appointment and participants.

Declaration

public ParticipantInfo[] GetParticipants()

Returns

Type	Description
ParticipantInfo[]

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

GetRemovedAppointmentRows()

Matrix holding information about repeating appointment and participants.

Declaration

public IEnumerable<AppointmentRow> GetRemovedAppointmentRows()

Returns

Type	Description
IEnumerable<AppointmentRow>

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

GetTemplateVariables()

Matrix holding information about repeating appointment and participants.

Declaration

public TemplateVariables GetTemplateVariables()

Returns

Type	Description
TemplateVariables

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

HasOwnership(AppointmentMatrix.OwnershipIndex)

Determine if the logged in user has the the required ownershiprequested.
If the required is the same or larger than the Ownership, true is returned.

Declaration

public bool HasOwnership(AppointmentMatrix.OwnershipIndex minimumRequiredOwnership)

Parameters

Type	Name	Description
AppointmentMatrix.OwnershipIndex	minimumRequiredOwnership	The mimimum required ownership index required.

Returns

Type	Description
Boolean	True if minimumRequiredOwnership is the same or larger than the Ownership.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

HasParticipant(ParticipantInfo)

Matrix holding information about repeating appointment and participants.

Declaration

public bool HasParticipant(ParticipantInfo participant)

Parameters

Type	Name	Description
ParticipantInfo	participant

Returns

Type	Description
Boolean

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

ModifyOnRows(Int32, RecurrenceUpdateMode, AppointmentMatrix.RowModification, AppointmentMatrix.RowModification)

Matrix holding information about repeating appointment and participants.

Declaration

public static void ModifyOnRows(int appointmentId, RecurrenceUpdateMode recurrenceUpdateMode, AppointmentMatrix.RowModification operationOnFirst, AppointmentMatrix.RowModification operationOnConsecutive)

Parameters

Type	Name	Description
Int32	appointmentId
RecurrenceUpdateMode	recurrenceUpdateMode
AppointmentMatrix.RowModification	operationOnFirst
AppointmentMatrix.RowModification	operationOnConsecutive

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Move(DateTime)

Matrix holding information about repeating appointment and participants.

Declaration

public void Move(DateTime newStartTime)

Parameters

Type	Name	Description
DateTime	newStartTime

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Exceptions

Type	Condition
SoIllegalOperationException	Thrown if a participant is trying to move a booking.

OnIdUpdate()

Update related objects with correct id's to make sure that relations are consistent before saving to the database.

Declaration

protected override void OnIdUpdate()

Overrides

NestedPersist.OnIdUpdate()

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

OnPreIdUpdate()

Allow for "fake id's" to be forced upon related objects.

Declaration

protected override void OnPreIdUpdate()

Overrides

NestedPersist.OnPreIdUpdate()

Remarks

In order to figure out which objects taking part of the nested save operation that actually needs to be saved, this method allows for "fake id's" to be forced upon related objects. Upon receiving the "fake id", the objects receiving such an id can determine if they needs to be persisted (e.g. saved) to the database. However, the fake id's forced upon related objects must be set to correct id's in the OnIdUpdate method taking place later in the save operation.

OnPrimaryKeyRequest(PKContainer)

Allow the object to add itself to a collection of requests for primary keys.

Declaration

protected override void OnPrimaryKeyRequest(PKContainer pkContainer)

Parameters

Type	Name	Description
PKContainer	pkContainer	Collection of objects getting a primary key.

Overrides

NestedPersist.OnPrimaryKeyRequest(PKContainer)

Remarks

When implementing this method, add yourself to the collection if you need a new primary key.

OnPrimaryKeyUpdate(PKContainer)

Update primary key.

Declaration

protected override void OnPrimaryKeyUpdate(PKContainer pkContainer)

Parameters

Type	Name	Description
PKContainer	pkContainer	Collection of objects getting a primary key.

Overrides

NestedPersist.OnPrimaryKeyUpdate(PKContainer)

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

OnSave(BatchSave)

Add the object to the collection of objects that are to be saved within the transaction.

Declaration

protected override void OnSave(BatchSave batchSave)

Parameters

Type	Name	Description
BatchSave	batchSave	An object holding all the objects that needs to be persisted.

Overrides

NestedPersist.OnSave(BatchSave)

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

OnSaved(Boolean)

Matrix holding information about repeating appointment and participants.

Declaration

protected override void OnSaved(bool bSucceeded)

Parameters

Type	Name	Description
Boolean	bSucceeded

Overrides

NestedPersist.OnSaved(Boolean)

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Reject(ParticipantInfo, RecurrenceDate, String)

Rejects the appointment for the provided participant at the given date

Declaration

public void Reject(ParticipantInfo participantInfo, RecurrenceDate date, string rejectReason)

Parameters

Type	Name	Description
ParticipantInfo	participantInfo	Participant that rejects the appointment
RecurrenceDate	date	The date of the rejected appointment
String	rejectReason	Text that explains why he/she can not attend

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Reject(ParticipantInfo, String)

Rejects all occurrences of the appointment for the participant. If only one occurrence exist, then only this one is rejected (not a recurring booking appointment)

Declaration

public void Reject(ParticipantInfo participantInfo, string rejectReason)

Parameters

Type	Name	Description
ParticipantInfo	participantInfo	Participant that rejects all occurrences of the appointment
String	rejectReason	Text that explains why he/she can not attend

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Reject(Int32, RecurrenceUpdateMode, String)

Rejects all occurrences of the appointment for the participant. If only one occurrence exist, then only this one is rejected (not a recurring booking appointment). The result of the rejection is saved to the database.

Declaration

public static void Reject(int appointmentId, RecurrenceUpdateMode recurrenceUpdateMode, string rejectReason)

Parameters

Type	Name	Description
Int32	appointmentId	AppointmentId of Invitation or Assignment to be set to rejected.
RecurrenceUpdateMode	recurrenceUpdateMode	How recurrence updates should be handled
String	rejectReason	Text that explains why he/she can not attend

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Reject(String)

Rejects all occurrences for the current appointment. If only one occurrence exist, then only this one is rejected (not a recurring booking appointment)

Declaration

public void Reject(string rejectReason)

Parameters

Type	Name	Description
String	rejectReason	Text that explains why he/she can not attend

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

RejectWithEmailConfirmation(String)

Rejects all occurrences for the current appointment. If only one occurrence exist, then only this one is rejected (not a recurring booking appointment)

Declaration

public void RejectWithEmailConfirmation(string rejectReason)

Parameters

Type	Name	Description
String	rejectReason	Text that explains why he/she can not attend

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

RemoveDate(RecurrenceDate[])

Remove a date from the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.

Declaration

public void RemoveDate(params RecurrenceDate[] dates)

Parameters

Type	Name	Description
RecurrenceDate[]	dates	Date to remove from the repeating appointment.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

RemoveDate(DateTime[])

Remove a date from the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.

Declaration

public void RemoveDate(params DateTime[] dates)

Parameters

Type	Name	Description
DateTime[]	dates	Date to be removed from the repeating appointment.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

RemoveParticipant(ParticipantInfo[])

Used to remove participants from a booking

Declaration

public void RemoveParticipant(params ParticipantInfo[] participants)

Parameters

Type	Name	Description
ParticipantInfo[]	participants	List of ParticipantInfo

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Save()

Matrix holding information about repeating appointment and participants.

Declaration

public override void Save()

Overrides

NestedPersist.Save()

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SetDates(RecurrenceDate[])

Set the dates for the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.

Declaration

public void SetDates(params RecurrenceDate[] dates)

Parameters

Type	Name	Description
RecurrenceDate[]	dates	Dates to set on the repeating appointment.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SetInvitationMailBody(String, String, String)

Matrix holding information about repeating appointment and participants.

Declaration

public void SetInvitationMailBody(string emailBody, string subject, string templateLanguage)

Parameters

Type	Name	Description
String	emailBody
String	subject
String	templateLanguage

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SetModifiedAppointmentFields(AppointmentRow)

Matrix holding information about repeating appointment and participants.

Declaration

public void SetModifiedAppointmentFields(AppointmentRow row)

Parameters

Type	Name	Description
AppointmentRow	row

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SetParticipants(ParticipantInfo[])

Matrix holding information about repeating appointment and participants.

Declaration

public void SetParticipants(params ParticipantInfo[] participants)

Parameters

Type	Name	Description
ParticipantInfo[]	participants

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SetSeen()

Sets an appointment Invitation or Assignment to seen.

Declaration

public void SetSeen()

Remarks

Set Seen (Booking or Assignment) or MovedSeen (Booking) depending on the previous status of the Appointment

SetSeen(Int32, RecurrenceUpdateMode)

Sets an appointment Invitation or Assignment to seen and save it to the database.

Declaration

public static void SetSeen(int appointmentId, RecurrenceUpdateMode recurrenceUpdateMode)

Parameters

Type	Name	Description
Int32	appointmentId	AppointmentId of Invitation or Assignment to be set to seen.
RecurrenceUpdateMode	recurrenceUpdateMode	How recurrence updates should be handled

Remarks

Set Seen (Booking or Assignment) or MovedSeen (Booking) depending on the previous status of the Appointment

SetSendMailToParticipants(Boolean)

Set if e-mails are going to be sent to participants that are marked receive mails, using default e-mail options for the logged in user.

Declaration

public void SetSendMailToParticipants(bool sendEmailToParticipants)

Parameters

Type	Name	Description
Boolean	sendEmailToParticipants	True if e-mails are going to be sent to participants that are marked receive mails.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SetSendMailToParticipants(Boolean, Boolean)

Matrix holding information about repeating appointment and participants.

Declaration

public void SetSendMailToParticipants(bool sendEmailToParticipants, bool setupConnections)

Parameters

Type	Name	Description
Boolean	sendEmailToParticipants
Boolean	setupConnections

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SetSendMailToParticipants(Boolean, String, String, String, Boolean, String, String, String, Boolean, String)

Set if e-mails are going to be sent to participants that are marked receive mails, with provided mail server options.

Declaration

public void SetSendMailToParticipants(bool sendEmailToParticipants, string imapServer, string imapUser, string imapPassword, bool imapSSL, string smtpServer, string smtpUser, string smtpPassword, bool smtpSSL, string sentFolder)

Parameters

Type	Name	Description
Boolean	sendEmailToParticipants	True if e-mails are going to be sent to participants that are marked receive mails.
String	imapServer	Name/IP with optional port (i.e. server:port)of the IMAP server for storing e-mail in the sent items folder.
String	imapUser	User-name to use when authenticating against the IMAP server for storing e-mail in the sent items folder.
String	imapPassword	Password to use when authenticating against the IMAP server for storing e-mail in the sent items folder.
Boolean	imapSSL	Use secure connection.
String	smtpServer	Name/IP with optional port (i.e. server:port)of the SMTP server for sending e-mail.
String	smtpUser	User-name to use when authenticating against the SMTP server for sending e-mail.
String	smtpPassword	Password to use when authenticating against the SMT server for sending e-mail.
Boolean	smtpSSL	Use secure connection.
String	sentFolder

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

SetSendMailToParticipants(Boolean, String, String, String, String, String, String)

Set if e-mails are going to be sent to participants that are marked receive mails, with provided mail server options.

Declaration

public void SetSendMailToParticipants(bool sendEmailToParticipants, string imapServer, string imapUser, string imapPassword, string smtpServer, string smtpUser, string smtpPassword)

Parameters

Type	Name	Description
Boolean	sendEmailToParticipants	True if e-mails are going to be sent to participants that are marked receive mails.
String	imapServer	Name/IP with optional port (i.e. server:port)of the IMAP server for storing e-mail in the sent items folder.
String	imapUser	User-name to use when authenticating against the IMAP server for storing e-mail in the sent items folder.
String	imapPassword	Password to use when authenticating against the IMAP server for storing e-mail in the sent items folder.
String	smtpServer	Name/IP with optional port (i.e. server:port)of the SMTP server for sending e-mail.
String	smtpUser	User-name to use when authenticating against the SMTP server for sending e-mail.
String	smtpPassword	Name/IP with optional port (i.e. server:port)of the SMTP server for sending e-mail.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

UpdateParticipantInfo(ParticipantInfo)

Updates data regarding mail sending for the participant

Declaration

public void UpdateParticipantInfo(ParticipantInfo participant)

Parameters

Type	Name	Description
ParticipantInfo	participant	Participant to update data for.

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

ValidateDays()

Matrix holding information about repeating appointment and participants.

Declaration

public void ValidateDays()

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

ValidateParticipant(ParticipantInfo[])

Validates the information in the ParticipantInfo given as parameter and fills inn lacking information if needed. I.e assoc_id could both represent an associate or a resource. In the case of an associate, the person_id should also be present. Person that are actually associates are similarly updated with their associate id.

This also ensures consistent processing later on (associates really are processed as associates, etc)

Declaration

public static void ValidateParticipant(params ParticipantInfo[] participants)

Parameters

Type	Name	Description
ParticipantInfo[]	participants

Remarks

A booking consists of a booking master and booking children. Booking master is the master appointment record representing the party (i.e. associate) hosting an event or meeting. Booking children represents invitations and participants to the meeting. We are distinguishing between the current date and dates into the future. The user is prompted with a request to modify the current date and all future dates. Furthermore, we view a repeating booking like a matrix, where participants are represented by columns and repetitions (dates) are represented by rows. When accessing data like a matrix, we use x for the x dimension of the matrix and y for the y dimension. Hence; matrix[x,y] would result to matrix[participant, date].

    | M P P |
    | B C C |
    | B C C |
Where:
M - Master booking for the appointment used to instantiate the matrix.
P - Participant of in the meeting used to instantiate the matrix.
B - Master booking for appointments ahead in the series of repeating bookings.
C - Child appointment records representing participation in appointments ahead in the series of repeating bookings.</code></pre>


The B and C records only exists when there are repetitions.  P and C records only exist when the
appointment is a booking (i.e. there are participants).  Related information like description are only held by M and
B records, and the corresponding P and C records only point to this data.  Related data for the M record is
require to display the related information to the user.  Related information to the B records are modified when the corresponding
related information to the M record is modified only if the information is identical.  Hence; B's related information needs
to be checked and potentially modified when modifying M's related information.


Too much data would be loaded if we would load all participants for all repetitions, including related information like text.
Hence; we choose to load what we actually need.  This means that we load the M, P and B records initially.
C records are loaded as required.  If there is a repeating booking with 10 participants and 15 recurrences to the future of the 
appointment record in focus, we load 15 + 10 = 25 appointment records.  We would load 15 x 10 = 150 appointment records if
we were to load the entire matrix.  All these records could, however, be loaded in case of modifying the list of participants or 
recurrences.

Implements

INestedPersist

Extension Methods

EnumUtil.MapEnums<From, To>(From)

Converters.MapEnums<From, To>(From)