CONREGO Terminology

The documents and CONREGO application contain terms that may require further clarifications. The most important ones have been defined below.

Organisers of events are quite frequently forced to divide participants into categories. Such divisions are made, if different terms and conditions of participating in a given event are offered to various participants. Such a division is referred to as a type of representation, during the registration process.

Example: A given event is attended by students (who pay a fee of 500 EUR), members of an organisation (who pay a fee of 250 EUR), and journalists (they register free of charge).
The easiest way of handling such an event is to create three (3) types of participation, in order to:
- Assign different rates for participation to each participant;
- Hide the section with invoice information in the registration form intended for journalists;
- Hide the “Edition” field for students and members of an organisation, since it will only be visible to journalists, for accreditation purposes.

Types of participation are configured using the Advanced System Configuration > Event settings section.

Each individual registration listed in the application database has a status assigned, which quite precisely defines its condition.
  • Initiated - This status means that the participant has started the registration process but they have not completed it, intentionally or unintentionally. Registrations with this status are created, when the participant moves from the first step of the registration process (Registration Form) to the next one. Depending on the parameters of the registration process, it will be Agenda, Accommodation, or Summary. Thanks to the data saved in the system, the organiser may communicate with the participant to provide support.
    By default, this status does not lock free seats among the available limits in conference rooms or accommodation sites, nor does it eliminate the possibility of using the same email address of the participant, when restarting the registration process.
  • Complete -This is a final status of a free-of-charge registration that has been made correctly. If the participant has completed registration, they have also received an email message that confirms it (Stage VI).
    By default, this status locks free seats among the available limits in conference rooms or accommodation sites, and eliminates the possibility of using the same email address of the participant, when restarting the registration process.
  • Unpaid - This is a final status of:
    - A paid registration completed correctly, provided that the participant has selected payment by regular bank transfer;
    - A paid registration completed correctly, provided that the participant has selected electronic payment based on integrating with one of the payment service providers, but transaction was not completed correctly or is still awaiting authorisation.
    If the status of registration is “unpaid”, then the participant should receive an email message that confirms registration (Step VI) and contains a proforma invoice attached.
    By default, this status locks free seats among the available limits in conference rooms or accommodation sites, and it eliminates the possibility of using the same email address of the participant, when restarting the registration process.
  • Paid -It is a final status of a paid registration completed correctly by the participant, provided that the participant has selected electronic payment based on integrating with one of the payment service providers, and transaction was finalized.
    By default, this status locks free seats among the available limits in conference rooms or accommodation sites, and it eliminates the possibility of using the same email address of the participant, when restarting the registration process.
  • Cancelled - This status is assigned by the administrator to all registrations sent by the people that decided not to participate.
    By default, this status does not lock free seats among the available limits in conference rooms or accommodation sites, nor does it eliminate the possibility of using the same email address of the participant, when restarting the registration process.
  • Abandoned - This status means that the participant has initiated registration and then abandoned it intentionally, by moving to a different tab on the website, during the registration process, which resulted in session cookies expiring. We assume that the process was abandoned intentionally, since the participant sees an appropriate warning on the screen and must that they actually want to stop the registration process, before it happens.
    By default, this status does not lock free seats among the available limits in conference rooms or accommodation sites, nor does it eliminate the possibility of using the same email address of the participant, when restarting the registration process.
  • Pending - It is a working status assigned by the administrator, in order to mark the participants that are undecided or wait for a decision regarding their participation in an event, made by the organiser.
    By default, this status does not lock free seats among the available limits in conference rooms or accommodation sites, nor does it eliminate the possibility of using the same email address of the participant, when restarting the registration process.
  • Imported - It is a temporary status assigned to registrations that are imported into the system based on XLS files.
    By default, this status does not lock free seats among the available limits in conference rooms or accommodation sites, nor does it eliminate the possibility of using the same email address of the participant, when restarting the registration process.

A group of participants, a group of registrations, or a group of questionnaires is a collection of applications created over a given period of time, saved under a particular name, and which contains entries valid for the time the group was created.
Example: If we create a group of registrations that today meet the criterion of unpaid, and save it under the name "UNPAID as on 20th May", then tomorrow those people will still belong to the "UNPAID as on 20th May", although the status of some participants has changed from “unpaid” to “paid”.

The mechanism behind creating groups of participants has been defined in the Reports > Participants section.

The CONREGO system uses data fields that are considered basic, in many of its modules. The following fields are categorised as basic:

  • name,
  • surname,
  • email,
  • phone,
  • organisation,
  • payment_method,
  • password.

