Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

2 Managing Plugins

Conn Warwicker edited this page Jul 25, 2018 · 9 revisions

Plugins appear on the student's ELBP as a series of boxes, which contain summary information and can be expanded to see more detailed information and edit them.

To edit an installed plugin, click on its "Settings" link in the list of plugins and you should be taken to its configuration page.

Every plugin has the same core settings at the top:

  • Enable/Disable
  • Plugin Title
  • Header/Font Colour for the box (Student Profile does not have this setting)
  • Email Alerts (If the plugin supports them)

Now let's look at the plugin-specific settings.

2.1 Core Plugins

All core plugins can be installed from the Plugins Configuration page and selecting "Core Plugins" from the drop-down in the "Install New Plugin" section at the top.

2.1.1 Student Profile

The Student Profile plugin sits at the top of the ELBP and displays information about the student as well as a Student Information area which the students can fill out like a kind of mini profile. Unlike all other plugins, it does not appear as a box, and cannot be added to a plugin group.

Main : Extras

The Extras section of the Main tab lets you choose whether some extra bits of information should be displayed on the profile.

Profile Fields

The Profile Fields tab allows you to add new fields that you want to be displayed on the students’ profiles. For example:

  • Full name
  • Address
  • Contact Number
  • Emergency Contact
  • Emergency Contact Number
  • Date of Birth
  • Etc…

Each field can have a different Confidentiality level, to define who can and cannot see that field. For more information on Confidentiality levels, hover over the little help icon.

Here you can also choose whether or not the profile can be edited, as you may just want to use it to display data rather than have it changed by anyone.

MIS

The “MIS” tab allows us to choose whether or not this plugin uses the Moodle database, or if it draws data out of an external database, most probably your MIS/SIS system.

If you want to use the Moodle database you do not have to do anything on this tab, you can ignore it.

If you do want to draw data out of another system, the first thing you will need to do is to go back to the ELBP Configuration page, go to the MIS tab and create a new MIS connection (unless you have already created one you want to use) and assign it to the StudentProfile plugin.

Once you have assigned a valid MIS connection to the StudentProfile plugin, come back to the MIS settings and changed “Moodle Database” to “MIS” and save the settings, this will then load up additional MIS settings so that we can map our Plugin to the MIS data.

We should now see the next setting is “MIS Table/View Name”, here we need to define the name of the table or view we are going to be querying.

Next we can define any SQL we want to be executed after connecting, for example setting a particular charset if you need to. This is optional.

Next we need to choose how we are going to be looking up data when we load up a student’s ELBP. Are we going to be looking for their “username” or their “idnumber”?

Next we have the “MIS Field Mapping” section, where we can map our fields to those fields/columns in our external data source.

Firstly we have “ID”, this should contain a unique ID field in the defined table/view.

Then we have “Username”, this should contain either the student’s “username” or “idnumber” as defined in previous setting. Then we have a mapping for each of the Profile Fields we set up.

For this example I have used the Profile Fields: “Full Name”, “Address” and “Date of Birth”.

So for the sake of example, let us assume I am connecting to another MySQL database that stores our MIS information. And the table I want to query is this:

The settings I would put into this page would be:

Then I would save these settings and run an MIS test at the bottom of the page.

If I were to then enter “dduck” as my username in the MIS test, it will run a query based on all the settings we have input to try and find all the information about a user with the username “dduck”, which for me would return:

Anon Object
(
[Full Name] => Daffy Duck
[Address] => 789 Some Road
Some Place
Some County
AB1 2CD
[Date of Birth] => 1926-01-13
)

However, the Date of Birth is not in a particular nice format, so let’s change that. This is where it becomes a little more complex and we have to start using the Field Functions and Aliases. You also have to know some SQL.

How this would work differs greatly depending on the type of database we are connecting to, however for this example we are using MySQL. So basically what we want to do is rather than just return the value in the “dob” field, we want to run it through a function first instead. In MySQL to convert a date into a different format we would use the DATE_FORMAT() function. For example if we do this in our MySQL database we can see how we can change the format:

So what we will do here is for the “Date of Birth” field, we will add that function call into the “Field Function” box, and then add an alias so we get both the original and the new versions:

