Skip to main content

“Participants”

This provider name is implemented by the class <see cref=“T:SuperOffice.CRM.ArchiveLists.ParticipantsProvider”>SuperOffice.CRM.ArchiveLists.ParticipantsProvider</see> inside NetServer’s SODatabase assembly. Archive list provider for the participants list of a booking (multi-person appointment) This provider, like the <see cref=“T:SuperOffice.CRM.ArchiveLists.LinksProvider” />, offers two alternative ways of accessing the data. For existing appointments, the appointment_id is used as search criterion. This will retrieve all participants in this appointment, regardless of whether the given appointment is the mother or one of the slaves. For appointments under construction, where the data have not yet been saved to the database, the caller must specify all data through the use of restrictions - some of which are then used for information, and some as keys to fetch actual person or associate/resource records from the database. <list type=“table”><listheader><term>Restriction</term><description>Meaning</description></listheader><item><term>appointmentRestrictionId</term><description>Single appointment id, using the = operator. This restriction is used on its own for fetching information from existing appointment records. The id may be of any appointment in the booking, and all participants will be fetched (limited by entity selection).</description></item><item><term>associateRestrictionId</term><description>Operator: IN, Value: array of associate id’s. These will be returned as participants of type associate, if the associate entity has been selected.</description></item><item><term>groupRestrictionId</term><description>Operator: =, Value: group id. The group will be translated into associate id’s, and these will be returned as participants of type associate, if the associate entity has been selected. This is an alternative to specifying the associates one by one and cannot be used together with the associateRestrictionId.</description></item><item><term>externalPersonRestrictionId</term><description>Operator: IN, Value: array of of person id’s. These will be returned as participants of type external person, if the externalPerson entity has been selected. <i>Note: Persons who are actually associates</i> will be detected as such, and be returned as associates.</description></item><item><term>resourceRestrictionId</term><description>Operator: IN, Value: array of of associate id’s. These will be returned as participants of type resource, if the resource entity has been selected.</description></item><item><term>personEmailsInformation</term><description>Operator: IN, Value: array of of person id’s. This restriction is optionally used together with externalPersonRestrictionId, and specifies which of the persons should have an email icon set.</description></item><item><term>associateEmailsInformation</term><description>Operator: IN, Value: array of of associate id’s. This restriction is optionally used together with associatePersonRestrictionId, and specifies which of the associates should have an email icon set. Note that resources do not get invitation emails, so there is no corresponding resourceEmailsInformation restriction.</description></item><item><term>startTimeInformation</term><description>Datetime of appointment start, needed when fetching data through the explicit restrictions (not appointmentRestrictionId) and if you want collision detection.</description></item><item><term>endTimeInformation</term><description>Datetime of appointment end, needed when fetching data through the explicit restrictions (not appointmentRestrictionId) and if you want collision detection.</description></item><item><term>ownerAssociateIdInformation</term><description>Operator: =, value: associate id. This is the Id of associate who is the owner of the whole booking. If this is not given, and appointmentRestrictionId is given, the system will look up the associate of the master booking record (mother_id = appointment_id) and use that as the owner. If ownerAssociateIdInformation is given, it overrides (disables) this lookup. If neither are given, then there is no owner associate. The owner associate always comes at the top of the list, and has the ‘owner’ row style hint.</description></item><item><term>inhibitConflictsInformation</term><description>Operator: =, value: boolean. If you provide either an appointmentRestrictionId or startTime/EndTime, then conflicts will be detected. However, if the appointment is of type Free, then no conflict detetction will occur. To force ‘free’ behaviour on an under-construction appointment that does not have an appointment id, or on an appointment that is being changed, include this restriction with the value true. That will turn off conflict detection.</description></item></list> If you do not use the appointmentRestrictionId, you can instead specify external persons by a list (use the IN operator) of externalPersonRestrictionId, internal associates through a list of associateRestrictionId, and resources through resourceRestrictionId. All three restrictions can be given simultaneously, with an implied OR operator. In this case no appointment records are required or fetched. Conflict detection is provided if the status column is requested. For non-saved data, this also requires the presence of startTimeInformation and endTimeInformation restrictions (dates in InvariantCulture format), so that the conflicts may be calculated. Finally, the email status (should emails be sent for invitations and changes) is read from the database if the appointmentRestrictionId is used; if explicit person or associate restrictions are used, then email status information must be passed in through the associateEmailsInformation and personEmailsInformation restrictions. The value of each restriction is a list of associate resp. person id’s who have the email flag set. If all this sounds complex - well, it is. Being the tolerant sort, the provider will accept both associates and resources in each of associateRestrictionId and resourceRestrictionId, and internally sort out which is which. Similarly, if any of the person id’s you happen to pass in through the externalPersonRestrictionId are actually associates, then that too will be sorted out.

Supported Entities

Supported Columns

Supported Columns (cont.)

Sample

See also: <see cref=“T:SuperOffice.CRM.Services.IArchiveAgent”>IArchiveAgent</see>.