...
...
Objective
This page explains on the topic of how to create a new event on Rapla and explains further on different scenarios.
Complexity
| Status | ||||
|---|---|---|---|---|
|
Page Contents
| Table of Contents | ||||
|---|---|---|---|---|
|
...
Objective
Once you have read this article you will know how to create a new event on Rapla.
Assumptions
You have already read
the articleYou have already installed Rapla
. Refer toas per Accessing Rapla
You have a valid Rapla user account
Key terms and concepts
| Info |
|---|
...
Note |
...
Both admin and non-admin user privileges are able to create events |
...
Key terms and concepts
Identify, and describe or explain the terms and concepts that need to be understood in order to carry out the tasks explained in this article.
Use tables, or bullet or numbered lists when it is appropriate.
Implications
...
in Rapla. Only admin users can edit events created by other users. |
| Note |
|---|
Be advisedThe user needs to make sure they are not highlighting anything on the left-hand side of the menu bar. This can cause Rapla to think that you are creating any events against that resource. Hence, you might see a warning message |
...
. |
Explanation of Standard Event Types
Sessions (Lecture, tutorials, etc.) - most popular one, used for synchronising with Paradigm
Meetings
Exams
Student bookings
Auditions
Explanation of Standard Event Attributes (Fields)
Take the most popular event type - Session as an example, please see the following common attributes:
Field Name | Description |
|---|---|
Unit Name | The name of the unit offers by the Institution. The same one matches the record in Paradigm. |
Unit Code | The unit code offers by the Institution. The same one matches the record in Paradigm. |
Session Type | Subject to each institution to define their session type (e.g. class, tutorial, lecture) |
Campus | Subject to each institution to define their campus (e.g. Melbourne, Sydney) |
Minimum Participants | The minimum number of participants for running the session (e.g. 5) |
Maximum Participants | The maximum number of participants for running the session |
Faculty/Department | Subject to each institution to define their faculty/department (e.g. Faculty of Art) |
Session Group ID (Group number) | A group of sessions from which a selection is made during the enrolment (aka. it is an enrolment choice). |
Session Seq ID (Class number) | A set of students who attend the same session together under one scheduled unit (Lecture). |
Session Group and Session Class
| Info |
|---|
NoteIt is up to each provider or institution to allocate an appropriate ID when populating the Session Class or Session Group fields. |
| Note |
|---|
Be AdvisedCarefully consider the following definitions to determine if your institution requires the use of the session group and class fields. If these features are not required then it is appropriate to leave the field(s) in blank. |
Session Class (or session sequence ID)
| Warning |
|---|
WarningParadigm makes an important assumption that ALL sessions where the Session Class is not set are compulsory enrolments. |
The Session Class is used to limit what a user may select when enrolling into sessions. The restrictions work in two layers
Selecting a Session Class will also select all other sessions that share the same Session Class value
When a Session Group AND a Session Class are both set, then the user must select one and only one session, from each group
The use of Session Class simplifies the process of selecting a suitable, non-clashing set of sessions. It is especially useful when there is a need to define a pairing or set of sessions consisting of multiple Session Groups where you want to enforce predefined session enrolment combinations.
We recommend starting the Session Class value with the digit 1 increment it by 1 for each new Session Class.
Session Group
| Info |
|---|
NoteWhen the Session Class is set but the Session Group is blank, then the Paradigm will assume there is an implicit Session Group value of 1. |
The Session Group is used when there are multiple Session Types associated with the same Scheduled Unit. Assigning a Session Group will visually group the sessions when viewed from within Paradigm. When used together with Session Class it is possible to prevent users from enrolling into more than one session from each defined Session Group. Examples of common session group types include lectures, tutorials and and workshops.
We recommend starting the Session Group value with the digit 1 increment it by 1 for each new Session Group.
Workflow
How to create a single event on Rapla
You will use the left mouse (drag and drop) to mark the time period for the specific appointment you want to. The marked rows are highlighted in pale blue (
Asas below).
...
2. Right click a new context menu appears, then select the suitable event type, ranging from a session, generic event, meeting or student booking. In the below instance, it is an example of creating a new Event (Paradigm Session).
...
Note there are three sections:
The upper section: confirm the Event type you want to create, fill out these fields that are critical for integration between Rapla and Paradigm: Unit Codes (E.g. FIT9130), Unit Name, Campus (if applicable), Delivery mode, Department.
...
The middle section shows the detail of the appointment: you will need to fill out the start and end date, select whether it is a single event or recurring one. You can even exclude public holidays or semester breaks if applicable (Refer to below scenario 2).
...
The bottom section shows the resources you want to allocate to, add the resources from the left hand side to the right section by either double clicking or click on the resource and go to click Add button
...
3. Click on Save button.
| Expand | ||
|---|---|---|
| ||
This is one of magics that Rapla will show you next... While you follow the above steps of creating events/appointment, when you reach to the bottom section - resource allocations. Rapla tells you the available resource by |
having a green icon |
at front. The red cross icon means the resource has been taken for another event. So you should try to avoid |
allocating it again |
. |
 |
| Expand | ||
|---|---|---|
|
...
| |
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
...
 6. You have now created a repeating event with one or more exception(s). |
| Expand | ||
|---|---|---|
|
...
| |
 4. At Resource Allocation section, you need to assign resources (e.g. staff, rooms) to each appointment individually. 5. Currently all resources have been set to every appoint, you can change it by click on 'Every appointment'. It opens up more options to each appointment. 6. Resources have been color coded and allocated to Appointment 1 and Appointment 2.  |
Further Reading
| Filter by label (Content by label) | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Related Pages
| Related Labels |
|---|