Now let’s save those settings and run our MIS test again and see what results we get:

Anon Object
(
[Full Name] => Daffy Duck
[Address] => 789 Some Road
Some Place
Some County
AB1 2CD
[Date of Birth] => 13/01/1926
)

So you can see now we have the Date of Birth in a different format.

So if I now went to the ELBP of a user with the username of “dduck”, this is the data it would retrieve from the MIS system.

Also on this page we have an MIS Contact section. If we are allowing students to edit their profiles, but we are also using an MIS connection, we do not really want them to be able to directly UPDATE the MIS database, as this may cause problems. So instead what we can do is specify a user to be emailed with the details whenever a student updates their profile information, so they can then amend the MIS database.

Once you have finished setting up the Student Profile and made sure it is enabled, you should be able to see it has appeared on the ELBP when you view a student.

2.1.2 Targets

The Targets plugin is used so that students can have individual targets set for them to achieve.

Main

As well as the core options, under the main tab we have automation settings, which allow the target status to be set to achieved when the progress is changed to 100% and vice-versa, and a setting to integrate targets into the student calendars.

Settings

The “Settings” tab allows us to customise our Target Statuses, Attributes and Instructions. On installation of the plugin it should have created some default values for you, which you may wish to keep or you may wish to change.

The Target statuses allow you to define the status of each target, by default these options are “To Be Achieved”, “Partially Achieved”, “Achieved” and “Withdrawn”. There are some check boxes next to each status as well, which allow you to define which of these statuses should be considered “Achieved/Complete/Met”, which of these statuses should be ignored and won’t be checked for its deadline, nor will it be included in progress reports. And “List in Summary” means that the last 5 targets of this status will be listed on the student’s Target summary on the ELBP.

Attributes are done in the same way across any plugin which uses them, they are pieces of information you want to be stored against a given record (a target in this case). Our default values here should be: “Target Type” and “Target. For more information on plugin attributes, see that section of the wiki.

In the Targets plugin we also have the “Target Hover” setting, which lets us define which of our attributes is our main target content so that we can display it in tooltips from other plugins. By default this will be the “Target” attribute.

Then we have "Target Filter", which lets you filter targets by a particular attribute when viewing the expanded list.

And finally we have Target Instructions which is displayed at the top of the New Target form, as instructions for creating a new Target.

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

Then if you view a student’s ELBP, you should see the Targets plugin is now available.

2.1.3 Tutorials

The Tutorials plugin is used so that Personal Tutors can set Tutorial records for a student, recording what was discussed, any targets that were set, etc…

Main

As well as the core options, you can also choose how many tutorial records to show in the summary list.

Settings

The “Settings” tab allows us to define attributes to be included in Tutorials, so we can record whatever data we want. By default these will be set to: Tutor Comments and Student Comments. For more information on plugin attributes, see that section of the wiki.

Next we have the “Tutorial Hooks” section, which allows us to hook in data from other plugins. Supported hooks for Tutorials: Targets, Attendance (Avg/Total).

For example, if we have no hooks, when we set up a Tutorial it will just be a box for the date, a box for Tutor Comments and a box for Student comments. But if we enable the Hook to the Targets plugin, then we can add Targets specifically to that Tutorial (they will also appear in the Targets plugin box).

Finally we have the “Tutorial Instructions” for when people are setting up new Tutorials.

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

Then if you view a student’s ELBP, you should see the Tutorials plugin is now available.

2.1.4 Attendance

The Attendance plugin is used to display the students Attendance, Punctuality, etc… so that they and any of their tutors can see it.

Settings

The “Settings” tab allows us to customise how our Attendance plugin will work – what types of data it will store (e.g. Attendance, Punctuality, Lateness, Whatever, etc…), what periods of time to store it against (e.g. Term 1, Term 2, Last 7 Days, Last 28 Days, etc…).

The first Settings section lets us choose what courses we want to display Attendance information for. If you do not use Meta/Child courses, then just tick “Both” for this. And also choose which name you want to be displayed for the course.

Next we have the “Record Types” section, where we can define the record types we want to record. By default this will be “Attendance” and “Punctuality”, but you can change them to whatever you want, e.g. “Absent”, “Late”, “Present”, “Lizard”, etc… They should also have a 1 or 2 character short code, which should be unique, e.g. if you have “Attendance” and “Absent”, they should not both have the short code “A”.

