Class AppointmentMatrix
Matrix holding information about repeating appointment and participants.
Implements
Inherited Members
Namespace: SuperOffice.CRM.Entities
Assembly: SoDataBase.dll
Syntax
public sealed class AppointmentMatrix : NestedPersist, INestedPersistRemarks
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(int, 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 |
|---|---|---|
| int | 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> _sendNewInvitationsField 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 |
|---|---|
| bool |
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 |
|---|---|
| bool |
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 |
|---|---|
| bool |
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
Gets a value indicating whether this instance is deleted.
Declaration
public override bool IsDeleted { get; }Property Value
| Type | Description |
|---|---|
| bool |
|
Overrides
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 |
|---|---|
| bool |
Overrides
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 |
|---|---|
| bool |
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 |
|---|---|
| bool |
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<bool> |
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 |
|---|---|
| bool |
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(int, 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 |
|---|---|---|
| int | 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(params 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(params 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(params 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(int, RecurrenceUpdateMode)
Deletes appointment if it is cancelled.
Declaration
public static void DeleteCancelled(int appointmentId, RecurrenceUpdateMode recurrenceUpdateMode)Parameters
| Type | Name | Description |
|---|---|---|
| int | 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(bool)
Matrix holding information about repeating appointment and participants.
Declaration
public void DeleteUnusedInvitationMatrix(bool allowCheckOnMainBooking = false)Parameters
| Type | Name | Description |
|---|---|---|
| bool | 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(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 |
|---|---|
| bool |
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.
GetParticipant(int, int, int, int, AppointmentStatus, bool)
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 |
|---|---|---|
| int | associateId | |
| int | personId | |
| int | contactId | |
| int | emailId | |
| AppointmentStatus | appointmentStatus | |
| bool | 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(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 |
|---|---|
| bool | 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 |
|---|---|
| bool |
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(int, RecurrenceUpdateMode, RowModification, 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 |
|---|---|---|
| int | 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
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
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
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
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
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(bool)
Called after the save operation has completed. A boolean value is passed to notify whether or not the save operation succeeded. The complete save operation is rolled back if Save operation failed.
Declaration
protected override void OnSaved(bool bSucceeded)Parameters
| Type | Name | Description |
|---|---|---|
| bool | bSucceeded | True if the save operation succeeded and false if the save operation failed and rolled back. |
Overrides
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(int, 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 |
|---|---|---|
| int | 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(params 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(params 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(params 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()
Save all the contained objects to the database.
Declaration
public override void Save()Overrides
Remarks
Save contained objects to the database:
SetDates(params 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(params 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(int, 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 |
|---|---|---|
| int | 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(bool)
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 |
|---|---|---|
| bool | 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(bool, bool)
Matrix holding information about repeating appointment and participants.
Declaration
public void SetSendMailToParticipants(bool sendEmailToParticipants, bool setupConnections)Parameters
| Type | Name | Description |
|---|---|---|
| bool | sendEmailToParticipants | |
| bool | 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(bool, string, string, string, bool, string, string, string, bool, 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 |
|---|---|---|
| bool | 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. |
| bool | 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. |
| bool | 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(bool, 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 |
|---|---|---|
| bool | 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(params 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.