Class AppointmentMatrix
Matrix holding information about repeating appointment and participants.
Inherited Members
Namespace: SuperOffice.CRM.Entities
Assembly: SoDataBase.BusinessLogic.dll
Syntax
public sealed class AppointmentMatrix : NestedPersist, INestedPersist, IAppointmentMatrixRemarks
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, ICalendarUtility, IAppointmentUtility, IBookingManager, ILogger<AppointmentMatrix>)
Matrix holding information about repeating appointment and participants.
Declaration
public AppointmentMatrix(Appointment appointment, RecurrenceUpdateMode recurrenceUpdateMode, ICalendarUtility calendarUtility, IAppointmentUtility appointmentUtility, IBookingManager bookingManager, ILogger<AppointmentMatrix> logger)Parameters
| Type | Name | Description |
|---|---|---|
| Appointment | appointment | |
| RecurrenceUpdateMode | recurrenceUpdateMode | |
| ICalendarUtility | calendarUtility | |
| IAppointmentUtility | appointmentUtility | |
| IBookingManager | bookingManager | |
| ILogger<AppointmentMatrix> | logger |
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.
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.
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.
SendNewInvitations
Matrix holding information about repeating appointment and participants.
Declaration
public List<ParticipantInfo> SendNewInvitations { get; }Property 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.
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
AcceptAsync(ParticipantInfo, CancellationToken)
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 Task AcceptAsync(ParticipantInfo participantInfo, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| ParticipantInfo | participantInfo | Participant that accepts all occurrences of the appointment |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
AcceptAsync(int, RecurrenceUpdateMode, CancellationToken)
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 Task AcceptAsync(int appointmentId, RecurrenceUpdateMode recurrenceUpdateMode, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| int | appointmentId | AppointmentId of Invitation or Assignment to be set to accepted. |
| RecurrenceUpdateMode | recurrenceUpdateMode | How recurrence updates should be handled |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
AcceptAsync(CancellationToken)
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 Task AcceptAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
AcceptRejectedAppointmentAsync(ParticipantInfo, RecurrenceDate, CancellationToken)
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 Task AcceptRejectedAppointmentAsync(ParticipantInfo participantInfo, RecurrenceDate date, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| ParticipantInfo | participantInfo | Participant that accepts the appointment |
| RecurrenceDate | date | The date of the accepted appointment |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
AcceptRejectedAppointmentAsync(CancellationToken)
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 Task AcceptRejectedAppointmentAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
AcceptWithEmailConfirmationAsync(CancellationToken)
... ... send emails
Declaration
public Task AcceptWithEmailConfirmationAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
AddDateAsync(CancellationToken, params RecurrenceDate[])
Add a date to the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.
Declaration
public Task AddDateAsync(CancellationToken cancellationToken, params RecurrenceDate[] dates)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken | |
| RecurrenceDate[] | dates | Date to add to the repeating appointment. |
Returns
| Type | Description |
|---|---|
| Task |
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.
AddDateAsync(CancellationToken, params DateTime[])
Add a date to the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.
Declaration
public Task AddDateAsync(CancellationToken cancellationToken, params DateTime[] dates)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken | |
| DateTime[] | dates | Date to add to the repeating appointment. |
Returns
| Type | Description |
|---|---|
| Task |
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.
AddParticipantAsync(CancellationToken, params ParticipantInfo[])
Matrix holding information about repeating appointment and participants.
Declaration
public Task AddParticipantAsync(CancellationToken cancellationToken, params ParticipantInfo[] participants)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken | |
| ParticipantInfo[] | participants |
Returns
| Type | Description |
|---|---|
| Task |
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.
AssignToAsync(ParticipantInfo, CancellationToken)
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 Task AssignToAsync(ParticipantInfo participantInfo, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| ParticipantInfo | participantInfo | Participant to assign the booking to (will become the owner) |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
AssignToExternalOrganizerAsync(ParticipantInfo, CancellationToken)
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 Task AssignToExternalOrganizerAsync(ParticipantInfo newOwner, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| ParticipantInfo | newOwner | Participant to assign the booking to (will become the owner) |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
CalculateDaysAsync(CancellationToken)
Calculate the days according the the recurrence pattern described.
Nothing will be performed if RecurrenceUpdateMode is OnlyThis.
Declaration
public Task CalculateDaysAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
CancelAsync(ParticipantInfo, CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public Task CancelAsync(ParticipantInfo participantInfo, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| ParticipantInfo | participantInfo | |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
DeleteAsync()
Delete items in the appointment matrix.
Declaration
public Task DeleteAsync()Returns
| Type | Description |
|---|---|
| Task |
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.
DeleteUnusedInvitationMatrixAsync(bool, CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public Task DeleteUnusedInvitationMatrixAsync(bool allowCheckOnMainBooking = false, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| bool | allowCheckOnMainBooking | |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
DeleteWithEmailAsync(CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public Task DeleteWithEmailAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
GetAllAppointmentRowsAsync(CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public IAsyncEnumerable<AppointmentRow> GetAllAppointmentRowsAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| IAsyncEnumerable<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.
GetIncludedAppointmentRowsAsync(CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public IAsyncEnumerable<AppointmentRow> GetIncludedAppointmentRowsAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| IAsyncEnumerable<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.
GetInnerMatrixAsync(CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public Task<KeyedMatrix<ParticipantInfo, RecurrenceDate, AppointmentRow>> GetInnerMatrixAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task<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.
GetLinksHelperAsync(CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public Task<ActivityLinksHelper> GetLinksHelperAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task<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.
GetMailBodyFromMailBodyAsync(TemplateVariables, string, ParticipantInfo)
Matrix holding information about repeating appointment and participants.
Declaration
public Task<string> GetMailBodyFromMailBodyAsync(TemplateVariables templateVariables, string mailBody, ParticipantInfo participant)Parameters
| Type | Name | Description |
|---|---|---|
| TemplateVariables | templateVariables | |
| string | mailBody | |
| ParticipantInfo | participant |
Returns
| Type | Description |
|---|---|
| Task<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.
GetParticipantFullNameAsync(ParticipantInfo, CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public Task<string> GetParticipantFullNameAsync(ParticipantInfo info, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| ParticipantInfo | info | |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task<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.
GetTemplateVariablesAsync(CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public Task<TemplateVariables> GetTemplateVariablesAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task<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.
MoveAsync(DateTime, CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public Task MoveAsync(DateTime newStartTime, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| DateTime | newStartTime | |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
OnIdUpdateAsync()
Update related objects with correct id's to make sure that relations are consistent before saving to the database.
Declaration
protected override Task OnIdUpdateAsync()Returns
| Type | Description |
|---|---|
| Task |
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.
OnPreIdUpdateAsync()
Allow for "fake id's" to be forced upon related objects.
Declaration
protected override Task OnPreIdUpdateAsync()Returns
| Type | Description |
|---|---|
| Task |
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.
OnPrimaryKeyRequestAsync(PKContainer)
Allow the object to add itself to a collection of requests for primary keys.
Declaration
protected override Task OnPrimaryKeyRequestAsync(PKContainer pkContainer)Parameters
| Type | Name | Description |
|---|---|---|
| PKContainer | pkContainer | Collection of objects getting a primary key. |
Returns
| Type | Description |
|---|---|
| Task |
Overrides
Remarks
When implementing this method, add yourself to the collection if you need a new primary key.
OnPrimaryKeyUpdateAsync(PKContainer)
Update primary key.
Declaration
protected override Task OnPrimaryKeyUpdateAsync(PKContainer pkContainer)Parameters
| Type | Name | Description |
|---|---|---|
| PKContainer | pkContainer | Collection of objects getting a primary key. |
Returns
| Type | Description |
|---|---|
| Task |
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.
OnSaveAsync(BatchSave)
Add the object to the collection of objects that are to be saved within the transaction.
Declaration
protected override Task OnSaveAsync(BatchSave batchSave)Parameters
| Type | Name | Description |
|---|---|---|
| BatchSave | batchSave | An object holding all the objects that needs to be persisted. |
Returns
| Type | Description |
|---|---|
| Task |
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.
OnSavedAsync(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 Task OnSavedAsync(bool bSucceeded)Parameters
| Type | Name | Description |
|---|---|---|
| bool | bSucceeded | True if the save operation succeeded and false if the save operation failed and rolled back. |
Returns
| Type | Description |
|---|---|
| Task |
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.
RejectAsync(ParticipantInfo, RecurrenceDate, string, CancellationToken)
Rejects the appointment for the provided participant at the given date
Declaration
public Task RejectAsync(ParticipantInfo participantInfo, RecurrenceDate date, string rejectReason, CancellationToken cancellationToken = default)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 |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
RejectAsync(ParticipantInfo, string, CancellationToken)
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 Task RejectAsync(ParticipantInfo participantInfo, string rejectReason, CancellationToken cancellationToken = default)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 |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
RejectAsync(string, CancellationToken)
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 Task RejectAsync(string rejectReason, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| string | rejectReason | Text that explains why he/she can not attend |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
RejectWithEmailConfirmationAsync(string, CancellationToken)
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 Task RejectWithEmailConfirmationAsync(string rejectReason, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| string | rejectReason | Text that explains why he/she can not attend |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
RemoveDateAsync(CancellationToken, params RecurrenceDate[])
Add a date to the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.
Declaration
public Task RemoveDateAsync(CancellationToken cancellationToken, params RecurrenceDate[] dates)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken | |
| RecurrenceDate[] | dates | Date to add to the repeating appointment. |
Returns
| Type | Description |
|---|---|
| Task |
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.
RemoveDateAsync(CancellationToken, params DateTime[])
Remove a date from the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.
Declaration
public Task RemoveDateAsync(CancellationToken cancellationToken, params DateTime[] dates)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken | |
| DateTime[] | dates | Date to remove from the repeating appointment. |
Returns
| Type | Description |
|---|---|
| Task |
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.
RemoveParticipantAsync(CancellationToken, params ParticipantInfo[])
Used to remove participants from a booking
Declaration
public Task RemoveParticipantAsync(CancellationToken cancellationToken, params ParticipantInfo[] participants)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken | |
| ParticipantInfo[] | participants | List of ParticipantInfo |
Returns
| Type | Description |
|---|---|
| Task |
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.
SaveAsync()
Save all the contained objects to the database.
Declaration
public override Task SaveAsync()Returns
| Type | Description |
|---|---|
| Task |
Overrides
Remarks
Save contained objects to the database:
SetDatesAsync(CancellationToken, params RecurrenceDate[])
Set the dates for the repeating appointment. Nothing will be performed if RecurrenceUpdateMode is OnlyThis.
Declaration
public Task SetDatesAsync(CancellationToken cancellationToken, params RecurrenceDate[] dates)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken | |
| RecurrenceDate[] | dates | Dates to set on the repeating appointment. |
Returns
| Type | Description |
|---|---|
| Task |
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.
SetParticipantsAsync(CancellationToken, params ParticipantInfo[])
Matrix holding information about repeating appointment and participants.
Declaration
public Task SetParticipantsAsync(CancellationToken cancellationToken, params ParticipantInfo[] participants)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken | |
| ParticipantInfo[] | participants |
Returns
| Type | Description |
|---|---|
| Task |
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.
SetSeenAsync(CancellationToken)
Sets an appointment Invitation or Assignment to seen.
Declaration
public Task SetSeenAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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, 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.
SetSendMailToParticipantsAsync(bool, bool)
Matrix holding information about repeating appointment and participants.
Declaration
public Task SetSendMailToParticipantsAsync(bool sendEmailToParticipants, bool setupConnections)Parameters
| Type | Name | Description |
|---|---|---|
| bool | sendEmailToParticipants | |
| bool | setupConnections |
Returns
| Type | Description |
|---|---|
| Task |
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.
UpdateParticipantInfoAsync(ParticipantInfo, CancellationToken)
Updates data regarding mail sending for the participant
Declaration
public Task UpdateParticipantInfoAsync(ParticipantInfo participant, CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| ParticipantInfo | participant | Participant to update data for. |
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.
ValidateDaysAsync(CancellationToken)
Matrix holding information about repeating appointment and participants.
Declaration
public Task ValidateDaysAsync(CancellationToken cancellationToken = default)Parameters
| Type | Name | Description |
|---|---|---|
| CancellationToken | cancellationToken |
Returns
| Type | Description |
|---|---|
| Task |
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.