Next we have the “Record Periods” section, where we can choose what periods of time we are storing the data against. By default this will be “Last 7 Days”, “Last 28 Days” and “Total”, but again, you can change them to whatever you want.

Next we have the “Tracking” section, which lets us setup Attendance tracking. This is only available when using the Moodle database, not when using an MIS connection. If you enable this, you can choose the date to start tracking, what period of time it should show tracking for, and what period of time it should be before it writes changes to the database. For example if I set:

  • Track changes every 7 days
  • Tracking period 60 days
  • Start date 21-09-2014

That would mean that, starting on 21-09-2014, every 7 days it would store in a tracking table what the student’s current Attendance data is. Then on the ELBP we would be able to look back over the previous 60 days and see what the Attendance was at every 7 day interval.

NOTE: The tracking table in the database gets VERY large.

Example:

Lastly we have the “Profile Summary” section. If you have the Student Profile plugin installed and enabled, this will allow us to display a summary of the Attendance data in the Student Profile. To do so, simply choose which period you would like to be displayed for each Type. We generally recommend having a “Total” or “Overall” period, for just such an occasion.

MIS

The “MIS” tab lets us connect to an external data source to bring in the Attendance data, rather than using the Moodle database to store it. If you don’t want to use an MIS connection, you can skip this bit.

To setup the plugin to use an MIS connection, firstly you will need to go back to the main Configuration page and create an MIS connection (unless you have already created one you wish to use), then assign it to the Attendance & Punctuality plugin. Now return to the MIS tab on the Attendance & Punctuality settings and change the tick box from “Moodle Database” to “MIS” and save the change. Then you should see various extra settings for the MIS connection.

In order to use the MIS option instead of the Moodle database, your table/view that we will be querying must be in the format of: (id, username, course, type, period, value), though the column names can be different if you want, that is what they must contain. So there must be a new row for each combination of Type and Period for a student. Example:

Where the course is “NULL” denotes the overall data for that student, not specific to an individual course.

In the future we will attempt to broaden the requirements of this plugin, so that if your Attendance data is in a very different format, it will still work without having to create a view to format it like this.

So to setup the MIS connection, first we need to enter the name of the table or view what we will be querying. Then – optionally – any SQL you need to be executed after the connection is established.

Next we need to choose how we are going to find a user in the table/view, will it be by their Moodle username or their Moodle idnumber field?

Then similarly for the courses, how are we going to find a course in the table/view? Will it be by the Moodle shortname or Moodle idnumber field?

Next we have the “MIS Field Mapping” section, where we define what the column names are in our table/view so that we can SELECT the correct data.

The “ID” field should refer to a unique id column (this is optional, but helpful).

The “username” field should refer to a column containing data that will match the user’s Moodle username or Moodle idnumber, depending on which you chose in that setting previously.

The “course” field should refer to a column containing data that will match the course’s Moodle shortname or Moodle idnumber, depending on which you chose in that setting previously.

The “type” field should refer to a column that will contain a valid Type, as defined in your plugin’s settings (e.g. “Attendance”, “Punctuality”, etc…)

The “period” field should refer to a column that will contain a valid Period, as defined in your plugin’s settings (e.g. “Last 7 Days”, “Last 28 Days”, “Total”, etc…)

The “value” field should refer to a column that will contain the numeric value (most likely a percentage) for this particular user/course/type/period.

Example:

Now after we have saved these changes, we can run a test MIS query to make sure it is returning the correct data. For example, using the MIS database view I showed you earlier, I can run a test query looking for any data related to the user with the username “271040”, and I get the following output:

Array
(
[0] => Anon Object
(
[username] => 271040
[course] =>
[type] => Attendance
[period] => Last 28 Days
[value] => 80
)
[1] => Anon Object
(
[username] => 271040
[course] =>
[type] => Attendance
[period] => Last 7 Days
[value] => 70
)
[2] => Anon Object
(
[username] => 271040
[course] =>
[type] => Attendance
[period] => Total
[value] => 90
)
[3] => Anon Object
(
[username] => 271040
[course] =>
[type] => Punctuality
[period] => Last 28 Days
[value] => 11
)
Etc……………
)