Various application modules refer to those fields in many different situations, for example when presenting data in the Reports > Participants table. However, there may be situations when you decide, for various reasons, to start creating a registration form for participants of an event from scratch, thus assigning different ID tags to new fields (e.g. using a tag “first_name”, instead of “name”). The system will not automatically detect that the “name” field has been removed and replaced with a new field, so we must help the system a little. In such a situation, we can use a function included in the Registration form section, which enables the so-called mapping of fields. It consists in linking configurable fields with basic fields (see the list above) in the database, in order to make it possible for the system to treat any of the fields marked by you, according to your intentions, e.g. as an email, and then continue working based on that selection, by sending confirmations of registration and mailings.

HTML tags (also referred to as markers), are used in more advanced formatting of texts on event pages and in mailings. HTML tags are placed in angle brackets - <>and they can also contain attributes that modify a given tag, in addition to the tag itself. The majority of tags must be closed with a closing tag, in order to operate correctly. The closing tag has the same name but it is preceded with the “/” character – the closing tag never has any attributes, even if an opening tag had its own attributes. Therefore, most tags will look like this:
<tag attribute="value">content</tag>.

An example of a functioning tag:

<span style="color:blue;">This text will be displayed in blue</span>

The content of the tag will look like this:
This text will be displayed in blue

System tag System tag is a string of characters closed in square brackets [ ], which loads a value resulting from registration parameters for a particular participant.
System tags are usually loaded using a panel available during the editing of:
- Step IV and Step V of the registration process;
- Email messages with confirmation of registration orconfirmation of transaction,
- Page with a thank-you message for sending an application via the Questionnaires module;
- E-mail messages sent via the Questionnaires module;
- PDF document template using the PDF Creator module.

System tags available in the current version of the CONREGO application include:

  • [registration_number] - It generates a registration No. that is assigned when the participant has completed the registration process;
  • [registration_agenda] - It embeds a table containing an agenda of events selected by the user, during the second step of the registration process;
  • [registration_hotel] - It embeds a table containing information about booking a hotel and a room, during the third step of the registration process;
  • [registration_total_price] - It embeds an amount that constitutes the sum of all costs regarding participant’s registration (based on agenda and price-list options);
  • [qrcode] - It creates and embeds graphics of a QR code assigned to participant’s registration;
  • [barcode] - It creates and embeds graphics of a bar code assigned to participant’s registration.

Registration tag (also referred to as registration field tag) is a string of characters closed in square brackets [ ], which loads a value of one of the fields in the registration form filled in by the participant (it is usually available during the first step of the registration process).

Example:
You wish to use the Summary to present the data the participant entered at the previous step, so that they can verify its correctness. For example, such data could include: name, surname, company, position, email address, and telephone number. The tags used to load those fields will contain detailed ID notation for a given field in the database, i.e.:
[first_name] [surname] [organization] [position] [email] [phone]

As a result, you will have the following notation in the summary content:
John Doe CONREGO event manager support@conrego.com +48733666922

It does not look good, though, since our intention, when formatting the text, should be to obtain the following notation:

Name: [first_name]
Surname: [surname]
Organisation: [organization]
Position: [position]
E-mail address: [email]
Phone number: [phone]

Practically speaking, it is not required to fill in all the fields in the registration form. Taking the afore-mentioned content layout as an example, leaving the [phone] field blank would result in embedding the Phone number: label for no purpose. Since such omissions do not look good, we need to employ a modifier. The most commonly used modifier is "|withlabel".
It contains a condition that:
- Shows or hides content of an entire row, if a field in the registration form has not been filled in;
- Adds a label in a given language version;
- Adds a
tag at the end of each character string created by each tag.

Thanks to the modifier, the code will look like this:
[name|withlabel] [surname|withlabel] [company|withlabel] [position|withlabel] [email|withlabel] [telephone number|withlabel]

...and the following content will be generated:

Name: John
Surname: Doe
E-mail address: support@conrego.com
Phone number: +48733666922

Questionnaire field tag is a string of characters closed in square brackets [ ], which loads a value of one of the fields filled in by the participant, in the registration form. Questionnaire field tags function, according to the same principle as registration tags.

Additional tag is a string of characters closed in square brackets [ ] that loads content generated based on PHP code.

Example: the caretaker-agreement.php file contains the following code:

<? if($oReg->wiek=='0-18'){?>
    Your age indicates that your parents/legal guardian must give consent for your participation in the conference.
<? } ?>

The afore-mentioned code conditions the displaying of content, depending on the value of the age field that was previously configured in the registration form. Therefore, using this tag may load the following elements of content:
- One of the registration process steps;
- An email message that confirms completion of registration of transaction;
- Conditional content defined in the tag code.