Data

The “Data” tab allows us to import Attendance data directly into our Moodle database, using a CSV spreadsheet. You can download an example csv and a template csv to fill out with data to be imported.

You can also choose what to do should the import script come across any users or courses that don’t actually exist in Moodle.

You could use this to manually import Attendance data every day/week/etc… but if possible, the best thing to do (if you want to use the Moodle database) would be to setup a cron, using the “Crons” tab.

Crons

To setup a cron, first choose to enable it. Then choose when you want the cron to run. You can choose either a specific time, or to run “Every…”

For example if you choose:

  • Timing: Specific Time
  • Hour: 05
  • Minute: 30

Then the cron will run at 05:30 every day.

If you choose:

  • Timing: Every…
  • Hour: 01
  • Minute: 15

Then the cron will run every 1 hour and 15 minutes.

Lastly all you have to do is specify where on your server the CSV file will be located to process and import.

The cron will use the exact same script to import the data as is run when you run the import manually from the “Data” tab. So the best thing to do is to test it first using the “Data” tab to ensure that your CSV is in the correct format and working, and then set it up as a cron.

If the cron attempts to run but cannot find the file specified, it will fail.

Best practice would be to have the CSV automatically generated and placed in that location every x hours/days.

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

Then if you view a student’s ELBP, you should see the Attendance plugin is now available.

2.1.5 Attachments

The Attachments plugin is used to provide a space for file uploads that should only be visible by that individual student and so cannot be added to their course page.

Main

As well as the core options, we have the “Attachments Configuration” section we can choose what document types we want to allow to be uploaded. By default none of these will be selected, so you will need to choose some. You can also specify others if the type you are looking for isn’t listed anywhere, but it must be a valid MIME type.

The “Max File Size” setting cannot be edited, it just uses the web server’s setting.

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled. Then if you view a student’s ELBP, you should see the Attachments plugin is now available.

2.1.6 Comments

The Comments plugin is used to allow staff members to write comments about the student. These could be positive comments, such as praising the student for working hard, or negative comments to do with behaviour, attendance, quality of work, etc… They can either be visible to the student, or hidden, and can also be published to the Parent Portal, if you are using that plugin.

Main

As well as the core options, you can also chose how many comments to show in the summary box.

Settings

The “Settings” tab allows us to define attributes to be included in Comments, so we can record whatever data we want. By default these will be set to: Category, Comment and Action Taken. For more information on plugin attributes, see that section of the wiki.

We can also change which attribute should be used as the title for each comment, and upload our own icons for positive/negative, if you do not want to use the ones provided.

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

Then if you view a student’s ELBP, you should see the Comments plugin is now available.

2.1.7 Register

The Register plugin is used to display a student’s register information, so that both the student and staff can see which lessons the student was present/absent/etc… for.

Settings

The “Settings” tab allows us to define the start and end of our academic year, so that we can display the weeks correctly. For example, your academic year might start on 01-09-2014, which you would want to be displayed as “Week 1”. So for “Start Date/Week” you would set the date to “01-09-2014” and the week number to “1”. And do the same for the end of the academic year.

Next we have the “Value Settings” section where we can define codes and what they mean on the register. For example, your institution might use the following codes on your registers:

“/” Present “L” Late “A” Absent “E” Excused Etc…

So here is where you would setup the codes and their titles.

We can also chose whether to show the name of the moodle course (if the register event is linked to one) or the register event description, or both.

MIS

The “MIS” tab allows us to setup the plugin to draw in data from an external data source, rather than using the Moodle database. If you want to use the Moodle database instead, you can skip this bit.

To set up the Register plugin to use an MIS connection, you must first go back to the main Configuration page and create an MIS connection (unless you have already done so) and link it up to the Register plugin. Then come back to the “MIS” tab in the Register settings and change “Moodle Database” to “MIS” and save the change, then you should see some extra MIS settings.

So to setup the MIS connection, first we need to enter the name of the table or view what we will be querying. Then – optionally – any SQL you need to be executed after the connection is established.

Next we need to choose how we are going to find a user in the table/view, will it be by their Moodle username or their Moodle idnumber field?

Next we have the “MIS Field Mapping” section, where we define what the column names are in our table/view so that we can SELECT the correct data.

The “ID” field should refer to a unique id column (this is optional, but helpful).

The “username” field should refer to a column containing data that will match the user’s Moodle username or Moodle idnumber, depending on which you chose in that setting previously.

The “Day Name” field should refer to a column containing the name of the day that particular record is for.

The “Day Number” field should refer to a column containing the number of the day that particular record is for, e.g. where Monday = 1 to Sunday = 7, or Monday = 0 to Sunday = 6. This is so we can order it by day.

The “Course” field should refer to a column containing data that will match the course’s Moodle shortname or Moodle idnumber, depending on which you chose in that setting previously.

The “Description” field should refer to a column containing a description of the event/lesson/etc… This will probably be the title of the course, whereas the “course” field is a code.

The “Start Time” field should refer to a column containing the start time of that particular event. This should be in the format: 00:00, e.g. 12:30

The “End Time” field should refer to a column containing the end time of that particular event. This should be in the format: 00:00, e.g. 13:30

The “Week” field should refer to a column containing the week number of that particular record.

The “Value” field should refer to a column containing the value the student has for that particular record. This should match one of the Values you previously set, such as “/”, “A”, “L”, etc…

Once you have saved these changes, we can run a test MIS query at the bottom of the page, to see if it is returning the data you think it should be.

Data

The “Data” tab allows us to import Register data directly into our Moodle database, using a CSV spreadsheet. You can download an example csv and a template csv to fill out with data to be imported.

You can also choose what to do should the import script come across any users or courses that don’t actually exist in Moodle.

You could use this to manually import Register data every day/week/etc… but if possible, the best thing to do (if you want to use the Moodle database) would be to setup a cron, using the “Crons” tab.

Crons

To setup a cron, first choose to enable it. Then choose when you want the cron to run. You can choose either a specific time, or to run “Every…”

For example if you choose:

  • Timing: Specific Time
  • Hour: 05
  • Minute: 30

Then the cron will run at 05:30 every day.

If you choose:

  • Timing: Every…
  • Hour: 01
  • Minute: 15

Then the cron will run every 1 hour and 15 minutes.

Lastly all you have to do is specify where on your server the CSV file will be located to process and import.

The cron will use the exact same script to import the data as is run when you run the import manually from the “Data” tab. So the best thing to do is to test it first using the “Data” tab to ensure that your CSV is in the correct format and working, and then set it up as a cron.

If the cron attempts to run but cannot find the file specified, it will fail.

Best practice would be to have the CSV automatically generated and placed in that location every night, or every [whatever period you want it to run].

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

Then if you view a student’s ELBP, you should see the Register plugin is now available.

2.1.8 Course Reports

The Course Reports plugin allows teaching staff to create reports as an overview of how the student is performing on their course. They can also create periodical reports (e.g. termly) and combine individual reports into one large report.

Settings

The “Settings” tab allows us to firstly choose what type of courses we want to be able to store Course Reports against. If you do not use Meta/Child courses, or are unsure, just tick “Both”. Then choose which field should be used to display the name of the course.

Next we can define attributes to be included in Course Reports, so we can record whatever data we want. By default these are empty. For more information on plugin attributes, see that section of the wiki.

Next we can edit the “Review Questions” and their possible values. These are a series of options the staff member will be able to fill out when creating the report, to summarise how the student is doing in those various areas.

Next we can put in some instructions for staff to see when creating a new Course Report.

And finally we can hook data into our course reports from other plugins, if it is supported.

The supported hooks for Course Reports are currently:

  • Attendance – This will bring through the student's Attendance data for that course

Periodical

The “Periodical” tab allows us to setup Periodical Reports. We can enable/disable it, and also choose which data to hook into the Periodical Reports.

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

Then if you view a student’s ELBP, you should see the Course Reports plugin is now available.

2.1.9 Additional Support

The Additional Support plugin is similar to the Tutorials plugin, and allows staff members assigned to a student as Additional Support Tutors to record support sessions they have with the student, in the same way the Personal Tutor records Tutorial sessions.

Main