Additional tags make the registration process and resulting communication exceptionally flexible. Additional tags are most frequently used in those situations that require content to depend on whether participation is related to payments. Another purpose for which they are often applied is the presence of diversified content that depends on a payment method selected by the participant. For example, it is not advisable to inform the participant that has already chosen to pay by regular bank transfer about the method of paying by credit card.

You must remember that it requires experience in PHP code or assistance of a software developer, if you intend to use additional tags. Each tag must be saved as a PHP file in the /application/classes/views/tags/ directory and activated in the last panel of the Advanced System Configuration - Registration process section.

PDF attachement tag PDF attachment tag is a string of characters closed in square brackets [ ] that results in attaching one of the PDF documents created with the PDF Creator module to a delivered email message. First, the application creates a PDF file for a given participant (the document will be customised on the go, since their individual template may contain content based on other system tags), and then attaches it to the email message sent during the course of Step VI, or together with Confirmation of transaction, or using the Communication.

There are two types of Invitation codes:
1. Enabling the participant to register for selected types of participation that are configured in the Advanced System Configuration > Event Settings section.
2. Enabling individual, one-time registration that had already been imported into the system and can be used by a single participant.

Individual invitation code (invicode) is a string of characters that can be assigned to each registration in the CONREGO system. The string of characters is imported together with email addresses, or added to registrations entered manually by the administrator, if required. The final goal is to make it possible for the participant to unlock registering, according to certain conditions.

Example:
Imagine that you want to send an invitation to register to 2,000 people, but some of them will register for free, while others will have to pay to participate. Thanks to the invitation code management feature, you can create two databases for importing. The first database will include people with free-of-charge participation, while the other one people that pay to participate.
a) Add invitation codes to the first column of the imported XLS file;
b) When importing, select the type of participation that will be assigned to the imported records;
c) Create a link with the href="domain.com/welcome/invite/[invicode]” parameter to be included in mailing with invitation;
d) Hide the field that enables selecting the type of participation, in the registration form (IMPORTANT: use the conrego.css file for that purpose);
e) Invitations sent by the system will enable participants to open the registration form with already filled-in imported data (optionally), but it will not be possible to change the type of participation.

Checkbox is a square-shaped selection button. If the square is filled with a tag in the form of a v , it means that the option which label is visible next to the ticked checkbox has been selected..

Example:

Winter Spring Summer Autumn

Radio button is an option selection button. If one radio button of the buttons available in the registration form block has been selected, all others will be automatically disabled. If a radio button-type selector is marked with a black dot, it means that the option it refers to has been selected.

Example:

Winter Spring Summer Autumn

Pole select field is a drop-down list that enables selecting one option only. Remember to enter a default value, i.e. one that is displayed before selecting any other option (it is usually “- select -”), when entering values for successive options.

Example:

Textarea Text area is a field in the registration form that enables entering longer content that the standard text field. For example, it can be used to enter abstracts of scientific papers, justifications to participate in an event, etc.

Example:

Abstract is a synopsis of a book or a scientific article, which contains basic information about its topic and a list of key words separated by commas. The full definition of abstract is available on the following website: https://en.wikipedia.org/wiki/Abstract_(summary).

It is a two-dimensional code (in the form of a square) that can contain up to 984 Polish characters. Each participant registering in the CONREGO system is assigned an individual QR code that can be used when checking at the reception desk or during access control. Additionally, QR codes can be used to post links to websites (e.g. a website with event agenda). Participants can scan such codes with their smartphones or tablet computers, provided that they have installed appropriate software.

It is a one-dimensional code (in the form of vertical bars) of much less information capacity than the QR code. Each participant registering in the CONREGO system is assigned both an individual bar code and a QR code. QR code readers are also capable of reading bar codes, but it is not possible, if using cheaper bar code readers.

CRON is a software utility that acts as a job scheduler, which activates other programs/scripts to run periodically. The CONREGO system uses it to perform email blasts. CRON is set in the server that supports the system. Contact a hosting company that supports your server, if you’re having problems with setting this application.

CRON configuration will surely look different on each individual server. Nonetheless, most systems enable using the following standard parameters:

Command / Script links -dump http://domain.com/cron/do_cron/access_key(2)
Example: links -dump http://domain.com/cron/do_cron/438219
File for messages /dev/null
File for errors /dev/null

Stay up-to-date with news and subscribe to CONREGO Newsletter

I hereby declare that I have read the Terms and Conditions regarding using the Newsletter published on conrego.com and have accepted them.
This website uses Cookies to collect data about our visitors for marketing and orders processing purposes. By continuing to browse the site, you are agreeing to our use of cookies.
Accept