As well as the core options, we also have the “Additional Support Configuration” section where we can set any instructions we want to be displayed to the staff member when creating a new support session. Then we can set the number of most recent sessions to be displayed in the summary box, by default this is 5. Then we can enable/disable Confidence levels, which lets the student set how confident they are at achieving the targets set for them, as well as the score maximum, by default this is 1-5. Then various other settings such as should the Targets lock for editing after the deadline has passed? Should the Targets be deleted if the session is deleted? And do you want a box to be able to email the session details to other interested parties, such as the students Personal Tutor, Teaching Staff, etc…

Settings

Next we can define attributes to be included in Additional Support Sessions, so we can record whatever data we want. By default this ise: Session Information. For more information on plugin attributes, see that section of the wiki.

We can also hook data into our Support Sessions from other plugins. If you want the Support Session to be able to have Targets created for it and assigned to it, you will need to hook in “Targets”.

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

The student will have to have at least 1 staff member assigned to them via the Additional Support Tutor otherwise it will simply say that they are not assigned for Additional Support. This can be done through the dashboard, by following the My Students link on the ELBP block.

2.1.10 Challenges

The Challenges plugin allows the student to highlight areas that they feel may impact upon their academic success, such as Home Life, Finances, Health, etc…

Settings

The “Settings” tab lets us define what possible Challenges the students can choose from, by giving them a name and an icon. By default these challenges will be:

Alcohol/Substance Abuse, Child/Adult Care, Communication Skills, Computer Skills, Cultural Issues, Disability, English Skills, Exam Anxiety, Family Life, Finances, Grief/Loss, Health, Housing/Shelter, Legal Issues, Motivation, Relationship Problems, Stress, Time Management, Transportation, Unclear Goals/Career Choices.

You can assign icons to them by supplying an image URL as well.

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

Then if you view a student’s ELBP, you should see the Challenges plugin is now available.

2.1.11 Learning Styles

The Learning Styles plugin allows the student to take a short questionnaire, which will then calculate their Learning Style. This is based on a custom questionnaire developed for the ELBP, which in future versions you will be able to customise.

Settings

The “Settings” tab allows us to see the default questions and answers, which are used to calculate the user’s Learning Style.

This Learning Style plugin uses the VAK (Visual [Linguistic, Spatial], Auditory, Kinesthetic) Learning Styles paradigm, so each answer gives points to a certain style, which are then averaged out at the end. At the moment you cannot change these without changing things directly in the database, but in future versions you will be able to edit/add/delete questions, answers and possibly styles.

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

Then if you view a student’s ELBP, you should see the Learning Styles plugin is now available.

2.1.12 Custom Plugins

As well as all the plugins supplied with the ELBP, you can create your own customised ones if there is something else you would like on the students’ ELBPs which isn’t covered by any of our plugins.

To create a Custom Plugin, go to the “Plugins” tab of the main Configuration. To create a new one from scratch, give it a title and click “Create”. Or if someone has exported a Custom Plugin for you to import, you can choose the XML file to import it from instead.

We will be creating a new one from scratch for this example.

Once you have created the plugin, it should appear in the “Manage Plugins” list, highlighted yellow. Click on “Settings” and we will set it up.

The “Block Configuration” section has the usual settings, where you can change the plugin’s display name and colours. Now onto the “Plugin Structure” section. This is where we decide what type of plugin we are creating. You have 5 options to choose from:

  • Single Report – This is a single set of form fields, which the user can fill out. They can update their responses whenever they like, but there is only one instance of them. Think of it like the Student Profile. That might have fields like Date of Birth, Address, etc… You only fill them out once, although you can change them later on.
  • Multi Report – This is a set of form fields which can be filled out numerous times, creating new instances. Think of it like a Tutorial. You have boxes to fill out like “Description”, “Comments by Tutor”, “Comments by Student”, etc… but then a few weeks later you want to fill out another new tutorial, using the same boxes.
  • Incremental Report – This is a set of form fields which can be used to append data to a report. Think of it like a table, with each new instance being a row you are adding to the table.
  • Internal DB Report – This lets you define an SQL query to run on your Moodle database, and field mappings so that you can display the information. For example you could set it up to run a query to display all the students courses they are enrolled on, or all the assignments they have submitted on their courses, etc… It is up to you what you want the query to do.
  • External DB Report – This is the same as the Internal DB Report, except that instead of running it against your Moodle database, you setup an MIS connection and run it against an external database.

Next we have the “Summary Configuration” section, where we can set a summary title (this is what appears in the summary box, e.g. “Your Targets”, “Your Tutorials”, etc…) and you can upload an icon to appear in the box (should be 64x64 pixels like the other icons).

Once you have chosen what plugin structure to use, we can edit the settings of the Custom Plugin.

2.1.12.1 Single Report / Multi Report / Incremental Report

Settings

The “Settings” tab of the Single Report, Multi Report and Incremental Report, allows us to define a set of Attributes to appear in the plugin, which can be filled out by the student. For more information on plugin attributes, see that section of the wiki.

2.1.12.2 Internal DB Report

Settings

The “Settings” tab of the Internal DB Report structure allows you to input an SQL query to be run for the student. You can use various placeholders to insert things like the student’s id, username, etc…

You can then choose whether the query is going to return 1 row, or multiple rows which should be looped through.

Finally you can then create the field mappings for the fields that you want to be displayed on the ELBP.

You can also run a test query to make sure it is returning the data you expect, but for testing purposes you will need to replace any placeholders with actual values.

Example:

Becomes:

2.1.12.3 External DB Report

Settings

To use an External DB report, first you will need to go back to the “MIS” tab of the main configuration and create a new MIS connection (unless you already have one you want to use) and assign it to the Custom Plugin.

Now the “Settings” tab of the External DB Report will allow you to setup the SQL query and field mappings.

Example:

Becomes:

Permissions

The “Permissions” tab for the Custom Plugin will allow you to define what users can and cannot do with the plugin, based on their role. What permissions are shown depends on the Structure of the plugin, as some Structures allow for more things to be done with them, than others.

The permissions check on the student’s ELBP will go through System roles, Course roles, User roles and Front Page roles to see if the user has a given permission.

For example, say we were looking at the ELBP of student ID 123, on course ID 4. Also say that you are the Personal Tutor of that student, and finally say the permissions were set so that only Teachers can print the plugin off and only Personal Tutors and Students can edit the plugin.

When checking if the logged in user can print, it will say:

  • In the System context are we a teacher? – No
  • Are we a teacher on Course ID 4? – No
  • Are we assigned to User ID 123 as a Teacher? – No
  • Are we a teacher on Course ID 1 (Front page)? - No

When checking if the logged in user can edit, it will say:

  • In the System context are we a Personal Tutor or a Student? – No
  • Are we assigned to Course ID 4 as a Personal Tutor? – No
  • Are we a student on Course ID 4? – No
  • Are we assigned to User ID 123 as a Personal Tutor? – Yes

So the permission is granted.

2.2 External Plugins

External Plugins can be installed by selecting the relevant path to the plugin in the drop-down menu, in the "Install New Plugin" section and then changing the filename to install from (where required), by clicking on the small, grey file path.

2.2.1 Timetable

The Timetable plugin is an external plugin that comes in its own elbp_timetable block (which can be added to a course page, the same as other blocks), which allows staff and students to the student’s timetable in daily, weekly, monthly and yearly views.

To install this plugin, choose “External Plugin” from the drop down menu, then select “Block” and then “elbp_timetable” and click Install.

Main

As well as the core options, we can choose whether or not we want to try and link timetable records to Moodle courses.

Next we have the “Time Settings” section, where we can define what hour the Timetable should start and end, and how many minutes should it be broken down by.

Next we have the “Colour Settings” where we can choose the default colours for each day on the Timetable (users can change these individually as well).

If you want to use the Moodle database to store your Timetable information, you can skip the “MIS” tab and move onto the “Data” tab.

If you want to use an external database, you can skip the “Data” and “Crons” tabs and go to the “MIS” tab.

MIS

The “MIS” tab lets you setup the Timetable to draw in data from an external database. To do this, the first thing you will need to do is return to the “MIS” tab of the main configuration and create a new MIS connection (unless you already have done so) and link it up to the Timetable plugin. Now if you return to the “MIS” tab in the Timetable settings and change the tickbox from “Moodle Database” to “MIS” and save the change, now we should see some extra MIS settings.

So to setup the MIS connection, first we need to enter the name of the table or view what we will be querying. Then – optionally – any SQL you need to be executed after the connection is established.

Next we need to choose which day numbering system our external database is using: 0-6 (Sun-Sat), or 1-7 (Mon-Fri).

Next we need to choose how we are going to find a user in the table/view, will it be by their Moodle username or their Moodle idnumber field?

Then we move onto the “MIS Field Mappings”, where we define what columns in the external database we need to return. The “ID” field should refer to a unique id column (this is optional, but helpful).

The “Day Number” field should refer to a column containing the number of the day that particular record is for, e.g. where Monday = 1 to Sunday = 7, or Sunday = 0 to Saturday = 6. This is so we can order it by day.

The “Day Name” field should refer to a column containing the name of the day that particular record is for.

The “Username” field should refer to a column containing data that will match the user’s Moodle username or Moodle idnumber, depending on which you chose in that setting previously.

The “Lesson Name” field should refer to a column containing the title of the lesson, to be displayed.

The “Teaching Staff” field should refer to a column containing a string of all the teachers that are relevant for this particular lesson.

The “Course” field should refer to a column containing data that will match the course’s Moodle shortname or Moodle idnumber (if you chose to try and link to Moodle courses by one of these fields).

The “Room” field should refer to a column containing the name of the room this lesson will be taking place in.

The “Start Time” field should refer to a column containing the time that this lesson starts. This must be in the format “00:00”, e.g. “12:30”.

The “End Time” field should refer to a column containing the time that this lesson ends. This must be in the format “00:00”, e.g. “17:00”.

The “Start Date” field should refer to a column containing the date that this lesson series starts. This must be in the format “dd-mm-yyyy”, e.g. “21-09-2014”.

The “End Date” field should refer to a column containing the date that this lesson series ends. This must be in the format “dd-mm-yyyy”, e.g. “31-06-2015”.

Once we have saved these settings, we can run a test MIS query at the bottom of the page, by supplying a username to be queried against, so that we can see what data is being returned.

Example: Given the following external database table/view:

We can see what columns we need to link up to which field mappings. However, the start and end dates are in the wrong format, so to get them into the dd-mm-yyyy format, we will need to apply a function and alias to that field.

So our MIS settings would be:

Now if we run a test MIS query, we can see that the correct data is being returned:

ID: 1 
UserID: 3 
User Full Name: Test Student 
Course: C001-14 
Description: Testing Stuff 
Start Date: 01-03-2014 
End Date: 01-03-2015 
Start Time: 09:00 
End Time: 11:00 
Day Number: 2 
Staff: Conn, Mark, Nadine 
Room: A16
etc...

Data

If you prefer to use the Moodle database, the “Data” tab allows you to import Timetable data manually into your database, using a CSV spreadsheet (example and template available on this page).

You can also choose what the script should do if it comes across any users or courses that do not exist in your Moodle system.

Whilst you can just use this to manually import data as and when you need to, the best thing to do would be to setup a Cron to run automatically to import the data.

Crons

To setup a cron, first choose to enable it. Then choose when you want the cron to run. You can choose either a specific time, or to run “Every…”

For example if you choose:

  • Timing: Specific Time
  • Hour: 05
  • Minute: 30

Then the cron will run at 05:30 every day.

If you choose:

  • Timing: Every…
  • Hour: 01
  • Minute: 15

Then the cron will run every 1 hour and 15 minutes.

Lastly all you have to do is specify where on your server the CSV file will be located to process and import.

The cron will use the exact same script to import the data as is run when you run the import manually from the “Data” tab. So the best thing to do is to test it first using the “Data” tab to ensure that your CSV is in the correct format and working, and then set it up as a cron.

If the cron attempts to run but cannot find the file specified, it will fail.

Best practice would be to have the CSV automatically generated and placed in that location every night, or every [whatever period you want it to run].

Once you have finished setting up your Plugin, you will need to add it to a Plugin Group and ensure it is enabled.

Then if you view a student’s ELBP, you should see the Timetable plugin is now available.

2.2.2 Grade Tracker

Information coming soon...

2.2.3 Parent Portal

Information coming soon...