MoodleDocs - User contributions [en]

Grader report 2014

2025-02-24T07:13:45Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Grader report 2014
|state = Specification
|tracker = https://tracker.moodle.org/browse/MDL-25544
|discussion = https://moodle.org/mod/forum/discuss.php?d=263318
|assignee = Moodle HQ
}}
{{Work in progress|forumurl=https://moodle.org/mod/forum/discuss.php?d=263318}}

This document specifies the changes to be made to the core Grader report in Moodle 2.8. The changes are focussed on improving usability and accessibility for teachers using Moodle gradebook on any platform.

==Rationale==

The major portions of this specification were agreed by the Moodle Gradebook Working Group in June 2014.

This work is supported by the results of the two surveys run by Moodle in May and June, as well as many bug reports in the tracker over the past few years.

==Technology==

* Compatible and maintainable: Javascript is required in this interface, hence our YUI library must be used wherever possible.
* Accessible: WCAG 2.0 compliance and ARIA implementation that is as complete as possible.
* Responsive: Must work well on all platforms from smartphone browsers up to large desktop screens.

==Main display==

The main display is the "scrolling spreadsheet" showing users as rows and activities as columns.

We agreed to base this interface around the prototype from UCLA, which uses YUI:

[[Image:UCLAgraderproto.png]]

Final features include (some are in the above prototype *):
* Uses whole window (blocks can be collapsed/restored easily) *
* Scrolls up/down and left/right based on page scrolling *
* Display header rows for weight, range and average.
* Headers on top are sticky to the top of the viewport *
* Headers on left and sticky to the left of the viewport *
* Headers on bottom are sticky to the bottom of the viewport *
* Minimal cell size
* Endless scrolling - no paging
* Sort on any column *
* Collapse/expand columns and header rows (eg like Google sheets)
* Switch between categories / course columns or show only item columns
* Column with Last modified date for sorting users
* Wrap headers according to user-defined width (drag column borders?)
* Navigate between cells using arrow keys

This display also offers some editing:
* Cells can be edited as now.
* Drag and drop columns to change order or put them into other categories
* Clear overrides button top of each column

==Dynamic filters==

Dynamic filtering controls at the top of the page can reduce the rows shown:
* by name search
* by group or groupings
* by grade range
* what else?

==Single row/column editing==

Each student row will have a link to a new page where all the grades for that student are shown in a long form (along with other settings like overrides) and can be edited.

Each activity column will have a link to a new page where all the grades for that activity are shown (along with other settings) and can be edited.

Features include:
* Jump/swipe to next/previous row/column.
* For each cell in a row, jump to corresponding column by clicking near activity name, and for each cell in a column, jump to corresponding row by clicking near student name.

Quickedit screens from LSU:

One student:
[[File:rowedit.png]]

One activity:
[[File:columnedit.png]]

==Original workshop notes==

Content

Datatable with activities columns, user rows (like UCLA)
Range and Average along top below header row (Luther College)
Use case for keeping average (on by default)? Many teachers like it. But averages is a load issue on large courses.
Should averages be for course or just displayed? Some like the average to just be for the information displayed, but need to indicate that to the user.
Table decision until later.
Can freeze footer row to bottom of page to keep averages on-screen all the time (like UCLA)
Currently includes 0 or empty scores and non-active enrollments (config option?)

Dynamic Filtering

Any user field (as ELIS example) https://github.com/remotelearner/elis
Groups and groupings
Modified date ranges

Clean responsive design

Smaller cells (eg: UCSB report)
Fixed student information columns and header rows, not scrolling off page on vertical scroll (As UCLA example)
Maximize content button to hide all blocks/headers (see UMN, Tracker)
Mobile: for very smallest screens don’t even show table, just filters for users/activities -> list of names -> quickedit

Columns

Drag and drop edges to resize widths
Drag and drop columns to
Change order
Move them into (other) categories
Save sort order and category movement in the backend
Collapse/expand columns (eg Google sheets)
Switch between categories / course columns or show only item columns
Clear overrides button top of each column
Teacher-definable columns for text. Add a grade, ability to assign text value to the GRADE (not just feedback)
Last modified date - for sorting users
Header cells
Wrapped text to user-defined width
Real weight displayed in cell (ex: 'W=28.33‰')

Input

By admin setting, disable ability to input values into category and course cells. Disable would be the default setting.
Ability to enter grades as points, letters or percentages. Letters would be translated to one point lower than the minimum for the next highest letter
Links to single row/column edit forms (aka Quickedit from LSU)
Quick Edit - add configuration option to specify which user fields are displayed for student
Autofill column’s empty cells with selected value

Redesign the control buttons for each cell. Let's just give this some thought how it could be substantially improved. Maybe a control drop down, edit, unhide, etc like some of the themes treat activity controls

Admin setting controlled link to quick dump (preconfigured export to csv) (Luther College)

Notifications/History

Like Google Docs tells you what/who changed something recently.
Maybe color changed background for recently changed grades.
Idea, when hovering over grade cells, indicate who made last change.
Advisory that someone else is editing the gradebook

Sandbox/”Unit tests”

Allow instructor to “test” their gradebook setup with sample data to ensure they have it setup correctly.
LSU’s “Projected Final Grade” report allows students to see what they need to score on the remaining un-graded items.
Can be expanded for instructors? Yes.
Can it be turned off? Faculty can turn it on or off for students.
Have a “Potholes” (UCSB) like dashboard to alert instructor of any potential problems with their gradebook.

Arrow key support

Can already use tab and tab ordering works fine by going to next value in column.
Idea: What about using arrow keys to move between columns or cells as well? (Remote Learner)

Gradebook setup

Allow drag and dropping of items to reorder items/categories.

Gradebook Help

Sliding screen as in UCLA example

Moodle Workplace 4.1 release notes

2025-02-12T05:20:14Z

Sarjona:

=4.1=
See our [https://docs.moodle.org/401/en/Moodle_Workplace_new_features Moodle Workplace 4.1 new features page] in the user documentation for an introduction to Moodle Workplace 4.1 with screenshots.
==Major features==
Moodle Workplace 4.1 is based on top of Moodle LMS 4.1 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace:
* '''Advanced tenant appearance settings''': tenant branding now includes two more settings that were available in Workplace 3.11: Navigation bar and Primary button colours. We have added more granularity to the permissions to change the appearance of the tenant, so advanced settings such as custom SCSS can be restricted to specific roles.
* '''Improvement to Tenant-allocation rules in the Shared Space'''. We have added two new conditions (“Users is allocated to tenant” and “User is not allocated to tenant”) and one action (“Allocate to tenant”) to Shared Dynamic Rules, with this addition we simplify the tenant allocation workflows for Admins in multi-tenant Workplace sites.
* '''Migration of core_reportbuilder custom reports'''. Migration feature now supports import and export of Custom Reports using Moodle LMS native report sources.
* '''Improved My Teams support in the Workplace App'''. The new My Teams page now includes information about learning and tracking in the Workplace App.
=== Other interesting features ===
* Hide/mask description of Dynamic rules conditions and actions when current user is not able to edit them
* Improved how hidden courses are displayed in the My Courses and Program pages
* Added "department" to User profile field condition in Dynamic Rules
* New setting to disable Program Cover page
* New setting to hide "Dates" section in the course information popup
* Fixed bug with deleted appointments being listed in user calendar
* Archive course certificates during program reset
* Display a warning when changing a tab without saving a form
* Allow tenant admin to edit locked profile fields for users in their tenant
* Fixed a bug causing an exception when viewing program progress report as an organisation manager after program import
== Upgrade notes for 4.1 ==
=== Upgrade from LMS ===
If "$CFG->forcewpsetup = true;" is set in config.php before upgrading Moodle LMS to Moodle Workplace 4.1, the upgrade process add ‘myinprogress’ and ‘myavailable’ blocks to the default dashboard, and reset the dashboard for all users.
=== Upgrade from Moodle Workplace 3.11 and 4.0 ===
On upgrade from Workplace 3.11 to 4.1 in one step, all appearance settings will be preserved excepting the Drawer colour, which doesn’t have any equivalent in 4.1.

Note that in case the upgrade is performed in two steps (3.11 > 4.0 and 4.0 > 4.1), the Navigation bar and Primary button colours will not be preserved in the corresponding settings, but the values of the settings that were added as custom CSS on upgrade to 4.0 will still be available (see [[Moodle Workplace 4.0 release notes#Branding|Workplace 4.0 upgrade notes]]).
=== Deprecation ===
We have deprecated the following in 4.1:
* get_managed_users web and get_teams_tab_filters web service in tool_organisation;
* get_user_learning_statuses in tool_program.
* tool_wp/db class
=4.1.1=
Moodle Workplace 4.1.1 is based on top of Moodle LMS 4.1.1 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace. This is a very short release as we launched 4.1 one week ago, so it does only include a couple of minor bug fixes.
=== Interesting features and fixes ===
* Fixed bug blocking users without the capability to edit their own profile to access Program Pages
=4.1.2=
See our [https://docs.moodle.org/401/en/Moodle_Workplace_new_features#4.1.2 Moodle Workplace 4.1.2 new features page] in the user documentation for an introduction to Moodle Workplace 4.1.2 with screenshots.
==Major features==
Moodle Workplace 4.1.2 is based on top of Moodle LMS 4.1.2 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace:
=== Key highlights ===
''(Available in 4.1.2 rolling only)''
* '''Search, filtering and reporting improvements to the Team overview block''':
** Quick filters that allow users to sort and filter data quickly within the Team overview block, making it easier to find the information they need.
** Access to full progress reports for certification, program, and course reports provide a comprehensive overview of each team member's learning progress
** Live search functionality that allows users to search for specific items in real-time within the Team overview block
** Warnings for overdue learning to provide notifications and reminders to users when they are falling behind on their coursework or certifications.
* '''Automatic branding enhancement for tenants''': generate shades of grey automatically based on the tenant primary colour, to reinforce the brand identity while avoiding disturbing the experience.
* '''Improvements in Appointments:'''
** New expandable UI for session details and bookings, with consistent navigation and design across activity modules.
** New completion criteria based on attendance
* '''Improvements in Dynamic Rules'''
** '''New action to end jobs'''
** '''New action to assign users to learning plans'''
** Option to suspend user's allocation to programs and certifications
* '''New setting to lock shared department and position frameworks''': only users with appropriate permissions can manage jobs within locked departments and position frameworks.
* '''Apply only allowed filters in Certificates:''' new feature for users to define allowed filters for certificates, so that only the ones specified by the user are applied to the PDF content.
=== Other improvements ===
''(Available in 4.1.2 rolling only)''
* Lock the Audience tab in Custom Pages and don’t include audiences in duplication of custom pages for users with no permission to locked departments and positions.
* Added back a link to Moodle LMS's user management page in Site Administration
* Maintain the order of blocks in courses when switching from Workplace List to topics course format during upgrade
* Introduce new data attributes to distinguish the tenant for better tenant customization
* Preserve the URL when switching tenants
=== Other interesting features and fixes ===
''(Available in 4.1.2 rolling and 4.1.2 standard)''
* Add the possibility for Certificate element plugins to have their own settings page
* Add course name to “My Certificates” list
* Fixed a bug that prevented the import of positions and departments into existing frameworks, preserving the hierarchy
* Fixed a bug where the completion status for courses was not displaying correctly on the Program Page
* Fixed a bug that prevented tenant administrators from viewing hidden user fields
* Legacy custom reports can no longer be created if custom reports are disabled site wide
== Upgrade notes for 4.1.2 ==
=== Block order is preserved when upgrading to 4.1 rolling only ===
In Workplace 4.0, the old Workplace List course format was replaced with topics course format (more details on [[Moodle Workplace 4.0 release notes#Course%20format%20.E2.80.9CWPList.E2.80.9D|Workplace 4.0 upgrade notes]]). As a consequence of that upgrade, order of blocks in course page might not be preserved (as per MDL-37240).

If the order of the blocks in courses has been changed and needs to be preserved, please make sure to upgrade to 4.1.2 rolling.
=== New data attributes to identify the tenant ===
Workplace 4.1.2 (rolling only) includes two new HTML data attributes to help to customize the styles for specific tenants. The new attributes are <code>[data-tenantid="{tenant_id}"]</code> and <code>[data-tenantidnumber="{tenant_idnumber}"]</code> (available when <code>idnumber</code> is defined for the tenant)
=4.1.3=
See our [https://docs.moodle.org/401/en/Moodle_Workplace_new_features#4.1.3 Moodle Workplace 4.1.3 new features page] in the user documentation for an introduction to Moodle Workplace 4.1.3 with screenshots.
==Major features==
Moodle Workplace 4.1.3 is based on top of Moodle LMS 4.1.3 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace:
=== Key highlights ===
''(Available in 4.1.3 rolling only)''
* '''Support contact by tenant.''' Now it is possible to configure the support contact information (support contact, support URL and availability) at a tenant level, so different tenant can have their own support contact settings.
* T'''eam’s overdue learning warnings for managers'''. The team overview block in the My Teams page now displays a warning when there are people with overdue learning to their managers. This notice includes a link to the corresponding report.
* ''''''User first login dynamic rule condition.'''''' Now it’s possible to create automations based on user’s first login.
=== Other improvements ===
''(Available in 4.1.3 rolling only)''
* Notify program creators when a course in the program when course completion is not set for courses with completion tracking enabled
* Add manager and department lead permissions to CSV import
=== Other interesting features and fixes ===
''(Available in 4.1.3 rolling, 4.1.3 standard and 4.0.8)''
* Fixed a bug causing appointment sessions being deleted after deleting another session.
* Fixed a bug that prevented assigning jobs in the upload user tool when using positions with duplicated idnumbers
* Fixed a bug in causing ad-hoc reports scheduled to be stuck endlessly
== Upgrade notes for 4.1.3 ==
Due to a fixed bug, the reports generated in the scheduled reports may now contain more data than they did before. We recommend reviewing your schedules and make sure that "View report as" is correct. For example, if the "View report as" is a global admin, the reports may contain cross-tenant data and they will be sent to all users in the schedules audiences, even those who do not normally have access to cross-tenant data.
= 4.1.4 =
Moodle Workplace 4.1.4 is based on top of Moodle LMS 4.1.4 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.
=== Interesting features and bug fixes ===
* Fixed a bug where the 'reset program' option was incorrectly displayed for dynamic allocation
* Fixed a bug in the 'Access' tab on tenant page where some users might have been incorrectly displayed.
* Fixed a bug during the upgrade process that caused it to get stuck in a loop
* Fixed a bug during the installation process that caused blocks in the dashboard to be copied multiple times under certain circumstances.
* Fixed a bug in tenant archiving that was granting tenant administration permissions from the default tenant to the tenant administrator of the archived tenant
* Fixed a bug during the upgrade process that caused it to get stuck in a loop (''4.1.4 rolling only)''
= 4.1.5 =
Moodle Workplace 4.1.5 is based on top of Moodle LMS 4.1.5 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.
=== Highlights ===
* We added some changes to the "Workplace" theme that allow to create child themes easier. We have released an example "[https://github.com/moodleworkplace/moodle-theme_wpchild Workplace child theme]"
* Moved "Information" tab to the second position on the course page
* Changed report data source "Issued certificates" removing a very strict capability check. Now it is possible to create reports such as "My certificates" or "My team's certificates" that can be accessed by users who can not view the templates list.
** '''Upgrade notes:''' To prevent accidental disclosure of new data to people who already have reports using the "Issued certificates" datasource, we have added a new condition that mimics the previous hardcoded restriction. This condition (called "Permission to access templates") is automatically added during upgrade to all existing reports from this datasource. It can be removed if necessary. This condition will not be automatically added to the newly created reports but can be added manually if needed.
=== Other fixes ===
* Fixed a bug causing program reset ad-hoc task to fail
* Fixed a bug insufficiently resetting course module views during program reset
* Fixed a bug causing failures during organisation structure export
* Improved Dynamic rules, allowing some actions to be executed as scheduled tasks only. Changed actions "Assign to learning plans" and respective "Unassign" action to use this functionality, because they can fail if they are executed in a session of a student
* Changed workplace activity icons to look more consistent with the LMS activity icons (white instead of black)
* Bug fixes and improvements in how some tenant configuration data is being sent to the mobile app (among other things, this makes sure that the site name in the user information page is correct and corresponds to the current tenant).
* Added validation to the tenant branding "Custom SCSS" field to prevent accidental breaking of the whole site layout
* Added column "Session date & time" to Appointments datasources that was present in legacy report builder in 3.11 but was forgotten in 4.0+ report builder

This version also contains a fix for a security issue in Moodle Workplace, the details will be communicated to the Moodle Partners on the day of release and disclosed here later.
= 4.1.6 =
Moodle Workplace 4.1.6 is based on top of Moodle LMS 4.1.6 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.
=== Other fixes ===
* Fixed: Suspended on Program report displays "Yes" even though user is not suspended from program

This version also contains a fix for a security issue in Moodle Workplace, the details will be communicated to the Moodle Partners on the day of release and disclosed here later.
= 4.1.7 =
Moodle Workplace 4.1.7 is based on top of Moodle LMS 4.1.7 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.
=== Fixes ===
* Fixed condition 'Select course' in the course participants custom report
* Appointment status and session summary no longer shows Wait-listed users as 'Booked'
* Allow to sort by allocation date column in report builder
* Fixed bug when manually changing certification due date causes date to get stuck on program info card
* Do not show percentage in recent courses block if course does not have completion
* It is now possible to delete user profile picture in the tenant user editing popup
* Do not show the enable/disable switch for the manual auth method that can never be disabled
= 4.1.8 =
Moodle Workplace 4.1.8 is based on top of Moodle LMS 4.1.8 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.
=== Fixes ===
* Removed and empty link in the "Certification progress" report

= 4.1.9 =
Moodle Workplace 4.1.9 is based on top of Moodle LMS 4.1.9 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.
=== Fixes ===
* Corrected the link to the user documentation in the Course Certificate activity module
* Fixed a bug in the Course Certificate scheduled task related with deleted templates

= 4.1.10 =
Moodle Workplace 4.1.10 is based on top of Moodle LMS 4.1.10 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.
=== Fixes ===

* Fixed multiple accessibility issues in several components in the scope of the WCAG 2.1 AA accreditation

= 4.1.11 =
Moodle Workplace 4.1.11 is based on top of Moodle LMS 4.1.11 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.

=== Fixes ===

* Various accessibility fixes related to the ongoing effort to achieve WCAG AA accessibility accreditation for Moodle Workplace

= 4.1.12 =
Moodle Workplace 4.1.12 is based on top of Moodle LMS 4.1.12 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.

=== Fixes ===

* Add support for separate group mode to Appointments activity module

=4.1.13=
Moodle Workplace 4.1.13 is based on top of Moodle LMS 4.1.13 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.

=== Security fixes ===
* A number of security related issues were resolved. Details of these issues will be released after a period of approximately one week to allow system administrators to safely update to the latest version.

= 4.1.14 =
Moodle Workplace 4.1.14 is based on top of Moodle LMS 4.1.14 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.

=== Security fixes ===

* A number of security related issues were resolved

= 4.1.15 =
Moodle Workplace 4.1.15 is based on top of Moodle LMS 4.1.15 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.

=== Fixes ===

* Resolved issue where users from other tenants could be incorrectly displayed on the tag index page

= 4.1.16 =
Moodle Workplace 4.1.16 is based on top of Moodle LMS 4.1.16 and has all the new features of the core version. In addition, it contains all exclusive features from Moodle Workplace.

There were no workplace-specific fixes in this release.

Exporting/importing several question categories at once

2025-02-10T08:32:57Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

==Interface==

The new interface, which lets you export several question categories at once.

To activate the export / import multiple categories question, click "Write several".

[[File:activate_mod.jpg]]

After clicking "Write several" combobox list elements is replaced by a tree of categories as it shown on the picture.

[[File:tree_categories.jpg]]

How to change the interface is described below .

1. Category you want to export, are chosen as you can watch at the image.

[[{{ns:file}}:Capture.png]]

To achieve the desired result, I have to use it.

==Change export/import function and file structure==

Import function does not need to be changed. Importing several question categories works correctly.

Export function needs to be corrected. Now only one question category exported.

Now Moodle has the structure of the file described below.

In the file category describes then questions describes which belong to the category then next category describes etc. This structure of the file is suitable for export of several question categories. A structure can be represented visually as

[Description category1]

[Description first question of category1]

[Description second question of category1]

[Description third question of category1]

[Description category2]

[Description first question of category2]

[Description second question of category2] .

So to achieve the goal I will not have to change the structure of the file.

Event Monitor specification

2025-02-10T08:28:54Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Event Monitor
|state = Implemented
|tracker = MDL-45758
|discussion = https://moodle.org/mod/forum/discuss.php?d=261660
|assignee = Ankit, Simey
}}
{{Moodle 2.8}}
The Event Monitor report will allow users to select events and receive notifications in real time* when the chosen event happens.

This report will be built on top of the new [[Events API]] infrastructure.

== How it works ==

* The user or site admin creates a specific set of “rules” that can be subscribed to.
* Each rule defines an event and frequency parameters.
* The users select the rules they are interested in and then subscribe to it at course level for a specific module or all modules.
* Whenever the event occurs in the system , in the frequency specified in the rule, a message is sent out to all the subscribers.
* Since we are using Moodle messaging system to send out these notifications, it can be delivered in any format supported by Moodle (Mobile notification, popup, email etc)
* There would be some default rules that would be shipped with the report, that users can subscribe to straight away.

=== User interface mock-ups ===

==== Subscribe to a rule ====

This is the main page of the Event Monitor report where users can see a list of rules and their current subscriptions. This also lets users to subscribe to new rules or delete their current subscriptions.

[[File:subscriptions.png]]

==== Manage rules ====

This page lets you manage the rules if you have appropriate permissions (create/edit/delete/copy)

This is roughly how the page will look like:-

[[File:listrules.png]]

==== Add/Edit a rule ====

This is the form where users can create a new rule, customise the filters (frequency and time) and personalise the notification message.

[[File:addrule.png]]

=== A specific example ===

One scenario may be that you wish to be notified when discussions are becoming active in a course's forums.

The figure above shows the creation of a new rule called 'My Student Discussions', which is set to monitor the 'Post Created' event, which is triggered by the 'Forum' module.

In this case, any user subscribed to this rule will receive notifications whenever 30 posts are created in 60 minutes in forums of a course, or within a single forum that have identified in their subscription to the rule.

The notification will contain the customised message as configured in the rule.

=== Message template ===

One interesting option of rule addition is the message template. When creating or editing a rule, the user can embed placeholders to add details to notification messages.

The use of placeholders in a message template is optional, so you don't have to use placeholders; you can use any personalised message.

The following table lists the available placeholders that can be used in a message template.
{| class="wikitable"
! Placeholder
! What it does?
! Example
|-
| '''{link}'''
| Direct link to the actual event, eg a forum discussion.
| http://YourMoodle.com/mod/forum/discuss.php?d=2
|-
| '''{modulelink}'''
| Link to the module where the event has happened, eg a forum
| http://YourMoodle.com/mod/forum/view.php?id=8
|-
| '''{rulename}'''
| A name for the rule.
| Student discussions
|-
| '''{description}'''
| A description of the rule.
| I want to receive notifications when there is a large volume of student posts in a discussion.
|-
| '''{eventname}'''
| The name of the event being monitored.
| Forum post created.
|-
|}
The examples above show the placeholders for a rule to monitor the '''Forum post created''' event. Here is an example of a message template using these placeholders.

The rule '''{rulename}''', monitoring the event '''{eventname}''', has just been fulfilled.
Click the following link to go to the forum discussion: '''{link}'''
Rule description: '''{description}'''

The result of this message template would be as follows.

The rule Student discussions, monitoring the event Forum post created, has just been fulfilled.
Click on the following link to go to the forum discussion: http://YourMoodle.com/mod/forum/discuss.php?d=2 .
Rule description: I want to receive notifications when there are a large volume of student posts in a discussion.

Now, let's create a rule called '''Glossary entries''' to monitor when a new glossary entry is created:

The rule '''{rulename}''', monitoring the event '''{eventname}''', has just been fulfilled.
Click the following link to go to see the new entry created: '''{link}'''
Rule description: '''{description}'''

The result of this message template would be as follows.

The rule Glossary entries, monitoring the event Entry has been created, has just been fulfilled.
Click on the following link to go to see the new entry created: http://YourMoodle.com/mod/glossary/view.php?id=5&mode=entry&hook=1.
Rule description: I want to receive notifications when a new glossary entry is created.

Note that some events do not have a link. '''Course deleted''' and '''Course module deleted''' for example, would not display any link if '''{link}''' or '''{modulelink}''' is used.

== Benefits ==

* Real time monitoring of events happening in Moodle.
* Admin can be notified when there is heavy activity on the site or they can monitor specific actions that interests them (ex:- course delete).
* A notification can be sent straight to a user's mobile if there is a situation that needs immediate attention.
* The report will be designed to trigger an event when a given subscription criteria are met. This will allow developers to build really powerful scripts on top of the report. For example, a block displaying “Hot forums”, or something more complex like load balancing when there is lot of activity in the forums or quiz.

== Usage scenarios ==

* Send notification when more than X posts in any forum are made in a given course in Y minutes.
* Send notification when new chapters are created in a book.
* Send notification (to admin) when a course is deleted.
* Send notification (to students) that a particular activity has been updated.
* Send notification (to admin) when potential security risk might happen due to change in system setting.

== Future work ==

* Allow events to be subscribed by only certain roles
* Forced subscriptions for students for certain rules
* An activity stream for messages
* An facebook style notification system for notifying logged in users

== See also ==

* [[Events API]]
* Moodlerooms developed a "[http://kb.moodlerooms.com/article/81/administrator Personalized Learning Designer]" that has some of these features (mostly for individual students only).
* Real time means “as soon as possible” - this depends on the cron configuration of the site. (For further information refer to [[https://docs.moodle.org/dev/Task_API#Adhoc_task_usage Adhoc tasks]])

Email reminders for calendar events

2025-02-10T08:24:53Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

== Introduction ==
Reminders are very useful for both students as well as teachers to recall their scheduled event before the actual moment. This project is about creating a set of reminders for Moodle calendar events and sending them ''automatically'' to relevant users on timely manner via Moodle message interface. It will be implemented as a local plugin to the Moodle.

== Requirements ==
Moodle 2.2 required

== Community Bonding Period ==

=== Milestones ===
# DONE - Refine the project proposal with Michael, Rossiani and the community
# DONE - Feature discussion
# DONE - Create mockups

=== Features ===
Following features are expecting to package with the reminders plugin.

:1. Reminders can be sent by customizing according to each event type.
::* Separate message providers for each event type.
::* Ability to customize message content according to event type.
:2. Administrator configurations
::* Administrator can enable/disable the process of sending reminders without uninstalling the plugin.
::* Ability to choose how many days ahead should the reminders be created ''for each event type''.
::** Reminders can be created only by days.
::** Supported only fixed amount of days ahead such as 7 days, 3 days and 1 day.
::* Ability to keep/remove history of reminder events.
:2. User configurations
::* User can select desired method of receiving reminder notifications on each message provider.

== Coding Period ==

=== Milestones ===

:1. DONE - Finalize the abstract architecture.
:2. DONE - Implementing the basic structure of the plugin. (CONTRIB-3648)
::* DONE - Creating a suitable version file.
::* DONE - Creating a language file.
::* DONE - Creating a message provider file.
::* DONE - Creating a lib file for the cron function.
:3. DONE - Implementing message providers for each event type. (CONTRIB-3659)
:4. DONE - Providing a administrator settings page. (CONTRIB-3660)
:5. DONE - Implementing necessary reminder classes. (CONTRIB-3669)
::* DONE - Creating abstract reminder class.
::* DONE - Creating concrete reminder classes for each event type.
:6. DONE - Building functionality.
::* DONE - Generation of message content for reminders. (CONTRIB-3671)
::* DONE - Implementation of Cron function. (CONTRIB-3670)
::* DONE - Extending to support plugin for repeated events. (CONTRIB-3672)
:7. IN PROGRESS - Testing
:8. IN PROGRESS - Bug fixing

=== File Structure ===
Following shows expected file structure of the plugin. Plugin name would be "''reminders''".

* contents/course_reminder.class.php
* contents/site_reminder.class.php
* contents/group_reminder.class.php
* contents/user_reminder.class.php
* contents/due_reminder.class.php
* db/access.php
* db/message.php
* db/upgrade.php
* lang/en/local_reminders.php
* reminder.class.php
* version.php
* lib.php
* settings.php
* README

=== Explanation ===
Picking up relevant events to send reminders in advance is very important and critical. Reminders must be sent only once for a event on predefined ahead of days. Identifying such events has to be done efficiently and carefully. It shows below how it can be achieved.

Events are checked against a ''fixed amount of time period'' in each and every cron cycle.

If any of event is falling exactly 1, 3 or 7 days ahead for that checking time period, that event will be marked as
a ready event to send reminders. In mathematically, if any event should satisfy to send reminders

(t(Ei) - X > T1) AND (t(Ei) - X <= T2) AND (t(Ei) > T2)

Where t(Ei) is the start time of the event and X is a set of constants indicates 1,3 or 7 days in seconds.

That ''fixed amount of time period'' is decided as the timestamp different between last cron cycle (this timestamp is not the
timestamp corresponding to the start of that cron cycle, but the time it began to check for its previous timeslot. This
can be extracted from info field in log record) and current time.

:1. If the running cron cycle is the first ever cron cycle (i.e. no log record could find for a previous cron cycle), then the time will be cutoff by X amount of days before as configured.
[[File:first_cron.jpg]]

::* (t1,t2) is the time period the time period that cron is running.
::* (T1,T2) is the time period which will be checked against events. (T1-T2) will be a constant and will be used at most once.

:2. Otherwise,
[[File:nth_cron.jpg]]
::* (t1,t2) is the interval between two cron cycles as defined in plugin.
::* (T1,T2) is the time inspecting region. (T1 will be decided by log record for the last cron cycle)

=== High Level Architecture Diagram ===

[[File:overall_architecture.jpg]]

=== Reminders Class Diagram ===
[[File:reminder_class_diagram_1.jpg]]

== Mockups ==
=== Administrator Setting Page ===
[[File:reminders_admin_config_page.jpg]]

=== Message Format (HTML) ===
* Message Title : Reminder: ${event_detail} @ ${event_date_time}

[[File:message_format_HTML.jpg]]

=== Message Format (Plain-text) ===
* Message Title : Reminder: ${event_detail} @ ${event_date_time}
* Message Content:

: '''${message_title}'''
: Reminder - #n days remaining

: When -> ${event_time}
: What -> ${event_course} or ${event_type}
: Description -> ${event_description}

== Screenshots ==
=== Admin Settings Page ===
[[File:settings_page_1.jpg]]

=== Sample e-mail reminder for course event ===
[[File:sample_email_reminder_course.jpg]]

=== Sample e-mail reminder for due event ===
[[File:sample_email_reminder_due.jpg]]

== Credits ==
* Mentors: [http://moodle.org/user/view.php?id=381842&course=5 Michael de Raadt] and [http://moodle.org/user/view.php?id=955449&course=5 Rossiani Wijaya]
* Special thanks goes to [http://moodle.org/user/profile.php?id=1297063 Luiggi Sansonetti] who translated the plugin into French language.
* Another thank goes to Guido Roessling for providing a German translation for this plugin

== Tracker ==
* CONTRIB-3647 Automating Email reminders for calendar events

== See also ==
* Plugin development [https://github.com/isuru89/moodle-reminders-for-calendar-events Repository]
* [https://docs.moodle.org/dev/Projects_for_new_developers Moodle - Google Summer of Code 2012 Idea List]
* [http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/isuru89/1 Original Proposal - GSoC 2012]
* RSS Feed from Personal Blog, [http://uisurumadushanka89.blogspot.com/feeds/posts/default/-/gsoc RSS Feed].

Email notification when a quiz is submitted

2025-02-10T08:24:17Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

This is a old feature request ([http://tracker.moodle.org/browse/MDL-648 MDL-648]) and there are various patches floating around, but I now want to implement this properly in core, probably for Moodle 2.0, but maybe for Moodle 1.9 if we are lucky.--[[User:Tim Hunt|Tim Hunt]] 04:59, 21 June 2007 (CDT)

[http://moodle.org/mod/forum/discuss.php?d=74185 Please discuss this proposal in this forum thread].

==Brief description of the requirement==

When a student clicks 'Submit all and finish' on a quiz attempt, send an email confirmation to one or both of:
* The student themselves.
* Any designated 3rd parties - who gets emailed needs to take account of the 'Separate groups' setting, if appropriate.

It should be possible for admins to customise the text of either of these emails.

==Design==

===Controlling who gets emailed===

Users will get an email confirmation of their own quiz submission if they have the mod/quiz:emailconfirmsubmission capability on the quiz. (This means that whether confirmations are sent can be controlled for the whole site by changing the role definition, and it can be separately controlled for each quiz using role overrides.)

Similarly, users will get notified of other people submissions if they have the mod/quiz:emailnotifysubmission capability. If a user has both mod/quiz:emailconfirmsubmission and mod/quiz:emailnotifysubmission then they only get one email, the confirmsubmission one.

====Interaction with groups mode====

If the quiz is set to 'Separate groups', then the notifysubmission email will only be sent to those users who are in the same group as the person who submitted, or who have the moodle/site:accessallgroups capability.

===Configuring the text of the emails===

The emails will be stored in language strings in the quiz.php lang file. There will be strings emailconfirmsubject, emailconfirmbody, emailnotifysubject and emailnotifybody.

When these strings are loaded, a '$a' variable contining lots of useful information will be passed in which may be used in the message. The fields available will be:

;$a->coursename
:The name of the course
;$a->courseshortname
:The shortname of the course
;$a->quizname
:The name of the quiz
;$a->quizreporturl
:The URL of the results overview for this quiz (.../mod/quiz/report.php?q=''quizid'')
;$a->quizreportlink
:The URL of the results overview URL and quiz name as a HTML link
;$a->quizreviewurl
:The URL of the review page for this attempt (.../mod/quiz/review.php?attempt=''attemptid'')
;$a->quizreviewlink
:The attempt review URL and quiz name as a HTML link
;$a->quizurl
:The URL of the main page of the quiz (.../mod/quiz/view.php?q=''quizid'')
;$a->quizlink
:The URL of the quiz and the quiz name as a HTML link
;$a->attemptsubmissiontime
:The time the attempt was submitted, formatted using userdate().
;$a->timetaken
:How long the quiz attempt lasted.
;$a->studentname
:The name of the person who submitted the quiz.
;$a->studentidnumber
:The idnumber of the person who submitted the quiz.
;$a->studentusername
:The username of the person who submitted the quiz.
;$a->username
:The name of the user the email is being sent to.
;$a->useridnumber
:The idnumber of the person who submitted the quiz.
;$a->userusername
:The username of the user the email is being sent to.

===When the emails are sent===

It is important that if an error occurs during sending of the emails, then this does not prevent the quiz from being submitted. So we will use the [[Events API]] to fire an event when the quiz is submitted, and then write an event handler to do the email sending.

==Where to implement this==

Graham Miller volunteered in the forums to try to implement this, so here are some brief notes on how.

===Which version?===

Since this is a new feature, it really ought to go into HEAD. However, if we took out the use of the events API, it could be done in essentially the same way in the 1.8 and 1.7 branches and HEAD. That would be OK for a first implementation.

===Where should the code go===

In /mod/quiz/locallib.php, we need a new quiz_send_notification_emails(...) function to do the work. More on this in a moment.

This new function should then be called from /mod/quiz/attempt.php. Pass in as much as possible if the information that is already available in attemtp.php as function arguments, so we don't have to re-fetch it from the database. The call should be just before the bit

<pre><nowiki>
/// Check access to quiz page

// ... [SNIP]

if ($finishattempt) {
redirect('review.php?attempt='.$attempt->id);
}
</nowiki></pre>

The new capabilities need to be added to /mod/quiz/db/access.php as usual, with a bump of the version number in /mod/quiz/db/version.php.

To test whether to send to the student who has just submitted, use has_capability. To get a list of 3rd parties to email, user get_users_by_capability, passing $doanything = false.

To prepare the $a variable, you mostly just need to assemble the right data from the users, quiz and course. For the bits relating to attempts (that is, how to format the times), you can see the code necessary in review.php.

Then you use get_string to generate the email body and subject.

Then you use email_to_user from from lib/moodlelib.php to send the email.

Obviously you need to do deal with any errors that may arise along the way. (The main benefit of using the events api would have been easier error handling.)

Finally, write some teacher-facing documentation at an appropriate place on this wiki.

==Examples of the type of email messages people might want to send==

===OU OpenMark system===

<pre>
Subject: OU online assessment confirmation - $a->quizname

Thank you for submitting your answers to:

$a->quizname

at:

$a->submissiontime

This email confirms that we have safely received your answers.

Please do not reply to this email, which was generated automatically by the
OpenMark online assessment system.
</pre>

===OU eTMA system===

<pre>
Subject: Ref: XXXXXX Receipt of assignment ($a->useridnumber $a->courseshortname $a->quizname)

Your assignment, number $a->quizname for course $a->courseshortname, was
received by the eTMA system at $a->submissiontime.

(Your receipt code is: D8CDA7B2). <--- not relevant to Moodle quiz.

Your submission included the following files: <--- not relevant to Moodle quiz.
Name (Size in Bytes)

TMA05.doc(114,688 bytes)

**********************************************************************************
The University has to ensure as far as possible that the work submitted by
students is their own and does not contain any unreferenced material from other
sources. The University statement "What constitutes plagiarism or cheating"
appears in your Assessment Handbook and you are expected to have familiarised
yourself with it. Please be aware that the University may subject your work to a
computerised check for plagiarism.

This is an automated reply from the Open University eTMA system. Please do not
reply to this email address as the mailbox is not monitored. If you have any
queries please email XXX@XXXX.
</pre>

==See also==

* [http://moodle.org/mod/forum/discuss.php?d=74185 Please discuss this proposal in this forum thread]

Element Library

2025-02-10T08:22:51Z

Sarjona:

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Element Library
|state = Specification
|tracker = https://tracker.moodle.org/browse/MDL-45770
|discussion = https://moodle.org/mod/forum/discuss.php?d=261202
|assignee = Damyon, Sam
}}
{{Abandoned|forumurl=https://moodle.org/mod/forum/discuss.php?d=261202}}
The element library will be a new admin tool that will display the output from a list of renderer methods / renderables. The target users for the tool are:
* Themers, used to test all the existing renderables in a newly developed theme
* Developers, used to see an organized list of all the renderables that can be used when building new pages (and the docs for them)

The requirements for this tool are:
* Show a list of renderables / renderer methods for a specific component
* Show the same renderable / renderer method rendered with different test data
* Show designer docs on the recommended usage of a specific element
* Allow easy testing in LTR/RTL and different screen sizes
* Direct links to the documentation for renderers / renderables
* Report on the list of renderables used by a renderable / renderer method
* Testing with different language directions

Some optional requirements:
* Perform some checks on the renderer to verify it contains no db queries etc
* Responsive testing in the tool (short-cuts to adjust the window size)

This tool will work by querying a core api for getting a list of renderer_sample_base instances from each plugin. The renderer_sample_base is an abstract class that provides documentation and an example rendering of either a renderer method or a renderable.

== How to add something to the element library (for developers) ==

Each "thing" in the element library - is rendered by an instance of a \core\output\renderer_sample_base class.

For a plugin (or core) to add a new "thing" they must:

A) Implement the tests in subclasses of "\core\output\renderer_sample_base". These classes can have any name, but it is recommended to name them as "\{plugin namespace}\output\XXX_renderer_sample". Each test must define a "execute()" method which produces the output, as well as supply developer docs, a name for the test and a category.

Note: the renderer should be able to produce it's output relying completely on the data contained in its own arguments or the renderable. If it is performing additional DB queries etc - it will probably fail when provided with "mock" data. In this situation, you should consider refactoring the renderer so it does not perform DB queries.

B) Extend the abstract class "\core\output\renderer_sample_generator_base" with a new class named "\{plugin namespace}\output\renderer_sample_generator". This class needs to extend "\core\output\renderer_sample_generator_base". There is one function to implement, which is the "create_samples" function which accepts no arguments and returns a list of subclasses of "\core\output\renderer_sample_base" (implemented in step A).

Note - the non-namespaced class name "{plugin name}_output_renderer_sample_generator" is also supported.

=== Example: Adding "Assign user summary" (TODO - change this example to a core renderable) ===

A) Add a new class "\mod_assign\output\assign_user_summary_renderer_sample" which extends "\core\output\renderer_sample_base".

This class should set the "name, docs and category" class variables in it's constructor. The "execute" method should create a "assign_user_summary" instance filled with dummy data, get a 'mod_assign' renderer and call render on the "assign_user_dummy" class.
<syntaxhighlight lang="php">
File: mod/assign/classes/output/assign_user_summary_renderer_sample.php
<?php

namespace mod_assign\output;

class assign_user_summary_renderer_sample extends \core\output\renderer_sample_base {

public function __construct() {
$this->name = 'Assign user summary';
$this->docs = 'A user summary object that is used to display information about a user in multiple places in mod_assign.';
$this->category = \core\output\renderer_sample_base::CATEGORY_COMPONENT;
}

public function execute() {
global $CFG, $PAGE;

require_once($CFG->dirroot . '/mod/assign/renderable.php');

$renderer = $PAGE->get_renderer('mod_assign');
$mockuser = guest_user();
$mockcourseid = 5;
$viewfullnames = true;
$blindmarking = false;
$mockuniqueidforuser = 5;
$mockextrauserfields = array();
$suspendeduser = false;

$renderable = new \assign_user_summary($mockuser,
$mockcourseid,
$viewfullnames,
$blindmarking,
$mockuniqueidforuser,
$mockextrauserfields,
$suspendeduser);

return $renderer->render($renderable);
}
}

</syntaxhighlight>

B) Implement the renderable_sample_generator for mod_assign
<syntaxhighlight lang="php">
File: mod/assign/classes/output/renderable_sample_generator.php
<?php
namespace mod_assign\output;

class renderer_sample_generator extends \core\output\renderer_sample_generator_base {
public function create_samples() {
$tests = array(new assign_user_summary_renderer_sample());
return $tests;
}
}

</syntaxhighlight>

== Related links ==
* [[Render library specification]]

Element HTML and CSS guidelines

2025-02-10T08:22:37Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Renderer consistency
|state = Specification
|tracker = https://tracker.moodle.org/browse/MDL-45830
|discussion = https://moodle.org/mod/forum/discuss.php?d=261202
|assignee = Damyon, Sam
}}
{{Work in progress|forumurl=https://moodle.org/mod/forum/discuss.php?d=261202}}

This is a guide to writing HTML and CSS for elements within Moodle.
In the future this will likely become the HTML and CSS guide for output in Moodle as we want to move elements. However at present we don't want to enforce this for all output, just new conversions to elements.

==Why have a strict guide==

At the time of writing this CSS within Moodle (2.7) themes is in a poor state and has been for a long time. Without previously having a guide we were finding that:

* As there was no formal guide to creating id's or classes, each developer does their own thing.
* As there was no formal guide on how to write CSS there were numerous techniques used when writing CSS and no consistency.
* Majority of pages create unique output and require unique CSS, there is very little re-use of design.

While those points may not sound bad to you consider that in following stats from Moodle 2.7 themes:

* Base theme contains 3802 rulesets with a total of 5800 styles.
* Bootstrapbase theme contains 5170 rulesets with a total of 9362 styles.
* Clean theme contains 5172 rulesets with a total of 9366 styles.
* More theme contains 5177 rulesets with a total of 9063 styles.

You get the picture, several thousand selectors containing nearly 10000 styles.

For Moodle 2.8 we committed to introducing a element library to aid the reuse of design and documenting all aspects of output including a guide on writing CSS for Moodle. This is that guide.

==Our goals==

Its very important to understand what we are trying to achieve with this style guide and output in general.

; Frontend framework agnostic : We want theme designers to be able to apply present and future frontend frameworks to Moodle with minimal effort.
; Consistent interfaces : We want Moodle to have consistency throughout its interfaces, minimising the amount of frontend design and development that is required in coding and styling an interface.
; Cleanly formatted HTML and CSS : to minimise both development time and to make our renderers and CSS and more maintainable.

We plan to faciliate these with the following:
; Elements : Highly re-usable objects to produce HTML, these will be used consistently and relied upon by developers creating interfaces. By having these elements we create a consistent look, interface creation will be much quicker and theme designers through the re-use of a limited number of elements.
; Element library : A tool to show samples of each element, this can be used to view and test designs. It aids the developer by showing them the elements they can select from when creating an interface, and it aids designers by giving them a test area that doesn't require them to dig through every page in Moodle.
; Documentation : We will now have proper documentation on all aspects of output. Including this CSS style guide, a renderer best practices guide, and a guide to creating elements.

==Where to put CSS in Moodle core==

CSS can reside in a number of locations depending upon what you are styling.

Remember it doesn't matter how many CSS files we end up with, on a production site with Theme designer mode switched off (default) all CSS files will be combined and minimised into a single file that is served to the client.
Excepting the case of IE where we must split the CSS into several smaller files to work around browser limitations.

===CSS for elements===
As we are moving to using elements you will find that CSS for elements is where most of the effort is going to go.

CSS for elements should reside within themes only, you will find that elements must be styled in all core base themes, this means at least Bootstrapbase and base.

CSS for elements should be located within either '''theme/themename/style/elements/elementname.css''' or '''theme/themename/less/elements/elementname.css'''

The actual CSS file should be named according to the element. As elements can be namespaced we need to ensure that that is reflected in the name of the file.
For instance:

{|
! Element
! CSS location in base
! CSS location in bootstrapbase
|-
| \core\output\button
| style/elements/core_output_button.css
| less/moodle/elements/core_output_button.css
|-
| \core\output\navigation_bar
| style/elements/core_output_navigation_bar.css
| less/moodle/elements/core_output_navigation_bar.css
|-
| \mod_assign\output\user_submission
| style/elements/mod_assign_output_user_submission.css
| less/moodle/elements/mod_assign_output_user_submission.css
|}

These will still need to be included in the theme, by which ever means is relevant.
If you are using ''.css'' files like the base theme does then you will use:

<syntaxhighlight lang="php">
// In your themes config.php
$THEME->sheets = array(
'elements/core_output_button',
'elements/core_output_navigation_bar',
'elements/mod_assign_output_user_submission'
);
</syntaxhighlight>

If you are using less as bootstrapbase does then you will use:
<syntaxhighlight lang="css">
/** In your primary less file **/
@import "moodle/elements/core_output_button";
@import "moodle/elements/core_output_navigation_bar";
@import "moodle/elements/mod_assign_output_user_submission";
</syntaxhighlight>

===General CSS===

This is CSS for the theme that doesn't relate to a specific element. Hopefully as we convert more and more of Moodles interfaces to use elements we should see less general CSS.

In any case nothing has changed in regards to the location of general CSS.
; CSS : If your theme is using standard CSS then it must be located within the ''style'' directory of your theme and should be in logically separated files.
; Less : If your theme is using less then it should be located in a ''less/moodle'' directory within your theme.

We recommend that you separate styles into files based upon the Moodle component being styled. Again as all CSS files get combined into a single file on production sites it doesn't matter how many files you end up with.

This would lead to files named like:
* style/core.css
* style/course.css
* style/mod_forum.css

===Where to put CSS in plugins===

It is possible in Moodle to add CSS stylesheets to all plugins (including core plugins). 
Moodle always looks for a ''styles.css'' file within your plugins directory, and it also looks for a styles_themename.css where themename is the name of the currect theme being used.

For instance the following could be added to the forum module:

* ''mod/forum/styles.css'': Used all the time.
* ''mod/forum/styles_base.css'' : Used when the user is using the base theme.
* ''mod/forum/styles_bootstrapbase.css'' : Used when the user is using the bootstrapbase theme.
* ''mod/forum/styles_clean.css'' : Used when the user is using the clean theme.

===CSS in core plugins===

For core plugins only styles.css is permitted and it should only ever contain styles essential to the presentation of the plugin. 
At present styles essential for the display of the plugin are allowed here, however when the plugin interfaces have been converted to use elements this file should be nearly empty and contain only the following:
* Images, icons and text used for visual presentation such as icons to notify state (expanded/collapsed, warnings...)
* Accessiblity orientated styles required to make the interface accessible.

'''Under no circumstances should it contain any visual stylings such as border, rounded corners, and background colours not associated with state.'''

==HTML==

The following sections detail rules in place for writing HTML.

Before we start a couple of general recommendations:

; Use hyphens rather than underscores when concatenating strings in attributes : for example ''.course-new-activity-chooser'' instead of ''.course_new_activity_chooser''. By all doing this we will have a more consistent appearance and as We use underscores as part of frankenstyle which is prominent in CSS helps us to reduce the chance of naming conflicts.
; Think semantics - but don't get caught up in it : Semantic CSS is beautiful CSS lending itself ultimately to the redesign that is going to happen. But enforcing a semantic design can be an arduous journey. Instead we encourage semantic CSS but are happy to see non-semantic CSS when it is for the greater good.

===Using the ID attribute===

The situation of having a single JavaScript driven element was considered but even then it is better to style only classes and other attributes as we can't be sure what the future holds.

There are three rules you should follow when creating an ID:

# They should only be given to elements and HTML nodes that need to be interacted with by JavaScript.
# It should always start with '''m-''' ''(see note below)''
# The actual ID should be descriptive of the node and contents as a whole unit. It must fully and concisely describe its purpose.

Keep in mind that in an ideal world ID's should not be used for styling.

'''Good'''
<syntaxhighlight lang="html5">
<div id="m-dock"> ... </div>

<div id="m-course-new-activity-chooser"> ... </div>
</syntaxhighlight>

'''Bad'''
<syntaxhighlight lang="html5">

<div id="dock"> ... </div>


<div id="m-activity-selector"> ... </div>
</syntaxhighlight>

'''Note:''' The requirement to use m- prefix is entirely new, this has been created as this instantly reduces the chances of conflicting with present and future frontend frameworks that may be adopted by core or third party themes. Aiding our goal of being frontend framework agnostic. 
It will also help reduce the chance of conflicts in any third party code that may be used either by us in core, or by outside developers in their own code.
Moodle ID's will also be much more easily recognisable which we expect will be a benefit as JavaScript use in Moodle continues to increase.

===Naming CSS classes===

This is where a bit of organisation goes a long way and we want to be reasonably thorough in a consistent naming scheme and implementation.

The very first thing to mention is that all classes in Moodle must now be prefixed by *m-*.
This instantly identifes a class as belonging to Moodle, it aids us in avoiding conflicts with any non-Moodle css that may be loaded, and it is part of our framework agnostic plan.

<blockquote>
All CSS classes must start with *m-*
</blockquote>

There are several prefix that are used within Moodle output now that should not be used as prefixs for classes unless they are serving the desired purpose.

Reserved prefixes are:

; m-element : Prefix used on element classes, where m-element preceeds the name of the element, e.g. m-element-button, m-element-search
; m-state : Prefix used for CSS classes representing the state of an item, e.g. m-state-disabled, m-state-active, m-state-expanded.
; m-grid : Prefix used for creating HTML grids.

====Elements====

Semantic design where it gives the best result, smart design where there is a better solution.

If you're not already familiar with the idea of semantic CSS then Chris Coylers artical [http://css-tricks.com/semantic-class-names/ What makes for a semantic class name] is a great starting point.

We've not commit to adopting any one strict approach for writing CSS. We have adopted atomic design for our HTML elements, a design style which fits nicely with the likes of OOCSS, however be very clear that we are not adopting the OOCSS approach in its entirety. The high level abstraction of the visual aspects of elements into highly reusable agnostic classes does not always lend itself well to the Moodle world in which the we wish to be frontend framework agnostic and support largescale completely customisable themes. 
The highly reusable classes that appeal to one designer, or to one frontend framework may not apply to another. 
This decision is also impacted by our current default theme bootstrapbase that does not use well abstracted OOCSS in its design.

Atomic design is going to see us end up with many parent child relationships in our HTML that we must carry through to our CSS. Through atomic design we start with smalled atoms and molecules that get built into larger organisms and placed within layouts.

Every element should have a single class that identifies it as element X.

For instance the button atom will have the class *m-element-button*

<syntaxhighlight lang="html5">
<button class="m-element-button">I am a button</button>
</syntaxhighlight>

This is simply the prefix "m-element" plus the element name.

The purpose of this class is to allow the element to be styled with ease. The class name should be applied to the root node for the element, it should never be applied any lower.

By having one class for the element, and always and only applied to the root node it makes it very easy in HTML to see where one element belongs to another.

The following is an example of the search molecule, which in turn contains two button atoms.
<syntaxhighlight lang="html5">
<form class="m-element-confirmation">
<h3>Are you sure?</h3>
Are you sure you want to perform this action?
<input type="submit" name="cancel" class="m-element-button" value="Cancel" />
<input type="submit" name="continue" class="m-element-button" value="Continue" />
</form>
</syntaxhighlight>

We've chosen to partially adopt BEM as a CSS standard when writing CSS for elements.

BEM stands for Block-Element-Modifer. It is a notation format for use with CSS to better describe the relationship between a component and it's constituent parts.

The notation is simple and consists of just 3 variants:

<syntaxhighlight lang="css">
.block {}
.block__element {}
.block--modifier {}
</syntaxhighlight>

* ''.block'' class represents our component e.g. .site-nav
* ''.block__element'' class represents part of our overall component e.g. .site-nav__link ('''NB:''' we use 2 underscores between the block prefix and the element suffix to distinguish it from being part of a hyphenated class name)
* ''.block--modifier'' class represents a variation in the type or state of our component e.g. .site-nav--vertical would allow us to vary the display of our navigation links. ('''NB:''' we use 2 dashes between the block prefix and the modifier suffix)

Let's apply the BEM notation to something more tangible and define a simple abstraction for a bottle component:

<syntaxhighlight lang="css">
.bottle {}
.bottle__cap {}
.bottle__label {}
.bottle__branding {} // a logo
.bottle--screwcap {} // a variation on a standard bottle
.bottle--corked {}
.bottle--empty {} // our bottle is in an empty state
.bottle--recycled {} // our bottle is in a recycled state
</syntaxhighlight>

and this might be how we would markup our bottle component:

<syntaxhighlight lang="html5">

<div class="bottle">
<header class="bottle__cap"></header>
Natural Spring Water
<img class="bottle__branding" />
</div>


<div class="bottle bottle--corked">
<header class="bottle__cap"></header>
Cheap plonk!
<img class="bottle__branding" />
</div>


<div class="bottle bottle--corked bottle--empty">
<header class="bottle__cap"></header>
The good stuff!
<img class="bottle__branding" />
</div>

</syntaxhighlight>

So you can see, using BEM notation, we can be very expressive in the definition of the elements that make up our pages. And as an added bonus, we are
building up a repository of components that we can reuse elsewhere in our pages.

Lets say for the purposes of this example that our bottle component includes a list of ingredients. We don't need anything fancy, just a regular old list with all the default formatting removed:

<syntaxhighlight lang="css">
.list-bare {
// remove default bullets, margin and padding!
}
</syntaxhighlight>
This kind of list sounds like something we could use elsewhere, so instead of defining it as part of our bottle component, lets make it a standalone component:

<syntaxhighlight lang="html5">

<div class="bottle bottle--corked">
<header class="bottle__cap"></header>
The good stuff!
<img class="bottle__branding" />
<h3>Ingrediants</h3>
<ul class="list-bare">
<li>Lots of Grapes</li>
<li>A dash of Yeast</li>
<li>A whole lot of love</li>
</ul>
</div>

</syntaxhighlight>

Now, when we need to use a simple unstyled list, we have a component to do just that. The longer you work with BEM notation, the more aware you become of the potential reuse of your components and size of your stylesheets become smaller and more manageable.

You'll notice in the example a little further up that there is no way to style the continue button differently from the cancel button without relying on its name attribute, something we certainly don't want to do.
The BEM standard comes into play here in naming the classes, the following shows how you would apply BEM to show the purpose of each button in a way that can be easily interpreted and styled in CSS. We will add additional classes to our 2 input elements to set them apart from standard buttons. You can consider ''m-element-button'' as a base class upon which we can build many variants for different purposes.

<syntaxhighlight lang="html5">
<form class="m-element-confirmation">
<h3 class="m-element-confirmation__title">Are you sure?</h3>
Are you sure you want to perform this action?
<input type="submit" name="cancel" class="m-element-button '''m-element-button--cancel'''" value="Cancel" />
<input type="submit" name="continue" class="m-element-button '''m-element-button--continue'''" value="Continue" />
</form>
</syntaxhighlight>

By including the class name for ''m-element-button--continue'' one of our form buttons assumes the additional styles we defined for our form's primary action.

Now to explain the idea of intent.
An intent is when a single element takes on a different apprearance to convey a specific meaning. A little bit like a state, but with more meaning.
An easy example is notifications where you will no doubt be familiar with the idea of having a error notifications, warning notifications, success notification etc. Each of error, warning, and success is a intent.

The following shows how this would work:
<syntaxhighlight lang="html5">

<div class="m-element-notification">You have not changed your password in the past 60 days</div>


<div class="m-element-notification m-element-notification--warning">You have not changed your password in the past 60 days</div>
</div>
</syntaxhighlight>

====Grids====

We need to adopt a single grid framework.

Personally I don't think we should use pure bootstrap or pure YUI, instead we should choose one of these and build it use our class name structures.

All grid classes should start with m-grid.

==CSS==

Before we begin lets lay down some ground level goals, things that will help us achieve clear and understandable CSS in the future.
* Formatting, ordering, alignment, and spacing are all important in having CSS that can be easily read by others.
* Don't optimise your CSS, be verbose and stick to the styles in this guide. We have tools that will handle optimisation for you.
* Never use *!important* in your CSS unless it is absolutely impossible to avoid doing so.

===Terminology===

Its important that when we are speaking about CSS we are speaking the same language.
Lets look at the following example:

<syntaxhighlight lang="css">
.m-page .m-selector-1,
.m-page .m-selector-2,
.m-page .m-selector-3 {
background-color: #FFF;
color: #000;
}

.m-selector-1 {
margin: 1em;
}
</syntaxhighlight>

; Ruleset : Each of the two rules is a single *ruleset*.
; Rule: _.m-page .m-selector-1_ is a rule.
; Selector : _.m-selector-1_ is a *selector*, it is a single part of a rule.
; Declaration : _background-color: #FFF_ is a declaration.
;

===Essential formatting===

The following are the guies for writing CSS.

* Always use spaces - never use tabs. All editors can be configured to do it.
* Indent by 4 spaces - never more, never less.
* A single empty line between rulesets to maintain consistent spacing of rules.
* One rule per line.
* A single space between each selector in a rule.
* No space between a rule and the comma in a ruleset.
* A single space between a selector and the opening brace of a ruleset.
* One level of indentation before each declaration.
* A single space the colon in a declaration.
* A single space after each item in a declaration containing multiple items.

The following shows how the above rules apply:
<syntaxhighlight lang="css">
.m-selector-1,
.m-selector-2 .m-selector-3 {
background: #ffa800 url("background.png") no-repeat right top;
border: 1px solid #000;
display: inline-block;
font-family: arial, sans-serif;
margin: 5px 10px;
padding: 0;
}

.m-selector-4 {
border-radius: 3px;
}
</syntaxhighlight>

===General rules===

Declaration ordering is the very first thing to discuss. There is no strict rule on how to order your declarations, however there is a recommendation.
We recommend that you order declarations within a ruleset alphabetically.
If we all start doing this then when you read CSS written by someone else you will soon learn to very quickly find your way around the declarations within a rule.
<syntaxhighlight lang="css">
/** Recommended **/
.m-selector {
background-color: #fff;
border: 1px solid #000;
color: #000;
display: block;
margin: 5px;
padding: 5px;
}
</syntaxhighlight>

Do not use a measurement unit when writing a 0 value.
<syntaxhighlight lang="css">
/** Good **/
.m-selector {
margin: 5px 0;
}

/** Bad **/
.m-selector {
margin: 5px 0px;
}
</syntaxhighlight>

Use lowercase and shorthand values for colours.
<syntaxhighlight lang="css">
/** Good **/
.m-selector {
background-color: #fff;
}

/** Bad **/
.m-selector {
background-color: #ffffff;
}
.m-selector {
background-color: #FFFFFF;
}
.m-selector {
background-color: white;
}
</syntaxhighlight>

Always quote variable values.
<syntaxhighlight lang="css">
/** Good **/
.m-selector[attr="variable"] {
background-image: url("image.png");
}

/** Bad **/
.m-selector[attr=variable] {
background-image: url(image.png);
}
</syntaxhighlight>

===Commenting===

Always comment your CSS and Less.

<syntaxhighlight lang="css">
/**
* Styles for the button atom.
*/
.m-element-button {
}
</syntaxhighlight>

===Rules and exceptions for less===

Need to write some guff on Less.

==See also==
* [[Render library specification]] - The original output specification for Moodle 2.8
* [[Output element planning]] - Thoughts on initial elements that should be created.
* [[Guide to creating output elements]]
* [[Renderer best practices]]
* [[Element HTML and CSS guidelines]]

Editors

2025-02-10T08:21:55Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

==Overview==

It's possible to add new editors to Moodle and replace or augment TinyMCE.

==Add a new Editor to Moodle==

The editor is a plugin used by Moodle that we can find in the Moodle source files folowing the path /lib/editor/

Moodle tipically uses the [http://www.tinymce.com/ TinyMCE editor], but other editors can be installed in Moodle.

We can find [https://moodle.org/plugins/browse.php?list=category&id=23 other editors] that can be installed in Moodle.

==TinyMCE==

TinyMCE is an platform-independent web-based JavaScript/HTML WYSIWYG editor control, used as the main Moodle editor plugin.

===Augmenting TinyMCE===

Specific Moodle TinyMCE plugins can be created in order to augment TinyMCE functionalities.

[https://docs.moodle.org/dev/Creating_a_Moodle_specific_TinyMCE_plugin Here] you will find some tips of how to create your own button, a Moodle specific TinyMCE plugin.

TODO: Finish this page.

[[Category:Plugins]]

Editor file management

2025-02-10T08:21:43Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

This document is a specification that describes how how the handling of embedded media and attachments will work with and around the editor in Moodle 2.0.

==Embedding media in a text==

Embedded media includes images, videos and sounds that are embedded within a single given HTML text. These are added using the HTML editor (which in Moodle 2.0 is a modified version of TinyMCE) and stored in the "file area" associated with the text. This applies to all HTML texts in Moodle 2.0, ranging from simple forum posts to full pages in the Resource module. These files can be stored in one flat virtual folder, they do not need to be in sub-directories.

The basic procedure for embedding an image is:

* Click on the image button in the editor
* Click on the "Choose..." button in the editor dialog
* Use Filepicker to select the file from a repository (or recent files, or upload) with a name
* IF A FILE WITH THAT NAME ALREADY EXISTS THEN ALTER THE NAME IN MOODLE (eg file.jpg --> file2.jpg)
* Add metadata and preferences in the editor dialog
* Insert the image into the text

(This procedure is almost identical for video and audio files as well)

Note: Like most operating system "Open file" dialogs, the filepicker only shows those media types that you are searching for at that time. For example, if you are looking for video files then repositories which don't support video files are not shown, and only video files are shown in the remaining repositories (even if other files may be there).

[[Image:Adding_an_image.png]]

(click on this diagram to see the full-sized version of this example)

==Attaching files==

Attached files are for whenever you have a set of files that you want to store and display. These include forum attachments, assignment submissions, and resource files (including whole mini web-sites). Attachments need to support subdirectories and require more file management.

The file manager form element is designed for this.

* Click on "Add" in the file manager form element
* Select a file from a repository (or upload)
* File is added

This is what the new "file manager" form element will look like in a Moodle form (example is from the "File" resource module):

[[Image:Filemanager.png]]

A second separate menu under the file manager allows you to pick a "main" file for this case.

==Components to build==

===Recent files repository===

Displays a complete paged history of all the files uploaded by the current user, sorted from newest to oldest.

===File manager===

====AJAX version====

The default interface shows the "root" of the file area (screenshots from MDL-16597):

http://tracker.moodle.org/secure/attachment/18132/File+manager+interface+%28on+root%29.png

And once you click on any folder you can go down in the tree:

http://tracker.moodle.org/secure/attachment/18130/File+manaager+interface+%28on+subdir%29.png

When moving a file or folder, you get a little popup browser to choose the destination.

http://tracker.moodle.org/secure/attachment/18128/moving+file+interface.png

====Non-JS version====

(spec to come)

==Discussion==

Discussion: [http://moodle.org/mod/forum/discuss.php?d=127238 RFC: Editor file management in Moodle 2.0]
Discussion document: [https://docs.moodle.org/en/index.php?title=Development:Editor_file_management&oldid=60871 August 3 version of this page]

Draft

2025-02-10T08:21:02Z

Sarjona:

{{Template:WillNotMigrate}}

A draft is an early version of a document that is not yet complete.

[[es:Borrador]]

Development data generator

2025-02-10T08:17:50Z

Sarjona:

{{Template:WillNotMigrate}}

{{Work in progress}}

The development data generator tool replaces the previous tool_generator (admin/tool/generator) in Moodle 2.6. It has also been backported (without removing the old one) to Moodle 2.5 as the current Moodle 2.5 tool_generator is not usable.

It contains multiple features to help generate data for development or testing purposes.

# [[Test course generator]]
# [[Test site generator]]
# [[JMeter test plan generator]]

Developer meeting April 2013

2025-02-10T08:17:31Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

Developer meeting April 2013

[[Developer meetings]] > April 2013 meeting notes

{| class="wikitable"
|-
| Time
| [http://timeanddate.com/worldclock/fixedtime.html?year=2013&month=4&day=23&hour=13&min=0&sec=0 13:00 UTC on Tuesday, 23 April 2013]
|-
| Meeting room
| [http://www.youtube.com/moodlehq Moodle YouTube channel]
|-
| Chat
| [https://moodle.org/local/chatlogs/info.php Regular Dev chat]
|-
| Twitter
| [https://twitter.com/search?q=%23moodledev #moodledev]
|}

In this meeting we focused on the impending Major release.

== Meeting video ==

<mediaplayer>http://www.youtube.com/watch?v=qTQyyE7dod4</mediaplayer>

== Meeting notes ==

===[https://docs.moodle.org/dev/images_dev/d/d3/hq-teams.pdf News from Moodle HQ] (Martin Dougiamas)===
* New HQ teams are being formed: Front-end, back-end, sites
* New focus and priorities in teams

===[[Moodle_2.5_release_notes|Moodle 2.5]]===
====[https://docs.moodle.org/25/en/New_features New features page]====
* Complements release notes
* Updated for every release
* Screenshots and quick overview
* The page to link to when sharing upcoming features

====[[OpenBadges_User_Documentation|Open Badges]] (Simon Coggins and Yuliya Bozhko)====
* Initiative from Mozilla for achievements across the Web
* Awards a badge that is an image but also a verifiable certificate
* Moodle can award badges and show badges from other sites
* Test site at <s>[http://openbadgestotara.elearning.catalyst.net.nz openbadgestotara.elearning.catalyst.net.nz]</s> Now decommissioned, use demo.moodle.net instead.
* Badges can be awarded at site-wide or course levels
* Create a badge in a course from the Admin menu and provide an image
* Awarded based on completion of course or activity
* Awards can be shared and connected to the Mozilla Backpack
* Mahara may become a Backpack provider in future

====[http://tracker.moodle.org/browse/MDL-38016 Bootstrap themes] (Martin Dougiamas)====
* Framework for responsive sites
* Now a new base theme for a new family of themes
* Will replace current base themes in future
* Not be the default theme in Moodle yet

====[http://tracker.moodle.org/browse/MDL-38509 Installation of new plugins from moodle.org] (David Mudrak)====
* Admin tool in Moodle
* Plugins found in the Directory can be downloaded, validated and installed
* Downloaded zip files can be installed and uninstalled from within Moodle without file access

====[http://tracker.moodle.org/browse/MDL-30637 Short forms] (Ruslan Kabalin and Frédéric Massart)====
* Forms are broken into sections that can collapse
* Fieldsets with required fields, non-validating fields and forced open
* Developers should review all their forms to see that they still make sense
* Editor can be simplified to hide editor toolbars

====[http://tracker.moodle.org/browse/MDL-37009 Consistent course listing display] (Marina Glancy)====
* Course listings are now rendered consistently
* Themes will be affected by this, but theming should be more consistent in the future

====[http://tracker.moodle.org/browse/MDL-15727 jQuery and jQuery UI supported in add-ons] (Petr Škoda)====
* JQuery library now available for plugins
* Not use by core

====[https://tracker.moodle.org/browse/MDL-37127 Shifting our YUI] (Andrew Nicols)====
* [[Javascript/Shifter]]
** Should help to improve documentation and allow unit tests
** JS can be linted for possible errors

====[http://tracker.moodle.org/browse/MDL-35611 Behat tests] (David Monllaó)====
* [[Acceptance testing]]
* Human readable test instructions
* Tests can be run automatically in a browser
* About 100 QA tests have been now automated (more to come) https://tracker.moodle.org/browse/MDLQA-5249
* Some assistance for test writers is provided by a Developer tool in Moodle 2.5
* [https://github.com/marinaglancy/moodle-tool_behatui Behat screenshotting tool]

====[https://tracker.moodle.org/issues/?jql=fixVersion%20in%20(%222.5%22)%20and%20component%20in%20(Assignment)%20and%20type%20%3D%20Improvement Assignment changes in 2.5] (Damyon Wiese)====
* Assignment code now validates with code checker
* More unit tests have been added
* Docs have been updated
* New feature: submission history
** Reattempts (manual or automatic)

===[[Moodle_Mobile_Release_Notes | Mobile app]] (Juan Leyva)===
* New version released with a more versions planned every two months
* App can be styled
* Push notifications to come

===[[GSOC|GSoC]] (Michael de Raadt)===
* Moodle has been accepted as a participating organisation
* Students are starting to submit applications to participate with Moodle
* Students may be found in forums now and in the future

==Attendees==
Adrian Greeve, Amy Groshek, Andrew Nicols, Ankit Agarwal, Anthony Borrow, Aparup Banerjee, Barbara Ramiro, Bas Brands, Damyon Wiese, Dan Poltawski, Daniele Cordella, Darryl Pogue, David Monllaó, David Mudrak, Davo Smith, Eloy Lafuente, Frédéric Massart, Gareth J Barnard, Helen Foster, Howard Miller, Jason Fowler, Jason Hardin, Jenny Gray, Jérôme Mouneyrac, Juan Leyva, Justin Filip, Marina Glancy, Mark Nelson, Martin Dougiamas, Mary Cooch, Mary Evans, Michael Blake, Michael de Raadt, Mike Churchward, Peter Bulmer, Petr Skoda, Rajesh Taneja, Rex Lorenzo, Sam Hemelryk, Sam Marshall, Tim Hunt, Watermark Neilsen, Yuliya Bozhko... (plus many more via YouTube and Twitter)

==Meeting chat log==
<div style="height:300px;overflow:auto;">
{| class="wikitable"
|-
| Moodle HQ
| ok we are going live
| 9:01:28 PM
|-
| Moodle HQ
| can you see us ok?
| 9:01:32 PM
|-
| mary
| yes
| 9:01:47 PM
|-
| Gareth J Barnard
| Yup
| 9:01:47 PM
|-
| Aparup Banerjee
| roger that
| 9:01:49 PM
|-
| Rajesh Taneja
| yes
| 9:01:49 PM
|-
| Juan Leyva
| yes
| 9:01:59 PM
|-
| Davo Smith
| yes
| 9:02:04 PM
|-
| Gareth J Barnard
| Hello all
| 9:02:14 PM
|-
| David Mudrák
| I'm lost
| 9:02:17 PM
|-
| David Mudrák
| shouldn't get an invatation to the hangout?
| 9:02:31 PM
|-
| Jason Fowler
| its working here
| 9:02:38 PM
|-
| Juan Leyva
| juanleyvadelgado@gmail.com
| 9:02:56 PM
|-
| Aparup Banerjee
| the youtube stream is really good here
| 9:03:36 PM
|-
| Ankit Agarwal
| yeah no lag and clear
| 9:03:55 PM
|-
| Dan Poltawski
| anyone get youtube on ipad?
| 9:04:09 PM
|-
| Jason Fowler
| and it.crashed...
| 9:04:17 PM
|-
| Helen Foster
| is michaeld writing notes?
| 9:04:29 PM
|-
| Jason Fowler
| trying on android
| 9:04:29 PM
|-
| Andrew Nicols
| hello
| 9:05:13 PM
|-
| Tim Hunt
| Hi
| 9:05:14 PM
|-
| Mark Nielsen
| Hello all
| 9:05:14 PM
|-
| Rajesh Taneja
| Hello
| 9:05:14 PM
|-
| Sam Hemelryk
| Hiya
| 9:05:15 PM
|-
| Davo Smith
| Hello
| 9:05:15 PM
|-
| Gareth J Barnard
| Hi
| 9:05:16 PM
|-
| Dan Poltawski
| lo
| 9:05:17 PM
|-
| Anthony Borrow
| hi
| 9:05:18 PM
|-
| bmbrands
| hi there
| 9:05:18 PM
|-
| Juan Leyva
| hello
| 9:05:19 PM
|-
| Ankit Agarwal
| hi
| 9:05:20 PM
|-
| Aparup Banerjee
| bye
| 9:05:23 PM
|-
| David Mudrák
| hi
| 9:05:26 PM
|-
| Jenny Gray
| hello
| 9:05:29 PM
|-
| Mark Nielsen
| We have some other folks from Moodlerooms watching as well
| 9:05:46 PM
|-
| Mark Nelson
| hi
| 9:05:48 PM
|-
| mary
| hello!
| 9:05:49 PM
|-
| bmbrands
| hi
| 9:05:56 PM
|-
| Jason Fowler
| can't get it working again
| 9:06:34 PM
|-
| Tim Hunt
| Moodle HQ is a jelly-fish. Suddeny it all makes sense.
| 9:07:16 PM
|-
| Aparup Banerjee
| lol
| 9:08:44 PM
|-
| Andrew Nicols
| heh
| 9:08:47 PM
|-
| bmbrands
|
| 9:08:48 PM
|-
| Gareth J Barnard
| :D
| 9:08:51 PM
|-
| Andrew Nicols
| Nice bit of recursion in the bottom right there
| 9:08:53 PM
|-
| Mary Evans
| is there no Hangout?
| 9:09:23 PM
|-
| Tim Hunt
|
| 9:09:29 PM
|-
| Sam Hemelryk
| Sorry about that not getting there in the end
| 9:12:05 PM
|-
| Andrew Nicols
| Martin: A couple of people asking in comments about how to get invites to the hangout. May be worth re-mentioning #moodledev and here again
| 9:12:28 PM
|-
| Aparup Banerjee
| David, hope you got your google hangout email
| 9:14:00 PM
|-
| David Mudrák
| no
| 9:14:17 PM
|-
| David Mudrák
| that's why I asked for it. I expect MD will add/remove people as needed to keep traffic low
| 9:15:04 PM
|-
| Aparup Banerjee
| clearly
| 9:15:07 PM
|-
| bmbrands
| yes
| 9:15:09 PM
|-
| Gareth J Barnard
| Yes
| 9:15:12 PM
|-
| Rajesh Taneja
| yes
| 9:15:12 PM
|-
| mary
| yes
| 9:15:14 PM
|-
| Yuliya Bozhko
| here
| 9:15:25 PM
|-
| Dan Poltawski
| (wow i'm seemingly lagging behind by quite a way)
| 9:15:28 PM
|-
| Moodle HQ
| waves
| 9:15:36 PM
|-
| Ankit Agarwal
| yeah me too as well
| 9:15:39 PM
|-
| Aparup Banerjee
| Hi Yuliya
| 9:15:49 PM
|-
| Andrew Nicols
| Moodle Meetings: Few people asking about where chat is
| 9:16:01 PM
|-
| Marina Glancy
| ÐŸÑ€Ð¸Ð²ÐµÑ‚ Ð®Ð»Ñ
| 9:16:02 PM
|-
| Dan Poltawski
| yep
| 9:16:32 PM
|-
| Dan Poltawski
| (hehe I am responding to stuff which seemingly happened ages ago)
| 9:16:44 PM
|-
| Tim Hunt
| Dan, reload the you-tube page?
| 9:17:03 PM
|-
| Dan Poltawski
| then i'll miss some!
| 9:17:12 PM
|-
| Moodle HQ
| David, invited you again
| 9:17:14 PM
|-
| David Mudrák
| what email did you use? Got nothing
| 9:17:36 PM
|-
| Mark Nelson
| Have you tried to click on the 'Live' wording on the video?
| 9:17:38 PM
|-
| Dan Poltawski
| just tried it
| 9:17:45 PM
|-
| Moodle HQ
| what would you like David?
| 9:17:50 PM
|-
| Tim Hunt
| open2study, the Australian MOOC platform, has crazy numbers of badges for really trivial things.
| 9:18:32 PM
|-
| Tim Hunt
| LOL
| 9:19:24 PM
|-
| Dan Poltawski
| i'm just seeing simon doing the demo now. How far behind am I?
| 9:19:27 PM
|-
| Tim Hunt
| How long was that URL?
| 9:19:28 PM
|-
| Aparup Banerjee
| can't wait for openbadges on moodle.org
| 9:19:44 PM
|-
| Moodle HQ
| Yes, helen you should start plannig some
| 9:19:58 PM
|-
| Aparup Banerjee
| it just switched to the moodlesite for me 10 secs ago
| 9:20:00 PM
|-
| Ankit Agarwal
| Dan P: a few seconds assuming am not lagging myself
| 9:20:05 PM
|-
| Dan Poltawski
| thanks
| 9:20:20 PM
|-
| Rex Lorenzo
| this is the url: http://openbadgestotara.elearning.catalyst.net.nz/
| 9:20:21 PM
|-
| Moodle HQ
| for us simon just started talking about site/course badges
| 9:20:28 PM
|-
| Anthony Borrow
| I wonder if MoodleRooms is working on a Common Core -> OpenBadges ecosystem
| 9:20:33 PM
|-
| Dan Poltawski
| Rex" looks like it
| 9:20:45 PM
|-
| Yuliya Bozhko
| https://docs.moodle.org/dev/OpenBadges_User_Documentation - documentation that has links to our test site with accounts you can use to try out badges
| 9:21:35 PM
|-
| Mark Nielsen
| @aborrow We are not working on that atm
| 9:21:38 PM
|-
| Moodle HQ
| 66 viewers on Youtube
| 9:21:57 PM
|-
| Jason Fowler
| @@
| 9:22:02 PM
|-
| Aparup Banerjee
| 41 in here
| 9:22:14 PM
|-
| Dan Poltawski
| 10 of those are mine
| 9:22:17 PM
|-
| Ankit Agarwal
| lol
| 9:22:40 PM
|-
| Rex Lorenzo
| Is there a login we can use to access the demo site?
| 9:24:37 PM
|-
| Dan Poltawski
| Rex: pretty sure it was posted on the forums
| 9:25:00 PM
|-
| Yuliya Bozhko
| it's in the docs
| 9:25:00 PM
|-
| Dan Poltawski
| looking
| 9:25:01 PM
|-
| Rex Lorenzo
| Got it
| 9:25:12 PM
|-
| Dan Poltawski
| Rex: you can also download and install 2.5
| 9:25:27 PM
|-
| Rex Lorenzo
| But you need to setup an open badge API
| 9:26:23 PM
|-
| Andrew Nicols
| Just seen the time at the top of Simon's laptop
| 9:26:26 PM
|-
| Rex Lorenzo
| Oh.. I can just use the default settings I guess
| 9:26:43 PM
|-
| mary
| wow yes Wed 1.25 am
| 9:26:57 PM
|-
| Yuliya Bozhko
| yeah, 1am here
| 9:26:59 PM
|-
| mary
| UK/Europe has the best time
| 9:27:12 PM
|-
| Moodle HQ
| Thanks Kiwis
| 9:27:15 PM
|-
| Aparup Banerjee
| youtube live streams can be played back again right
| 9:28:21 PM
|-
| Mark Nelson
| Rex: You can create badges without syncing them with Mozilla.
| 9:28:22 PM
|-
| Dan Poltawski
| hope you didn't have to come home from moodle moot party early
| 9:28:36 PM
|-
| Yuliya Bozhko
| nope, we have another person from out team presenting there
| 9:29:05 PM
|-
| Andrew Nicols
| FYI Stacey Walker @ Catalyst Europe is working on a Persona auth integration for moodle
| 9:30:39 PM
|-
| Aparup Banerjee
| does this integrate with oauth for moodle?
| 9:30:52 PM
|-
| Yuliya Bozhko
| I don't think so
| 9:31:41 PM
|-
| Dan Poltawski
| its not really the same
| 9:31:55 PM
|-
| bmbrands
| would be cool to have users compete for a badge
| 9:31:57 PM
|-
| Andrew Nicols
| bmbrands, like employee of the month stype thing?
| 9:32:26 PM
|-
| Aparup Banerjee
| Dan P: what do you mean?
| 9:32:44 PM
|-
| bmbrands
| @a.nicols: yes why not
| 9:33:02 PM
|-
| Andrew Nicols
| And "Top five contributors" type stuff
| 9:33:31 PM
|-
| Jenny Gray
| could be useful for reputation management stuff - a bit like our useful moodlers group too
| 9:34:06 PM
|-
| Dan Poltawski
| great work!
| 9:34:16 PM
|-
| Yuliya Bozhko
| thanks
| 9:34:32 PM
|-
| mary
| thanks Yuliya
| 9:34:44 PM
|-
| Mark Nielsen
| Do you loose course badges if a course is deleted?
| 9:35:15 PM
|-
| Ankit Agarwal
| isnt the badges like a permanent thing? can they be taken away?
| 9:35:43 PM
|-
| Yuliya Bozhko
| no, you don't, all issued badges belong to users
| 9:35:48 PM
|-
| Aparup Banerjee
| does it have to be synced/sent to external site?
| 9:36:06 PM
|-
| Aparup Banerjee
| (regularly)
| 9:36:14 PM
|-
| Yuliya Bozhko
| no, you don't have to use anything if you don't want them in Mozilla backpack
| 9:36:40 PM
|-
| bmbrands
| suddenly I feel like having a pizza
| 9:36:51 PM
|-
| Andrew Nicols
| Funny that
| 9:37:06 PM
|-
| Aparup Banerjee
| thanks yuliya
| 9:37:20 PM
|-
| Rex Lorenzo
| How difficult is it to maintain 2 core themes now? Is the goal to eventually move to bootstrap as the single core theme?
| 9:37:27 PM
|-
| Tim Hunt
| Yes
| 9:37:36 PM
|-
| Yuliya Bozhko
| Someone asking on Twitter: If a course disappears is the badge revoked? Answer: No, there is no such thing as revocation of badges at the moment. I think Mozilla team is working on it, but currently an issued badge cannot be revoked.
| 9:40:20 PM
|-
| Mark Nielsen
| Is bootstrap being used for the layouts as well? EG: the columns for blocks, etc
| 9:40:22 PM
|-
| bmbrands
| watermark: yes using bootstrap grids
| 9:40:46 PM
|-
| Rex Lorenzo
| Yuliya, will the badge still be verified as being valid?
| 9:41:03 PM
|-
| bmbrands
| Bootstrap can be used for plugin development too.
| 9:41:26 PM
|-
| Amy Groshek
| Thanks everyone for your hard work on bootstrap!
| 9:41:34 PM
|-
| bmbrands
| Not in the hangout
| 9:41:40 PM
|-
| Gareth J Barnard
| When will the folder name 'bootstrap' be changed to 'bootstrapbase'?
| 9:41:49 PM
|-
| Mark Nielsen
| @bmbrands what do you mean in regards to plugin dev?
| 9:41:57 PM
|-
| Rex Lorenzo
| Should we bring up the less/sass issue?
| 9:41:58 PM
|-
| Jason Hardin
| will the core renderers be rewritten to match bootstrap?
| 9:42:02 PM
|-
| Jason Hardin
| or will they continue to be overridden by bootstrap?
| 9:42:11 PM
|-
| Gareth J Barnard
| Thanks Martin
| 9:42:16 PM
|-
| Rex Lorenzo
| https://tracker.moodle.org/browse/MDL-38160
| 9:42:25 PM
|-
| bmbrands
| I'll be presenting about "beyond bootstrap" on the iMoot
| 9:42:38 PM
|-
| Rex Lorenzo
| Very much like YUI shifter in terms of the new dev workflow
| 9:43:03 PM
|-
| Tim Hunt
| JAson, the way it was summarised to me: where there are sensible changes, like adding a consistent class name to all cancel buttons, they will be done in core. WHere it is a bit bootstrap-specific then it will not be done in core.
| 9:43:13 PM
|-
| Amy Groshek
| @Rex has a good point; there is a less vs sass discussion going on there
| 9:43:21 PM
|-
| Andrew Nicols
| cue questions about what Shifter is ;)
| 9:43:28 PM
|-
| Gareth J Barnard
| There is a FireBug addon called FireLess that can be used for debugging Less.
| 9:43:42 PM
|-
| Jason Hardin
| will the be used for icons?
| 9:44:01 PM
|-
| mary
| who are just out of the picture in the Moodle meeting room?
| 9:44:06 PM
|-
| Tim Hunt
| Jason, that one is insane, I think.
| 9:44:12 PM
|-
| Jason Hardin
| meaning moving towards the use of css icons?
| 9:44:19 PM
|-
| bmbrands
| Bootswatches are worth mentioning too
| 9:44:31 PM
|-
| Amy Groshek
| Yes, what is the timeline for bootswatch import?
| 9:44:50 PM
|-
| Aparup Banerjee
| can a plugin that uses bootstrap+less be used with a theme that isn't based on bootstrap?
| 9:44:57 PM
|-
| bmbrands
| variables and css
| 9:45:07 PM
|-
| bmbrands
| very easy to us
| 9:45:20 PM
|-
| mary
| ah thanks
| 9:45:31 PM
|-
| marxjohnson00
| Aparup Yes, but it wouldn't get the bootstrap styling
| 9:45:38 PM
|-
| bmbrands
| aparup: depends, if you want to use javascript elements no.
| 9:45:55 PM
|-
| Marina Glancy
| afaik less has to be compiled anyway
| 9:46:06 PM
|-
| Gareth J Barnard
| I think you can used Less to generate any css either pre-compiled or client side with JS on the fly.
| 9:46:26 PM
|-
| Aparup Banerjee
| ie: new plugin with styles.css using less + moodle site with old theme that isn't based on bootstrap.
| 9:46:58 PM
|-
| Aparup Banerjee
| ah thanks Bas
| 9:47:03 PM
|-
| Andrew Nicols
| Will the new moodle.org (theme) be based on the new bootstrap theme?
| 9:47:06 PM
|-
| Amy Groshek
| Yes, .less files are not loaded live by the theme. It's more a matter of the development workflow.
| 9:47:08 PM
|-
| Anatai
| both less and scss need to be compiled to css, but less can also be interpreted client side (slower) for testing
| 9:47:09 PM
|-
| Amy Groshek
| You can do it client side but that's not a good idea for a live site.
| 9:47:22 PM
|-
| Andrew Nicols
| not yet
| 9:48:05 PM
|-
| bmbrands
| No only pizaa
| 9:48:06 PM
|-
| Aparup Banerjee
| no screen
| 9:48:06 PM
|-
| Andrew Nicols
| yup
| 9:48:07 PM
|-
| Tim Hunt
| I can see Martin eating Pizza
| 9:48:10 PM
|-
| Aparup Banerjee
| got it
| 9:48:10 PM
|-
| Gareth J Barnard
| But you can tinker client side with FireLess and then use 'recess' when happy for production.
| 9:48:12 PM
|-
| Tim Hunt
| Git it now.
| 9:48:13 PM
|-
| bmbrands
| ah yes
| 9:48:13 PM
|-
| Dan Poltawski
| yep
| 9:48:20 PM
|-
| Rajesh Taneja
| yes
| 9:48:21 PM
|-
| Gareth J Barnard
| @Bas Is there still more testing to do on Bootstrap in 2.5?
| 9:48:56 PM
|-
| mary
| yes
| 9:48:58 PM
|-
| Amy Groshek
| I'm not sure that tinkering is necessary when you can set recess to watch all of your less files for changes and automatically recompile your css.
| 9:49:06 PM
|-
| Justin Filip
| Again, similar to Shifter, as Andrew mentioned earlier. =)
| 9:49:21 PM
|-
| Gareth J Barnard
| @Amy but with FireLess you can debug client side to understand where to make the changes.
| 9:49:50 PM
|-
| bmbrands
| gjbarnard: not too much, but testing with addon plugins would be interesting
| 9:50:11 PM
|-
| Aparup Banerjee
| just notices G+ watermark on video
| 9:50:12 PM
|-
| Gareth J Barnard
| @Bas Ta, I can make a start with the course format's I'm responsible for,
| 9:50:42 PM
|-
| Dan Poltawski
| :D
| 9:51:26 PM
|-
| Dan Poltawski
| this is awesome
| 9:51:32 PM
|-
| bmbrands
| That would be very helpful, I think bootstrap would be very interesting for creating new courseformat too using bootstrap javascript
| 9:51:49 PM
|-
| Gareth J Barnard
| @Bas Interesting concept - what sort of layout do you have in mind?
| 9:52:30 PM
|-
| Amy Groshek
| Just discovered the "Large player" button on the youtube stream (hides youtube chat and makes video larger)
| 9:52:31 PM
|-
| marxjohnson00
| What sever setup is required for this plugin installation to work over and above what's already required by Moodle?
| 9:52:34 PM
|-
| Tim Hunt
| If malicious functions are used, I hope this woudl not get into teh plugins DB!
| 9:52:38 PM
|-
| Jenny Gray
| install adins: does it warn or could you set it to fail if the plugin isn't MATURITY_STABLE?
| 9:52:52 PM
|-
| Dan Poltawski
| marxjohnson00: shouldn't be anything unusual
| 9:52:59 PM
|-
| Dan Poltawski
| (same as repsoitory plugins etc)
| 9:53:06 PM
|-
| Rex Lorenzo
| If you delete a plugin, does it now delete the files? Before Moodle would tell you that you need to delete the files yourself
| 9:53:11 PM
|-
| Anthony Borrow
| @timhunt - yes I would like to see some type of warning/notice about installing plugins
| 9:53:11 PM
|-
| Mark Nielsen
| Would this installer find dependencies?
| 9:53:21 PM
|-
| Gareth J Barnard
| @Bas PMme with idea's and I'd be glad to help with a new course format.
| 9:53:22 PM
|-
| Rex Lorenzo
| It should, plugins can define dependancies
| 9:53:37 PM
|-
| marxjohnson00
| Dan P: Does it store them in moodledata dir then?
| 9:53:39 PM
|-
| bmbrands
| @gareth: sure, lets focus on this stuff by David
| 9:53:54 PM
|-
| Anthony Borrow
| @jennygray - we do this with core, it seems consistent to provide a similar warning of beta quality or less for plugins
| 9:53:54 PM
|-
| Justin Filip
| Does this support pulling in packages from a source other than moodle.org ?
| 9:53:56 PM
|-
| Dan Poltawski
| marxjohnson00: ah, no. You need to allow the webserver to write the plugin directories
| 9:53:58 PM
|-
| marxjohnson00
| right
| 9:54:02 PM
|-
| marxjohnson00
| cheers
| 9:54:04 PM
|-
| Aparup Banerjee
| its the same process of a normal download and unzip + upgrade moodle
| 9:54:16 PM
|-
| Dan Poltawski
| watermark.nielsen: good question
| 9:54:19 PM
|-
| Anthony Borrow
| excellent - glad to see the acknowledgement notice, well done!
| 9:54:22 PM
|-
| Gareth J Barnard
| Cool
| 9:55:08 PM
|-
| Anatai
| I really like the pre-check before install, great touch.
| 9:55:13 PM
|-
| Aparup Banerjee
| dependencies show up as little red requirements in upgrade screen
| 9:55:15 PM
|-
| Rex Lorenzo
| Uninstall also deletes files, right?
| 9:55:19 PM
|-
| Anthony Borrow
| great explanation David
| 9:55:20 PM
|-
| Dan Poltawski
| Marks question^ does it auto get the the dependencies?
| 9:55:28 PM
|-
| bmbrands
| Since almost all plugins are on Github it would be great to see some update method or standards when publishing new plugin versions
| 9:55:31 PM
|-
| Rex Lorenzo
| You can download github as zip
| 9:55:49 PM
|-
| Davo Smith
| Moodle.org can pull in from github already
| 9:55:58 PM
|-
| bmbrands
| Yes but the developer needs to create a zip, upload to the plugin database etc.
| 9:56:13 PM
|-
| Justin Filip
| Okay, thanks.
| 9:56:13 PM
|-
| Davo Smith
| Go to 'add new version' and click on 'add'
| 9:56:14 PM
|-
| Aparup Banerjee
| oh nope doesn't auto get dependent plugins afaik.
| 9:56:47 PM
|-
| Davo Smith
| bmbrands - no pull in directly from github, by using the 'github' repo when adding a new version
| 9:56:48 PM
|-
| Dan Poltawski
| bmbrands: https://moodle.org/mod/forum/discuss.php?d=222164
| 9:56:48 PM
|-
| Rex Lorenzo
| Validator functions? Such as?
| 9:57:06 PM
|-
| Gareth J Barnard
| Is it easy to write an uninstall script in the plugin to remove custom DB tables?
| 9:57:42 PM
|-
| bmbrands
| @dan: Cool
| 9:57:43 PM
|-
| Jason Hardin
| is there a roll back function?
| 9:58:05 PM
|-
| Rex Lorenzo
| Very good. Easier to try out new plugins. I don't have to do our whole git workflow to put plugins on our test server.
| 9:58:10 PM
|-
| Dan Poltawski
| Gareth J Barnard: it is done automatically by xmldb
| 9:58:11 PM
|-
| Jason Hardin
| to keep the plugin but downgrade/
| 9:58:12 PM
|-
| Rex Lorenzo
| Jason, cannot rollback any updates on Moodle.
| 9:58:25 PM
|-
| Gareth J Barnard
| @Dan - Very COOL :D - Thanks.
| 9:58:27 PM
|-
| Mark Nelson
| Downgrading requires the upgrade.php file to reverse what it has done, so no.
| 9:58:39 PM
|-
| Davo Smith
| Gareth, or you can use: https://docs.moodle.org/dev/Upgrade_API#uninstall.php if anything is not covered
| 9:58:40 PM
|-
| Gareth J Barnard
| @Davo Thanks
| 9:59:00 PM
|-
| Tim Hunt
| I did not see the UI screen that gets you to sign in blood that you have made a backup before you start.
| 9:59:03 PM
|-
| Dan Poltawski
| timhunt: there is a tickbox
| 9:59:26 PM
|-
| Aparup Banerjee
| bmbrands: i think the solution there is the github repository for uploading to Plugins directory. if its just to try/test perhaps there could be an alternative url that can be entered to fetch a zip from.
| 9:59:28 PM
|-
| Tim Hunt
| Good
| 9:59:36 PM
|-
| Dan Poltawski
| although it might not be there from the plugins directory route atm
| 9:59:39 PM
|-
| Davo Smith
| I can see that going wrong just a bit too often ....
| 10:00:23 PM
|-
| Dan Poltawski
| ^ wahey
| 10:00:31 PM
|-
| marxjohnson00
| That would be nice, but terrifying
| 10:00:35 PM
|-
| Dan Poltawski
| hehe
| 10:00:40 PM
|-
| bmbrands
| Yes, could get annoying having updates weekly
| 10:00:45 PM
|-
| marxjohnson00
| I'd need to write a lot of unit tests before I was comfortable doing that
| 10:00:55 PM
|-
| bmbrands
| Cool stuff David
| 10:01:01 PM
|-
| Rex Lorenzo
| There can be a contact developer button about problems. Or "Send a crash report", lol.
| 10:01:10 PM
|-
| Gareth J Barnard
| Thanks David
| 10:01:23 PM
|-
| David Mudrák
| thanks. Apu should get half of the credit for sure, this was a real team project.
| 10:01:38 PM
|-
| bmbrands
| I have made a "microsoft clippy" block for that, still hoping it will be core one day
| 10:01:45 PM
|-
| Ruslan Kabalin
| Sorry guys, just learned 10 mins ago that I am supposed to present something... do not have mic and did not have chance to prepare
| 10:01:50 PM
|-
| Tim Hunt
| Martin, just demo it!
| 10:02:06 PM
|-
| Dan Poltawski
| MArtin: ^
| 10:02:09 PM
|-
| Ruslan Kabalin
| I can comment here though
| 10:02:22 PM
|-
| Eloy Lafuente (stronk7)
| marTIN: ^^
| 10:02:25 PM
|-
| Dan Poltawski
| use QA site
| 10:02:35 PM
|-
| Dan Poltawski
| (or someting on integration)
| 10:02:45 PM
|-
| Andrew Nicols
| It may also be worth demoing the collapsed editor
| 10:02:45 PM
|-
| Dan Poltawski
| hehe
| 10:03:27 PM
|-
| Dan Poltawski
| try chat
| 10:03:43 PM
|-
| Tim Hunt
| Or quiz
| 10:03:53 PM
|-
| Jason Hardin
| for 2.6 will there be a focus on important fields showing not the whole section?
| 10:04:31 PM
|-
| Rex Lorenzo
| Hmm.. yeah something important, but not required
| 10:04:52 PM
|-
| Jason Hardin
| right
| 10:05:12 PM
|-
| Rex Lorenzo
| Oh, I like the collapsed editor
| 10:05:19 PM
|-
| Andrew Nicols
| Demo adding a new Multiple Choice question
| 10:05:22 PM
|-
| Jason Hardin
| the idea is to initially have all the fields that are most commonly used
| 10:05:25 PM
|-
| Jason Hardin
| shown
| 10:05:27 PM
|-
| Tim Hunt
| The heuristic is: Forms with more than 2 sections: any section after the first is collapsed by default.
| 10:05:35 PM
|-
| Jason Hardin
| then i expand what I need to add
| 10:05:36 PM
|-
| Andrew Nicols
| ah - some in there too
| 10:05:37 PM
|-
| David Mudrák
| jennygray: there is warning for anything lower than MATURITY_STABLE
| 10:05:44 PM
|-
| Tim Hunt
| Right, Jason.
| 10:05:47 PM
|-
| Dan Poltawski
| Jason Hardin: Fred hsa been reworking a lot of the forms in addition to the other work
| 10:05:58 PM
|-
| Jason Hardin
| It is more than that Dan
| 10:06:16 PM
|-
| bmbrands
| I love the editor toggle
| 10:06:18 PM
|-
| Tim Hunt
| Easy to override the default.
| 10:06:19 PM
|-
| Jason Hardin
| If there were an api like advanced
| 10:06:22 PM
|-
| Anthony Borrow
| any thought to add that new tinymce option for comments?
| 10:06:24 PM
|-
| Jason Hardin
| that a dev can tag a fields as "initial" or "important"
| 10:06:39 PM
|-
| Dan Poltawski
| Jason Hardin: I don't see it happening any time soon
| 10:06:51 PM
|-
| Tim Hunt
| Jason, we already have show advanced.
| 10:06:57 PM
|-
| Rex Lorenzo
| Jason, in the assignment plugin, the submission type section is made to be opened by default, but none of those options are required. So it is possible to define what sections to leave open
| 10:07:03 PM
|-
| Rex Lorenzo
| vs collapsed
| 10:07:06 PM
|-
| Dan Poltawski
| there is only so much we can add onto the existing forms library, this is part of the way forward
| 10:07:15 PM
|-
| Jason Hardin
| @tim yeah i know that but we dont' have important or initial as a concept
| 10:07:21 PM
|-
| Jason Hardin
| advanced is used to hide settings
| 10:07:34 PM
|-
| Sam Hemelryk
| Oh hurrah! policy bugs
| 10:07:34 PM
|-
| Rex Lorenzo
| Dan, any followup on the idea of replacing quickforms?
| 10:07:36 PM
|-
| Jason Hardin
| this would be used to show inputs
| 10:07:40 PM
|-
| Tim Hunt
| Jason, re-arrange your form to move the important stuff to the top.
| 10:07:42 PM
|-
| Dan Poltawski
| https://tracker.moodle.org/browse/MDL/component/12733
| 10:07:50 PM
|-
| Dan Poltawski
| https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20component%20%3D%20Policy%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
| 10:08:06 PM
|-
| Tim Hunt
| Thank Colin Chambers for the collapsed editor
| 10:08:10 PM
|-
| Jason Hardin
| @tim that defeats the purpose of grouping fields by identifiable names
| 10:08:11 PM
|-
| Amy Groshek
| Interesting, but it's not toggling between HTML raw and wysiwyg, both are wysiwyg...
| 10:08:21 PM
|-
| Amy Groshek
| So to get to HTML I have to show the editor and then select HTML view... I have more steps than before...
| 10:08:42 PM
|-
| Aparup Banerjee
| if only politicians had bugs.
| 10:08:45 PM
|-
| bmbrands
| @amy: would be nice to have a raw tab for that
| 10:09:02 PM
|-
| Ruslan Kabalin
| my pleasure
| 10:09:18 PM
|-
| Marina Glancy
| hello
| 10:09:50 PM
|-
| Marina Glancy
| can I just type?
| 10:09:58 PM
|-
| Petr Škoda
| lol
| 10:10:14 PM
|-
| Marina Glancy
| Basically in 2.5 all course listings will go through renderer. I made screenshots https://www.dropbox.com/sh/ytgtceoahiw5m6u/2tFpM389pW#/
| 10:10:36 PM
|-
| Rex Lorenzo
| Why aren't they using the QA site?
| 10:11:13 PM
|-
| Marina Glancy
| Rex, who are they?
| 10:11:25 PM
|-
| Marina Glancy
| We still might correct some CSS things there
| 10:12:00 PM
|-
| bmbrands
| Great to have images there, they could be used to create icon buttons for mobile
| 10:12:00 PM
|-
| Marina Glancy
| By the way, screenshots are made using https://github.com/marinaglancy/moodle-tool_behatui
| 10:12:34 PM
|-
| Tim Hunt
| How does that look with 2000 courses?
| 10:12:51 PM
|-
| Marina Glancy
| there are settings that limit the number of courses per page
| 10:13:06 PM
|-
| bmbrands
| @tim: isn't the limit set to 200 ?
| 10:13:11 PM
|-
| Davo Smith
| looks like I'm going to have to catch up with the rest of this later - time for the school run; see you all later
| 10:13:20 PM
|-
| Tim Hunt
| No. The OU has many courses.
| 10:13:22 PM
|-
| Dan Poltawski
| ciao Davo
| 10:13:30 PM
|-
| Marina Glancy
| more about settings: https://docs.moodle.org/dev/Courses_lists_upgrade_to_2.5
| 10:14:15 PM
|-
| Tim Hunt
| Where are the developer docs for what might break?
| 10:14:18 PM
|-
| Tim Hunt
| Ah!
| 10:14:19 PM
|-
| Tim Hunt
| Thanks.
| 10:14:20 PM
|-
| Dan Poltawski
| hehe
| 10:15:17 PM
|-
| Andrew Nicols
| There is a new JS side to it which hasn't yet landed
| 10:15:26 PM
|-
| Marina Glancy
| unfortunately it was not possible to keep old css because it was different everywhere
| 10:15:28 PM
|-
| Marina Glancy
| no, that's it. thanks
| 10:15:51 PM
|-
| Dan Poltawski
| there is a bit of lag here I think Martin (you keep giving up on us saying stuff)
| 10:16:09 PM
|-
| Andrew Nicols
| Yup - it lets you drill down, and loads the course information on the page
| 10:16:22 PM
|-
| Tim Hunt
| Hi!
| 10:17:09 PM
|-
| Dan Poltawski
| aergh!
| 10:17:18 PM
|-
| Gareth J Barnard
| Hi Petr
| 10:17:20 PM
|-
| Aparup Banerjee
| i didn't know he was moving in that close!
| 10:17:32 PM
|-
| Moodle HQ
| I think he's trying to look scary
| 10:17:36 PM
|-
| Andrew Nicols
| It's the light that makes it particularly scary
| 10:18:24 PM
|-
| Jenny Gray
| presumably we might move up to jquery 2.x when Moodle decides to drop support for older IE versions though?
| 10:19:17 PM
|-
| Dan Poltawski
| https://docs.moodle.org/dev/jQuery
| 10:19:37 PM
|-
| Jason Hardin
| I thought only IE 9+ was supported?
| 10:19:48 PM
|-
| Eloy Lafuente (stronk7)
| Prototype added for 2.6?
| 10:19:57 PM
|-
| Jason Hardin
| why is jQuery worried about IE 6?
| 10:19:59 PM
|-
| Anatai
| currently IE 8+ supported
| 10:20:05 PM
|-
| Andrew Nicols
| Jason Hardin, We support IE8
| 10:20:06 PM
|-
| Andrew Nicols
| FYI YUI supports back to IE6
| 10:20:17 PM
|-
| Jason Hardin
| sigh
| 10:20:33 PM
|-
| Eloy Lafuente (stronk7)
| Mootools for 2.7 ?
| 10:20:34 PM
|-
| Dan Poltawski
| Like Petr says, we're not intentionally breaking IE support
| 10:20:41 PM
|-
| Eloy Lafuente (stronk7)
| Dojo for 2.8?
| 10:20:42 PM
|-
| Amy Groshek
| @Eloy, ha ha
| 10:20:53 PM
|-
| Andrew Nicols
| jennygray, Not necessarily, but maybe. Althoughwe'll drop support for IE8 soon, we'll still try our best to make things work
| 10:20:56 PM
|-
| Andrew Nicols
| Hopefully the recent changes to use Shifter will help there too
| 10:21:15 PM
|-
| Jenny Gray
| OU still supporting IE7 in the "try our best" mode
| 10:21:18 PM
|-
| Andrew Nicols
| I can if you want
| 10:21:42 PM
|-
| Amy Groshek
| YUI resets/normalizr
| 10:21:43 PM
|-
| Moodle HQ
| gmail addres andrew?
| 10:21:50 PM
|-
| Tim Hunt
| Let Andrew talk
| 10:21:50 PM
|-
| Andrew Nicols
| andrewrn@gmail.com
| 10:21:55 PM
|-
| Andrew Nicols
| though Petr has covered most of it
| 10:22:09 PM
|-
| Andrew Nicols
| It will help us to write better API docs for our JS, and unit tests
| 10:22:39 PM
|-
| Aparup Banerjee
| nice coer of it too
| 10:22:43 PM
|-
| Aparup Banerjee
| *cover
| 10:22:47 PM
|-
| Tim Hunt
| Andrew, what is that good YUI theatre talk about YUI modules?
| 10:22:52 PM
|-
| Tim Hunt
| It is worth it!
| 10:23:16 PM
|-
| Andrew Nicols
| ermm...
| 10:23:22 PM
|-
| Andrew Nicols
| The one from Ubuntu One?
| 10:23:36 PM
|-
| Andrew Nicols
| Foxxtrot
| 10:23:40 PM
|-
| bmbrands
| yes
| 10:24:00 PM
|-
| Dan Poltawski
| Moodle 2.5: 'we're sick of the wussy windows devs' :P
| 10:24:01 PM
|-
| mary
| great job tweeting by tsala
| 10:24:07 PM
|-
| Ankit Agarwal
| yes we can
| 10:24:09 PM
|-
| Tim Hunt
| Shifter works fine on Windows
| 10:24:14 PM
|-
| Amy Groshek
| @Andrew love the haircut. Very nice.
| 10:24:14 PM
|-
| Mark Nelson
| Wow, cut your hair.
| 10:24:15 PM
|-
| Aparup Banerjee
| hairloss!
| 10:24:16 PM
|-
| Mike Churchward
| Holy crap! New man!
| 10:24:27 PM
|-
| Justin Filip
| Wowâ€¦ Mod Andrew. =)
| 10:24:35 PM
|-
| Tim Hunt
| If anyone wants to encorage Andrew's hair loss: http://www.justgiving.com/andrewnicols
| 10:24:56 PM
|-
| Dan Poltawski
| lol, the most commented on thing so far this meeting
| 10:24:57 PM
|-
| mary
| I liked the poneytail! But understand the reasons for haircut
| 10:25:05 PM
|-
| mary
| lol
| 10:25:09 PM
|-
| Petr Škoda
| linting - yay!
| 10:26:08 PM
|-
| Sam Hemelryk
| (
| 10:26:12 PM
|-
| Tim Hunt
| I learned a lot from the lint output.
| 10:26:21 PM
|-
| Eloy Lafuente (stronk7)
| I used to understand him better with the long hair, uhm...
| 10:26:30 PM
|-
| Tim Hunt
| Well, you just add Y.log statements to you code for development.
| 10:26:57 PM
|-
| Tim Hunt
| Then, they don't appear in the finished code for people not in dev debug mode.
| 10:27:09 PM
|-
| Aparup Banerjee
| Eloy: you need mod_rmaccent
| 10:27:30 PM
|-
| Petr Škoda
| https://docs.moodle.org/dev/jQuery is the jQuery docs page
| 10:27:32 PM
|-
| Mark Nelson
| What shampoo do you use?
| 10:27:34 PM
|-
| Justin Filip
| Andrew's so dreamy!
| 10:27:48 PM
|-
| Dan Poltawski
| wow, thats a good colour in your face now!
| 10:28:00 PM
|-
| Aparup Banerjee
| LOL
| 10:28:08 PM
|-
| Mark Nelson
| I keep thinking I am watching a shampoo commercial on youtube
| 10:28:15 PM
|-
| Dan Poltawski
| I can see ruslan trying to get in the picture
| 10:28:20 PM
|-
| Dan Poltawski
| with his arms
| 10:28:22 PM
|-
| mary
| lol
| 10:28:23 PM
|-
| Andrew Nicols
| https://docs.moodle.org/dev/YUI https://docs.moodle.org/dev/Javascript/Shifter
| 10:28:48 PM
|-
| Gareth J Barnard
| Get LANCs to change the paint colour!
| 10:28:51 PM
|-
| Andrew Nicols
| And https://docs.moodle.org/dev/YUI/Modules is in progress
| 10:28:56 PM
|-
| Dan Poltawski
| its gone dark
| 10:29:19 PM
|-
| Dan Poltawski
| https://docs.moodle.org/dev/Acceptance_testing
| 10:30:56 PM
|-
| Martin Dougiamas
| Are you hearing David ok?
| 10:31:34 PM
|-
| Dan Poltawski
| yep
| 10:31:36 PM
|-
| Ankit Agarwal
| yes
| 10:31:42 PM
|-
| Gareth J Barnard
| yep
| 10:31:43 PM
|-
| Eloy Lafuente (stronk7)
| best english in the season!
| 10:31:43 PM
|-
| David Mudrák
| yes
| 10:31:44 PM
|-
| Dan Poltawski
| (I am used to his spanish accent )
| 10:31:48 PM
|-
| Mark Nelson
| season, or session?
| 10:31:55 PM
|-
| Eloy Lafuente (stronk7)
| year*
| 10:32:01 PM
|-
| Eloy Lafuente (stronk7)
|
| 10:32:02 PM
|-
| Mark Nelson
| lol
| 10:32:05 PM
|-
| Andrew Nicols
| Martin Dougiamas, Where were you suggesting I add the links to the new docs?
| 10:32:24 PM
|-
| Helen Foster
| David sounds great!
| 10:32:45 PM
|-
| Martin Dougiamas
| The April 2013 dev meeting page
| 10:32:46 PM
|-
| Andrew Nicols
| will do
| 10:32:53 PM
|-
| Martin Dougiamas
| Thanks!
| 10:33:05 PM
|-
| bmbrands
| could this be used to create performance tests too? this looks easier than doing jmeter scripts.
| 10:33:32 PM
|-
| Dan Poltawski
| bmbrands: no
| 10:33:44 PM
|-
| Rex Lorenzo
| It wouldn't make sense to time the tests as a performance indicator?
| 10:34:04 PM
|-
| Dan Poltawski
| (not out of the box, I don't think.. doubting myself now)
| 10:34:06 PM
|-
| Eloy Lafuente (stronk7)
| not really (there are some "pauses" here and there), and will evolve along the time/depend of the product used.
| 10:34:13 PM
|-
| Martin Dougiamas
| Yes it can
| 10:34:13 PM
|-
| Dan Poltawski
| rexlorenzo@gmail.com: they are doing pauses and all kinds of things
| 10:34:21 PM
|-
| Dan Poltawski
| its not a very reliable way to do it
| 10:34:28 PM
|-
| Mark Nelson
| Just a note to developers: MDK (Fred's plugin) will set behat up for you.
| 10:35:07 PM
|-
| Martin Dougiamas
| No, sure. But I think with lots and lots of tests the pauses will sort of even out.
| 10:35:08 PM
|-
| Martin Dougiamas
| At least it would detect really stupid mistakes.
| 10:35:23 PM
|-
| Marina Glancy
| I found another implementation recently - it is useful to run the same test across all/some themes and make screenshots
| 10:35:29 PM
|-
| Mark Nelson
| Whoops, when I say plugin, I mean script. It is not a moodle plugin.
| 10:35:52 PM
|-
| Martin Dougiamas
| Post your code again marina.
| 10:35:55 PM
|-
| Martin Dougiamas
| It's a cool idea
| 10:36:12 PM
|-
| Marina Glancy
| https://github.com/marinaglancy/moodle-tool_behatui
| 10:36:17 PM
|-
| Martin Dougiamas
| (Y)
| 10:36:34 PM
|-
| bmbrands
| @marina: coool
| 10:36:49 PM
|-
| Marina Glancy
| I added there a big test for course listings, I'm going to suggest it for theme developers in my course listings doc
| 10:36:57 PM
|-
| Eloy Lafuente (stronk7)
| it can be used to cover some "key" vualizations.
| 10:37:05 PM
|-
| Eloy Lafuente (stronk7)
| *visualizations.
| 10:37:11 PM
|-
| Dan Poltawski
| If you have moodle 2.5, you can see the list of steps definitons in: admin/tool/behat/index.php
| 10:37:24 PM
|-
| Eloy Lafuente (stronk7)
| (aka the vocabulary)
| 10:38:07 PM
|-
| Anthony Borrow
| Given Marina submits moodle-tool_behatui to Moodle plugins, Then I can automatically install with Aparup's install button
| 10:38:37 PM
|-
| Jason Hardin
| behat is not using the mink plugin to allow for other test servers other than selenium?
| 10:39:38 PM
|-
| Eloy Lafuente (stronk7)
| yes
| 10:39:43 PM
|-
| Eloy Lafuente (stronk7)
| in fact I want to try it against others soon (faster and headless with JS support)
| 10:40:21 PM
|-
| Mark Nielsen
| Hrm... that can help speed up tests though. Using a headless browser, etc
| 10:40:42 PM
|-
| bmbrands
| have to leave, thanks all
| 10:40:52 PM
|-
| Jason Hardin
| it does help but has issues
| 10:41:03 PM
|-
| Jason Hardin
| not all headless support the same funcitonality as selenium
| 10:41:12 PM
|-
| Eloy Lafuente (stronk7)
| for non-js, non-corss-browser ones it already uses headless afaik)
| 10:41:16 PM
|-
| Jason Hardin
| selenium seems to be the best supported though
| 10:41:21 PM
|-
| Eloy Lafuente (stronk7)
| nah
| 10:41:25 PM
|-
| Jason Hardin
| the others have "issues"
| 10:41:27 PM
|-
| Eloy Lafuente (stronk7)
| lol, selenium has too
| 10:41:34 PM
|-
| Dan Poltawski
| Mark: yes. The problem is real useers don't use javascript-less browsers
| 10:41:38 PM
|-
| Martin Dougiamas
| Thanks Bas!
| 10:41:44 PM
|-
| Jason Hardin
| @eloy, true, but you can get the server to run
| 10:41:49 PM
|-
| Jason Hardin
| i have not gotten others to run onlinux and mac
| 10:42:01 PM
|-
| Jason Hardin
| only one or the other
| 10:42:06 PM
|-
| Rex Lorenzo
| Oh, are you guys also running behats tests for accessibility? The idea about javascript browsers made me think about it.
| 10:42:18 PM
|-
| Eloy Lafuente (stronk7)
| well, I've tried zombie and it rocks
| 10:42:26 PM
|-
| Jason Hardin
| i tried zombie and it failed
| 10:42:36 PM
|-
| Eloy Lafuente (stronk7)
| for the purposes I'm thinking about.
| 10:42:36 PM
|-
| Rex Lorenzo
| *javascript-less
| 10:42:41 PM
|-
| Dan Poltawski
| rexlorenzo@gmail.com: an interesting side effect of behat tests is that I think it helps us with accessibility
| 10:42:50 PM
|-
| Mark Nielsen
| @poltawski: not all tests require JS though - if I just want to confirm that some text appears after hitting a button, I don't need anything special
| 10:43:13 PM
|-
| Jason Hardin
| yeah when Eloy means javascript less it is that the testing software doesn't need aJS to run the tests
| 10:43:14 PM
|-
| Jason Hardin
| not that there is no js testing
| 10:43:18 PM
|-
| Dan Poltawski
| because we spot things like multiple links with the same meaning
| 10:43:20 PM
|-
| Dan Poltawski
| grr
| 10:43:24 PM
|-
| Dan Poltawski
| different meaning
| 10:43:28 PM
|-
| Andrew Nicols
| same heading, different meaning
| 10:43:43 PM
|-
| Dan Poltawski
| @watermark.nielsen its already supported with headless browser, if itsnnot got javascript requirement
| 10:43:46 PM
|-
| Mark Nielsen
| ah
| 10:43:57 PM
|-
| Jason Hardin
| if you want accessibility testing there is a fireeyes plugin that works pretty well it is free
| 10:43:58 PM
|-
| Dan Poltawski
| there is an @javascript tag for javascript depdendent tests
| 10:44:09 PM
|-
| Jason Hardin
| http://www.deque.com/deque-fireeyes
| 10:44:10 PM
|-
| Jason Hardin
| it si produced by the consulting company Moodlerooms hired to review Moodle
| 10:44:20 PM
|-
| Jason Hardin
| and free to use as long as you are not providing consulting services around it
| 10:44:36 PM
|-
| Eloy Lafuente (stronk7)
| he
| 10:44:42 PM
|-
| Eloy Lafuente (stronk7)
| meeting interruptus?
| 10:45:13 PM
|-
| Dan Poltawski
| thats his screen isn't it
| 10:45:16 PM
|-
| Dan Poltawski
| keep commentating!
| 10:45:22 PM
|-
| Eloy Lafuente (stronk7)
| music!
| 10:45:28 PM
|-
| Eloy Lafuente (stronk7)
| brasil!
| 10:45:32 PM
|-
| Dan Poltawski
| Ijust saw his terminal
| 10:45:52 PM
|-
| Aparup Banerjee
| seeing terminal snow
| 10:46:11 PM
|-
| Sam Hemelryk
| Yip I can see it
| 10:46:13 PM
|-
| Dan Poltawski
| its threre now
| 10:46:16 PM
|-
| Aparup Banerjee
| *now
| 10:46:19 PM
|-
| Rajesh Taneja
| yes
| 10:46:20 PM
|-
| David Mudrák
| finally a command line interface!
| 10:46:23 PM
|-
| Dan Poltawski
| its just that its at top of screen
| 10:46:23 PM
|-
| Eloy Lafuente (stronk7)
| DONT TYPE the ROOT's PASSWORD NOW!
| 10:46:25 PM
|-
| Ankit Agarwal
| lol
| 10:46:26 PM
|-
| Andrew Nicols
| Martin: Click on his window at the bottom. It's based on who is talking most
| 10:46:27 PM
|-
| Dan Poltawski
| get him to press enter
| 10:46:27 PM
|-
| Aparup Banerjee
| gone
| 10:46:29 PM
|-
| Andrew Nicols
| heh
| 10:46:40 PM
|-
| Andrew Nicols
| wfm ;)
| 10:46:49 PM
|-
| Dan Poltawski
| I see him!
| 10:47:05 PM
|-
| Aparup Banerjee
| its there now
| 10:47:06 PM
|-
| Eloy Lafuente (stronk7)
| here we go
| 10:47:13 PM
|-
| Dan Poltawski
| look you guys look!
| 10:47:23 PM
|-
| Eloy Lafuente (stronk7)
| it's boring... although last time i was 80 mins looking for them to complete.
| 10:48:01 PM
|-
| Helen Foster
| wow, how cool is that!
| 10:48:01 PM
|-
| Dan Poltawski
| lol
| 10:48:01 PM
|-
| Dan Poltawski
| david is cheating
| 10:48:28 PM
|-
| Dan Poltawski
| hes just doing it quickly
| 10:48:35 PM
|-
| Eloy Lafuente (stronk7)
| it's a recorded video! Fake!
| 10:48:42 PM
|-
| Eloy Lafuente (stronk7)
|
| 10:48:51 PM
|-
| Eloy Lafuente (stronk7)
| eh, have you seen the setType warning, Dan?
| 10:49:07 PM
|-
| Gareth J Barnard
| He has a Raspberry Pi controlled mouse ;)
| 10:49:09 PM
|-
| Aparup Banerjee
| suspects trained monkeys
| 10:49:10 PM
|-
| Dan Poltawski
| yes!
| 10:49:11 PM
|-
| Dan Poltawski
| errors not detected
| 10:49:25 PM
|-
| Justin Filip
| Does this take screenshots at any points for making sure a page is rendered correctly?
| 10:49:29 PM
|-
| Jason Hardin
| can you run just the plugin tests?
| 10:49:36 PM
|-
| Eloy Lafuente (stronk7)
| yeah, we should have them caught already, grrr
| 10:49:38 PM
|-
| Justin Filip
| Such as: this page looks great in Chrome and FF but renders incorrectly in IE8?
| 10:49:46 PM
|-
| Dan Poltawski
| Jason Hardin: you can run by tag
| 10:49:49 PM
|-
| Jason Hardin
| awesome
| 10:49:56 PM
|-
| Dan Poltawski
| jfilip: yes
| 10:49:56 PM
|-
| Eloy Lafuente (stronk7)
| by tag or by name (part of the description)
| 10:50:07 PM
|-
| Justin Filip
| Cool, thanks.
| 10:50:08 PM
|-
| Jason Hardin
| nice
| 10:50:20 PM
|-
| Moodle HQ
| Justin, that's exactly what Marinas behatui thing does
| 10:50:25 PM
|-
| Rex Lorenzo
| Are you guys running also running selenium in windows to test IE? How many different environments are you running selenium or planning to?
| 10:50:34 PM
|-
| Eloy Lafuente (stronk7)
| 2.6 testing won't be QA testing anymore but "picture testing" instead, lol.
| 10:51:15 PM
|-
| Justin Filip
| I'll take a look at it, thanks for the info.
| 10:51:41 PM
|-
| Moodle HQ
| Sauce labs, for now
| 10:52:11 PM
|-
| Rex Lorenzo
| Which service?
| 10:52:14 PM
|-
| Dan Poltawski
| https://saucelabs.com/
| 10:52:24 PM
|-
| Eloy Lafuente (stronk7)
| settype again
| 10:52:50 PM
|-
| Dan Poltawski
| https://saucelabs.com/u/moodle
| 10:52:58 PM
|-
| Dan Poltawski
| ^ cool
| 10:53:00 PM
|-
| Eloy Lafuente (stronk7)
| we need to catch all those notices/warnings/debuggins ASAP
| 10:53:34 PM
|-
| Rex Lorenzo
| Very cool stuff.
| 10:53:40 PM
|-
| Eloy Lafuente (stronk7)
| awesome stuff, david!
| 10:53:56 PM
|-
| Dan Poltawski
| now everyone else needs to start writing tests
| 10:54:14 PM
|-
| Eloy Lafuente (stronk7)
| i want to
| 10:54:20 PM
|-
| Dan Poltawski
| (steam was coming out of davids ears when I was in perth)
| 10:54:27 PM
|-
| Ankit Agarwal
| Nice presentations
| 10:54:58 PM
|-
| Ankit Agarwal
| slides
| 10:55:10 PM
|-
| Eloy Lafuente (stronk7)
| wasn't there a pending backport issue for tests to 2.4 ?
| 10:55:12 PM
|-
| Eloy Lafuente (stronk7)
| (evil)
| 10:55:18 PM
|-
| Eloy Lafuente (stronk7)
| (assign ones)
| 10:55:28 PM
|-
| Dan Poltawski
| yup
| 10:55:31 PM
|-
| Dan Poltawski
| aren't they waiting on Damyon
| 10:56:11 PM
|-
| Dan Poltawski
| yup: MDL-37632
| 10:56:31 PM
|-
| Moodle Bot
| https://tracker.moodle.org/browse/MDL-37632 - Backport unit tests for mod/assign/lib.php and mod/assign/lib.php and mod/assign/upgradelib.php to 24
| 10:56:31 PM
|-V: 0, W: 3, Type: Improvement, Assignee: Damyon Wiese, Priority: Minor, Status: Reopened
| Andrew Nicols
| yay people using the new drag/drop of help
| 10:59:07 PM
|-
| Dan Poltawski
| lol
| 11:00:11 PM
|-
| Dan Poltawski
| profile description from mdk
| 11:00:26 PM
|-
| Davo Smith
| popped back just in time
| 11:04:14 PM
|-
| Gareth J Barnard
| Will MDL-37490 make it into M2.5?
| 11:04:26 PM
|-
| Moodle Bot
| https://tracker.moodle.org/browse/MDL-37490 - Display assignment due date on course page.
| 11:04:27 PM
|-V: 4, W: 7, Type: New Feature, Assignee: Gareth J Barnard, Priority: Minor, Status: Waiting for integration review
| Ankit Agarwal
| yes
| 11:05:21 PM
|-
| Andrew Nicols
| Seeing it on youtube now
| 11:05:21 PM
|-
| Rajesh Taneja
| yes
| 11:05:24 PM
|-
| David Mudrák
| yes
| 11:05:27 PM
|-
| Justin Filip
| Yes
| 11:05:33 PM
|-
| sbourget
| yes
| 11:05:36 PM
|-
| Eloy Lafuente (stronk7)
| another perfect english speaker, yay!
| 11:06:05 PM
|-
| Eloy Lafuente (stronk7)
| the orange looks "too much" for me, lol.
| 11:09:00 PM
|-
| Tim Hunt
| No such thing as too much orange.
| 11:09:12 PM
|-
| Eloy Lafuente (stronk7)
| will it support custom backgrounds?
| 11:09:37 PM
|-
| David Mudrák
| typical mobile developer - having even desktop windows resized to 200 x 300 px
| 11:09:53 PM
|-
| Ankit Agarwal
| heh
| 11:10:04 PM
|-
| Martin Dougiamas
| Yes you can change backgrounds and everything via CSS
| 11:12:24 PM
|-
| Martin Dougiamas
| there is a new setting in Moodle 2.5 that lets you specify the URL to a CSS file
| 11:12:44 PM
|-
| Eloy Lafuente (stronk7)
| super
| 11:12:53 PM
|-
| Martin Dougiamas
| And the app will get this and use it
| 11:12:57 PM
|-
| Andrew Nicols
| Same goes for language customisations
| 11:13:18 PM
|-
| Martin Dougiamas
|
| 11:13:23 PM
|-
| Martin Dougiamas
| And all this is cached in the app
| 11:13:28 PM
|-
| Eloy Lafuente (stronk7)
| well done1
| 11:14:03 PM
|-
| Andrew Nicols
| It's a nice app - well done Juan
| 11:14:17 PM
|-
| Aparup Banerjee
| nice! (browser appears black sometimes in youtube)
| 11:14:49 PM
|-
| Rex Lorenzo
| Is the push notifications something similar to what Moodlerooms is proposing for their alert system in here? https://moodle.org/mod/forum/discuss.php?d=223812
| 11:14:59 PM
|-
| Rex Lorenzo
| How can we sent push notifications? Does it use the messaging api?
| 11:15:28 PM
|-
| Tim Hunt
| More open. Less free
| 11:15:29 PM
|-
| marxjohnson00
| Haha oh dear
| 11:15:36 PM
|-
| marxjohnson00
| lets not get into that now
| 11:15:40 PM
|-
| Dan Poltawski
| rexlorenzo@gmail.com: the notification using messaging system
| 11:15:43 PM
|-
| Juan Leyva
| Rex, yes messaging output plugins
| 11:15:46 PM
|-
| Eloy Lafuente (stronk7)
| "we are legion"
| 11:15:49 PM
|-
| Martin Dougiamas
| We have a server called AirNotifier that will recieve messages from Moodle
| 11:16:17 PM
|-
| maberdour
| Holy crap, been trying out different jabber settings for an hour. Made it in. Thanks @anatai
| 11:16:18 PM
|-
| Martin Dougiamas
| via Message API
| 11:16:21 PM
|-
| Eloy Lafuente (stronk7)
| jabber is sooo simple, lol.
| 11:16:33 PM
|-
| Martin Dougiamas
| and send it to Apple/Google and then to your phone
| 11:16:35 PM
|-
| Anatai
| @maberdour you're welcome
| 11:16:38 PM
|-
| Eloy Lafuente (stronk7)
| super
| 11:16:51 PM
|-
| Eloy Lafuente (stronk7)
| exciting
| 11:16:55 PM
|-
| Eloy Lafuente (stronk7)
| amazing
| 11:16:57 PM
|-
| sam marshall
| (yeah, how come irc works much better than jabber?
| 11:16:58 PM
|-
| Gareth J Barnard
| Thank you
| 11:17:05 PM
|-
| Aparup Banerjee
| yes the notifications i've received were cool Jerome
| 11:17:08 PM
|-
| Juan Leyva
| https://docs.moodle.org/24/en/Moodle_Mobile_app
| 11:17:19 PM
|-
| Juan Leyva
| https://docs.moodle.org/dev/Moodle_Mobile
| 11:17:19 PM
|-
| Eloy Lafuente (stronk7)
| welcom, G
| 11:17:21 PM
|-
| Andrew Nicols
| We've lost camear on youtube
| 11:17:22 PM
|-
| Andrew Nicols
| Got your camera now
| 11:17:44 PM
|-
| Anthony Borrow
| any updates on MDL-36350 / https://docs.moodle.org/dev/Survey_2_module - it seems to keep getting pushed back - possible GSOC project?
| 11:18:30 PM
|-
| Moodle Bot
| https://tracker.moodle.org/browse/MDL-36350 - Implement Survey 2 module
| 11:18:30 PM
|-V: 12, W: 18, Type: New Feature, Assignee: Daniele Cordella, Priority: Major, Status: Open
| Moodle HQ
| AFAIK Daniele stil on it
| 11:19:10 PM
|-
| Eloy Lafuente (stronk7)
| afaik Danielle is back, hard working on it, Anthony.
| 11:19:13 PM
|-
| Anthony Borrow
| good news!
| 11:19:21 PM
|-
| Andrew Nicols
| lag is tricky
| 11:19:54 PM
|-
| Dan Poltawski
| hi GSOC students watching!
| 11:19:58 PM
|-
| marxjohnson00
| 1
| 11:20:05 PM
|-
| Andrew Nicols
| and Twitter hasn't been great for it
| 11:20:06 PM
|-
| Ankit Agarwal
| Brilliant
| 11:20:07 PM
|-
| Aparup Banerjee
| this is way way better
| 11:20:08 PM
|-
| Eloy Lafuente (stronk7)
| 0.5
| 11:20:08 PM
|-
| Gareth J Barnard
| Will this live stream be saved? +1
| 11:20:09 PM
|-
| Andrew Nicols
| +1 though
| 11:20:09 PM
|-
| Rajesh Taneja
| 1
| 11:20:11 PM
|-
| Tim Hunt
| Video and audio is good.
| 11:20:11 PM
|-
| Sam Hemelryk
| 1
| 11:20:13 PM
|-
| Justin Filip
| Pretty good
| 11:20:13 PM
|-
| Rex Lorenzo
| Better than bbb
| 11:20:17 PM
|-
| Eloy Lafuente (stronk7)
| 0.2
| 11:20:17 PM
|-
| David Mudrák
| 1
| 11:20:18 PM
|-
| Tim Hunt
| Harder to see who is in the meeting and chat
| 11:20:20 PM
|-
| Andrew Nicols
| Could do with the stream running a bit for 15 minutes before hand to give people a chance to get themselves sorted
| 11:20:24 PM
|-
| Mark Nelson
| It worked with very little effort.
| 11:20:35 PM
|-
| Dan Poltawski
| 1
| 11:20:38 PM
|-
| Tim Hunt
| Yes. Starting the stream earlier woudlbe good.
| 11:20:40 PM
|-
| Eloy Lafuente (stronk7)
| google rocks!
| 11:20:42 PM
|-
| Jenny Gray
| twitter has been surprisingly quiet.
| 11:20:42 PM
|-
| Eloy Lafuente (stronk7)
|
| 11:20:43 PM
|-
| Gareth J Barnard
| BBB is being used at iMoot 2013.
| 11:20:56 PM
|-
| Andrew Nicols
| thanks
| 11:21:10 PM
|-
| David Mudrák
| too many places to check for feedback
| 11:21:11 PM
|-
| Gareth J Barnard
| Thank you all
| 11:21:26 PM
|-
| Eloy Lafuente (stronk7)
| devs rocks! C'mon!
| 11:21:35 PM
|-
| Tim Hunt
| Thanks.
| 11:21:36 PM
|-
| Anatai
| thanks
| 11:21:38 PM
|-
| David Mudrák
| thanks
| 11:21:40 PM
|-
| Ankit Agarwal
| Cya all
| 11:21:42 PM
|-
| Justin Filip
| Thanks
| 11:21:42 PM
|-
| mary
| thanks
| 11:21:44 PM
|-
| Rex Lorenzo
| Thanks.
| 11:21:44 PM
|-
| Sam Hemelryk
| Cool, thanks guys
| 11:21:45 PM
|-
| Mark Nelson
| Ciao.
| 11:21:49 PM
|-
| Dan Poltawski
| ciao
| 11:21:49 PM
|-
| David Mudrák
| (clap)
| 11:21:50 PM
|-
| David Mudrák
| +1 mojito
| 11:21:54 PM
|-
| Rossiani Wijaya
| cya
| 11:22:01 PM
|-
| Rajesh Taneja
| cya
| 11:22:01 PM
|-
| David Mudrák
| did I hear "meeting rums?"
| 11:22:07 PM
|-
| Aparup Banerjee
| thanks! good night! moodle out yo
| 11:22:14 PM
|-
| Eloy Lafuente (stronk7)
| did i hear "mojito" ?
| 11:22:16 PM
|-
| Eloy Lafuente (stronk7)
| lol
| 11:22:20 PM
|}

Developer credits processor

2025-02-10T08:16:55Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Developer credits processor
|state = In production
|tracker = MDLSITE-1663
|discussion = N/A
|assignee = [[User:David Mudrak|David Mudrak]]
}}

== Project goals ==

We need to replace part of the functionality provided by the legacy cvsadmin plugin at moodle.org. The new local plugin /local/dev is supposed to:

* gather activity traces of git commits in the main moodle.git repository
* gather activity traces of comments and transitions in JIRA
* assign activity traces to real moodle.org users
* produce a list of Moodle developers and simple amount of their contribution (per branch and per release)

== Design principles ==

* It must be cheap to display the data to the visitors of moodle.org site (with just one or two SQL queries)
* Data collecting and processing should be implemented in CLI scripts. Then we can schedule their execution accurately via robust Unix crontab syntax and we don't pollute Apache's access logs.

== Overall architecture ==

The following image displays the basic architecture of the plugin and how it applies to the two sources of activity records - moodle.git repository and the JIRA tracker.

[[Image:local_dev_processes.png|thumb|left|466px|Basic processes of collecting and aggregating activity traces in Moodle development]]
 

There is a table {dev_activity} that is the only one used when displaying the contribution data. A subclass of table_sql is used so it takes care of sorting and pagination.

Rows in the {dev_activity} table are updated by the script cli/aggregate.php. For every tracked activity source (like moodle.git, JIRA or whatever else in the future) there is a class that is responsible for updating its activity metric (eg. gitcommits, gitmerges etc).

There can be various tables for each tracked activity source to hold the data for the aggregating class. These tables are populated with data as needed.

=== Processing moodle.git commits ===

* The plugin keeps its own mirror of moodle.git in moodledata (cloned with --mirror parameter)
* The script cli/git-commits.php reads commits from all MOODLE_xx_STABLE branches as well as from the master branch and records them in the {dev_git_commits} table
* The script cli/git-tags.php assigns each commit to the Moodle release it belongs to
* The script cli/git-aliases.php tries to assign each commit to the real moodle.org user account (based on the email in the commit and eventually any explicit mapping defined in {dev_git_user_aliases} table).
* The script cli/aggregates.php uses two classes dev_gitcommits_aggregator and dev_gitmerges_aggregator that are responsible for aggregating commits and merges (respectively) and linking them to Moodle versions (by converting the associated Git tag to a Moodle version).

Datalib Notes

2025-02-10T08:16:06Z

Sarjona:

{{Template:WillNotMigrate}}

== General Datalib usage Notes ==

Couple of discussion threads about usage of datalib are [http://moodle.org/mod/forum/discuss.php?d=43456 here] and [http://moodle.org/mod/forum/discuss.php?d=38183 here].

== Advanced Usage: get_recordset() ==

There's a new series of function calls in datalib that were introduced shortly after 1.5: get_recordset() and friends. It takes a bit of work to make good use of them, they are definitely useful.

The function calls themselves take similar parameters to the get_records() family, and return an AdoDB recordset. In most situations, the right thing is to use get_records(), making sure that you are selecting a limited number of records (use LIMIT of course wink ), and that you are clearly fetching only the fields you need. That is enough for 99% of the cases. Stop reading now, use get_records(), and done.

Easy!

Now, there are some cases where we need to perform huge selects. And the downside of the get_records() machinery is that it allocates it all in RAM -- and if indeed records > than RAM, we are in trouble. This mostly affects batch processing in admin/cron.php (backups for instance) and the silly sync scripts we have in some auth and enrolment plugins.

In those cases, where you have no option but to SELECT all the users, or all the courses, get_recordset() really shines. As you get an AdoDB recordset, you can iterate through it very fast, and with very low memory usage. I have prepared and profiled some samples and found that to keep that advantage you have to be very careful how you use it.

I started testing with a large mdl_user table with 46K users, stored in PostgreSQL locally (socket connection). Here is a rundown of the code and rough timings...

The traditional get_records() is fast (~14s), but it consumes 296MB of memory. It looks like:

$users = get_records('user');

So the next thing was to check that just triggering the SELECT was fast, and that fetching and re-shaping all that data into memory was an expensive step. get_recordset() in itself never fetches the data into PHP-space, so it takes only 4.8MB and 1.4s:

$users = get_recordset('user');

Next I tried using get_recordset() with FetchNextObj() which looked quite convenient, because it will yield each record in an object, similar to the objects that get_records() returns inside the array. The memory usage stayed the same (4.8M), but this is very slow (~65s):

$users = get_recordset('user');
while($v = $users->FetchNextObj()){
// do something
}

Internally, get_records() is using GetAssoc(), so I looked in there to se faster ways of getting at the data. Apparently, the trick is in reading the $rs->fields array and using MoveNext(). So this loop still takes 4.8MB and walks the 46K user records in 4s:

$users = get_recordset('user');
while(!$users->EOF) {
$user = $users->fields;
// do something
$users->MoveNext();
}

Naturally, as soon as you start doing useful things, this will take longer to exec. The core advantage, however, is that it can give you comparable performance to get_records() but with very low memory usage.

There is an interesting [http://moodle.org/mod/forum/discuss.php?d=45794 discussion about get_recordset() in the General Developer Forum].

== Moodle 2 ==
Note, that this documentation is not valid for Moodle 2. Please refer to https://docs.moodle.org/dev/Data_manipulation_API#Using_Recordsets

Database collation issue

2025-02-10T08:14:57Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Database collation issue
|state = Specification in progress
|tracker = MDL-36208
|discussion = https://moodle.org/mod/forum/discuss.php?d=214564
|assignee = ''Hero required''
}}

== Background ==

Database store text data using a particular '''character set'''. Moodle uses UTF-8, which is a good thing, since UTF-8 can represent almost any character ever.

Text data is also stored with an associated '''collation'''. This affects how the values are sorted and compared. For example, different languages have different sort-orders, which depend on which alphabet they use. For example in German the '''ß''' character should come just after '''S''' (and '''s''').

Collations typically come in two forms, case sensitive, and case-insensitive. If you are using a case-insensitive collation, then not only do 'x' and 'X' get sorted the same, but actually, the database thinks that 'x' = 'X'.

Operations like JOINs are typically much faster if both tables (columns) use the same collation.

== The problems ==

=== Collation should depend on current language ===

On multi-lingual sites like [https://moodle.org/ moodle.org], different users will all expect reports to be sorted according to their language's collation rules. If we just specify the collation in database table definition, then all queries for all users have to use the same collation.

Typical bugs:
* MDL-30446 Glossary order issues for some collation settings (Postgres)

=== Machine-readable identifiers ===

Moodle stores two sorts for text data:
* user-visible strings like user.firstname, user.lastname or course.fullname
* machine-readable identifiers like user.username, course.idnumber or file.filepath

For machine-readable identifiers, the 'x' == 'X', or worse 'e' == 'é' behaviour is really bad, particularly if you want to put a unique index on the column in question. It has lead to bugs like:
* MDL-29332 Calculated Questions Require Case Sensitive Data Tables (MySQL)
* MDL-33655 MySQL case insensitivity breaks get_directory_files (MySQL)
* MDL-34271 improve mysql collation handling

=== Human-readable case-sensitive strings ===

* MDL-22117 Units in numerical questions are acting case sensitive, but not functioning that way

=== MySQL only has localised collations that are case-insensitive ===

If you look at the list of [https://dev.mysql.com/doc/refman/5.5/en/charset-unicode-sets.html MySQL collations], you will see that the only collations that give correctly locale-aware ordering are case-insensitive (the ci bit in utf8_czech_ci), and so suffer from the 'x' == 'X' and 'e' == 'é' problem. The only collation that does not have this problem is utf8_bin, which is not the order people want to see.

== Outline solution ==

The proposed solution is simple in outline:
# Store all data in database tables that use a case-sentistive collation (e.g. utf8_bin).
# Change all ORDER BY clauses in all SQL that sort text, to specify the correct sort collation, based on the current language.

To support that second part, we will need some helper code, for example, each language pack must specify the right collation to use, for each supported database, for example using new strings in langconfig.php. We will also need an $DB->sql_order_by_text($column) helper function to return the right SQL fragment like "columnname COLLATE utf8_czech_ci".

== Difficulties with the proposed solution ==

=== Transitional period (minor) ===

In the transitional period, when the table definitions have been updated to use a collation like utf8_bin, but before we have found and fixed all SQL queries in Moodle core (and in all third-party plugins) to use sql_order_by_text, then the worst that can happen is that the results of some reports appear in a slightly odd order for some users. The reports will still basically work.

Whenever a problem like this is detected, it will be easy to add the necessary sql_order_by_text call to the code to fix it.

=== Time to do the upgrade (moderate) ===

The amount of time required to upgrade all tables to a new collation is going to be comparable to the time required for the change that changed all unsigned int columns to signed. This was an issue for some large sites.

Like dropping unsigned columns, this is probably a necessary evil that we can live with.

=== Backwards compatibility of identifiers (severe) ===

This is the most serious problem. It affects areas like:
* What are valid user names? Are user names case-sensitive.
* For people using integrations like the database authentication and enrolment plugins, or CVS import, it may be that at the moment, the identifiers currently match using case-insensitive collation, but if we changed the database collation to utf8_bin, then things would not longer match. This could cause a real mess.

So, we may have to add an admin option for these areas, where admins can choose if they want case-sensitive or case-insenstivive collations. Then, if they choose case-insensitive collation for backwards compatibility, we will have to add explicit LOWER(...) or COLLATE calls to the code, to maintain the current behaviour.

Here the risk is not just wrong sorting of reports, but it could badly break sites data integration. Hence, the risks if we get this wrong is very severe.

We do not yet have a good solution to this problem.

[[Category:Project]]

Data Item Functions

2025-02-10T08:14:04Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

This page discuss the actual (sept 2006, moodle 1.7) functions used to create, modify or delete data items. 
Calculated parameters i.e {x1} are generated using the dataset parameters ( min, max, distribution) or edited directly by the teacher in the 3rd step of calculated questions creation or modification process.
The code for doing this,is mostly in '''question/type/datasetdependent/datasetitems.php''' and in
'''question/type/questiontype/generate_dataset_item($options)'''
'''question/type/questiontype/comment_on_datasetitems($question, $data, $number)'''
and backup and restore functions

In '''question/type/datasetdependent/datasetitems.php'''

// Handle adding of dataset items
A data item have been either generated or reused and is presented in the form so it can be edited. When the '''add button''' is clicked
// This twisted condition should effectively stop resubmits caused by reloads
if (isset($form->addbutton) && $maxnumber + 1 == $form->numbertoadd) {
$addeditem->number = $form->numbertoadd;
foreach ($form->definition as $key => $defid) {
$addeditem->definition = $datasetdefs[$defid]->id;
$addeditem->value = $form->value[$key];
if ($form->itemid[$key]) {
// Reuse an previously used record
$addeditem->id = $form->itemid[$key];
if (!update_record('question_dataset_items', $addeditem)) {
error("Error: Unable to update dataset item");
}
} else {
unset($addeditem->id);
if (!insert_record('question_dataset_items', $addeditem)) {
error("Error: Unable to insert dataset item");
}
}

foreach ($datasetdefs as $key => $newdef) {
if (isset($newdef->id) && $newdef->itemcount <= $maxnumber) {
$newdef->itemcount = $maxnumber+1;
// Save the new value for options
update_record('question_dataset_definitions', $newdef);
}
}
}
// else Success:
$maxnumber = $addeditem->number;

// removing of dataset items

When the remove button is clicked

} else if (isset($form->deletebutton)
&& $maxnumber == $form->numbertodelete) {
// Simply decrease itemcount where == $maxnumber
foreach ($datasetdefs as $datasetdef) {
if ($datasetdef->itemcount == $maxnumber) {
$datasetdef->itemcount--;
if (!update_record('question_dataset_definitions',
$datasetdef)) {
error("Error: Unable to update itemcount");
}
}
}
--$maxnumber;
}
make_upload_directory("$course->id"); // Just in case
$grosscoursefiles = get_directory_list("$CFG->dataroot/$course->id",
"$CFG->moddata");
The next form is prepared with a new or the last removed item is presented

// Generate a new dataset item (or reuse an old one)
foreach ($datasetdefs as $defid => $datasetdef) {
if (isset($datasetdef->id)) {
$datasetdefs[$defid]->items = get_records_sql( // Use number as key!!
" SELECT number, definition, id, value
FROM {$CFG->prefix}question_dataset_items
WHERE definition = $datasetdef->id ");
}

if (isset($datasetdefs[$defid]->items[$maxnumber + 1]) && (
empty($form->forceregeneration) &&
isset($form->regenerateddefid) &&
$form->regenerateddefid != $defid ||
isset($form->deletebutton))) {
// Reuse existing datasets
} else {
$datasetitem = new stdClass;
$datasetitem->id =
isset($datasetdefs[$defid]->items[$maxnumber + 1]->id)
? $datasetdefs[$defid]->items[$maxnumber + 1]->id : '';
$datasetitem->number = $maxnumber + 1;
if ($this->supports_dataset_item_generation()) {
if (!empty($form->addbutton) || // If we added an item
!isset($form->value) || // If we don't have a value
$form->regenerateddefid == $defid) { // If we explicitly ask for regeneration
$datasetitem->value =
$this->generate_dataset_item($datasetdef->options);
} else {
$definition = array_flip($form->definition);
$datasetitem->value = $form->value[$definition[$defid]];
}
} else {
$datasetitem->value = '';
}
$datasetdefs[$defid]->items[$maxnumber + 1] = clone($datasetitem);
}
}

When you remove a data item, you don't delete it , you just decrease a counter in the dataset.

By doing it this way, this removed data item can be reused if you want it.
==New functions==
We need to create new functions that could be call by '''question/type/datasetdependent/datasetitems.php''' and question/format.php different files.

'''function add_data_items'''($definition_id,$value,$data_item_id)
$addeditem->definition = $definition_id;
$addeditem->value = $value;
if ($data_item_id) {
// Reuse an previously used record
$addeditem->id = $data_item_id;
// perhaps adding a check that the record exist already just in case...
if (!update_record('question_dataset_items', $addeditem)) {
error("Error: Unable to update dataset item");
}
} else {
unset($addeditem->id);
if (!insert_record('question_dataset_items', $addeditem)) {
error("Error: Unable to insert dataset item");
}
}

function remove_data_items()

function get_data_items()

function save_data_items()

(to be continued 1 sept 06)

DDL exceptions

2025-02-10T08:13:37Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Moodle_2.0}}In previous versions problems during upgrade were ignored by default.

==Overview==
[[Image:Ddl_exceptions.png]]

Defined in lib/ddllib.php for now.

===ddl_exception===
Base class for DDL related exceptions

===ddl_table_missing_exception===
Table specified in function parameter does not exist.

===ddl_field_missing_exception===
Field specified in function parameter does not exist.

===ddl_change_structure_exception===
General exception thrown during execution of sql that changes database structure.

==See also==

* [[Exceptions|Exceptions]]: General guidelines for using of exceptions in Moodle 2.0
* [[DML functions|DML functions]]: Where all the functions used to handle DB data. ([[wikipedia:Data_Manipulation_Language|DML]]) are defined.
* [[DDL functions|DDL functions]]: Where all the functions used to handle DB objects ([[wikipedia:Data_Definition_Language|DDL]]) are defined.

DB layer 2.0 problems

2025-02-10T08:13:08Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Work in progress}}{{Template:Development:dmllib 2.0}}{{Moodle_2.0}}
Every section on this page will show important problems present in the adoption of the new dmllib 2.0. Each section will define the problem, its impact and, when available, its solution. Every section will include one line containing its status (''''Open'''', ''''Decided''', ''''Work in progress'''', ''''Finished'''', ''''Tested'''' and ''''Closed'''').

Of course, feel free to use the [http://tracker.moodle.org Bug Tracker] to follow the daily evolution of each one of these problems by adding one link inside each section pointing to the proper bug.

=== Do we still need record cache ===
('''Status:''' Open - '''Severity:''' Not Critical - '''Bug:''' not defined)

::No we do not, but people must stop using get_record() in large loops (like the case of latest conditional changes in gradebook). [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]]

=== Unknown parameter types in query parameters ===
('''Status:''' Open - '''Severity:''' Not Critical - '''Bug:''' not defined)

We can find out the correct type of each param for inserts and updates, but in case of other queries it might be a problem :-( we could use optional type hints in parameter names like :numberI, :numberD, :nameS where IDS means int, double, string (like in mysqli driver)
::Wouldn't some params->setInt(), setString(), setNull() do the trick? Once more the possible substitution of the plain array of values to one array of objects seems to appear in the discussion... [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 19:35, 6 May 2008 (CDT)
=== casting to (int) in insert_record() ===
('''Status:''' Open - '''Severity:''' Not Critical - '''Bug:''' not defined)
what happens if db returns string with number greater than max int?
:What means casting to int? Why we need that? IMO a more serious problem are some big sites raising the max int(10) sequence value (logs tables, backup and restore...). [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 19:35, 6 May 2008 (CDT)
::well, some code (like modedit) uses is_int() on results from insert_report() which was was breaking badly when I thied to remove the (int) casting from insert_record() [[User:Skodak|Skodak]]

=== Do we have to use array_values() on $params array in order to re-key the array when using "?" in query? ===
('''Status:''' Open - '''Severity:''' Not Critical - '''Bug:''' not defined)

It looks like pdo needs that [http://en.php.net/manual/en/pdostatement.execute.php]

:: yes we must do that because the keys must be 0,1,3,... in some drivers [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]]

=== DB layer functional tests ===
('''Status:''' In progress - '''Severity:''' Critical - '''Bug:''' MDL-19057)

reading the comments in php manual it seems like we need a big battery of unit tests to verify everything works as expected
:100% agree. For XMLDB stuff, for example... I've more that "custom" tests built in the XMLDBEditor. And it only covers a few DDL commands. I guess we'll need at least.... 100 tests for good dmllib testing. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 19:39, 7 May 2008 (CDT)

=== persistent connections ===
('''Status:''' Open - '''Severity:''' Not Critical - '''Bug:''' not defined)

should we limit persistent connections only for simple scripts like file.php and theme stuff? maybe this could make persistent connections more reliable. it could be implemented as some define before require config.php
:I would vote to include that define (CAN_USE_PERSISTENT_CONNECTION) in some files, agree. But will create one $CFG->experimentwithpersistentconnections (config-dist.php) to be able to play with it in the safe side. I remember tons of headaches with persistent connections in Moodle early days (due to drivers implementation, mainly). [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 19:39, 7 May 2008 (CDT)

=== old mysql driver ===
('''Status:''' Open - '''Severity:''' Not Critical - '''Bug:''' not defined)

should we deprecate native mysql driver and use mysqli or pdo:mysql instead?
: +1 [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 18:36, 5 May 2009 (UTC)
::we can remove it now completely imo [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]]

=== ADOdb Insert_ID() function under MSSQL, using placeholders doesn't work ===
('''Status:''' Closed - '''Severity:''' Critical - '''Bug:''' MDL-14886)

'''Problem:''' Queries '''using placeholders''' under MSSQL are executed by one sp_executesql() procedure call. In MSSQL procedures, triggers are executed into new scopes (like "shells"), so the Insert_ID() function (internally usind SCOPE_IDENTITY()) doesn't work at all, because the insert has been executed in another scope.

'''Solution:''' Patch ADOdb driver so, each time one INSERT is going to be executed by sp_executesql(), we'll add one SCOPE_IDENTITY() in the same procedure execution (that way, both the insert and the identity will be in the same scope). Once executed, return the value of the identity by the standard Insert_ID() function. BC compatible 100% with current code if implemented that way.

::+1 to stop using adodb and emulate bound params if needed -like in other drivers

DB layer 2.0 migration docs

2025-02-10T08:11:25Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Template:Development:dmllib 2.0}}{{Moodle_2.0}}
== Introduction ==
Much of the following documentation will not make much sense unless you first read [[XMLDB_Documentation|the XMLDB documentation]]. Please read it first if you would like to join the effort to convert Moodle's code to the new dmllib.

Also, it's recommended to read the whole [[wikipedia:Data_Definition_Language|DDL]] and [[wikipedia:Data_Manipulation_Language|DML]] documentation before starting with the migration. That will allow you to have some initial knowledge about the new architecture.

This article defines all the changes that need to be performed in Moodle 1.9 code in order to make it run properly under the new Moodle 2.0 DB layer. The changes below are grouped into 2 main blocks, [[XMLDB_Documentation|XMLDB]] and [[wikipedia:Data_Manipulation_Language|DML]], to keep them organised. Additional minor changes may be required in the [[wikipedia:Data_Definition_Language|DDL]] code, but won't be documented here.

Although the order of changes shown on this page isn't mandatory at all, it can be interesting to follow the migration progress to be able to understand and learn a bit more about all them. That way, you'll end up knowing not only what to change but how and why those changes are required.

Each change will be as simple as possible, representing one easy rule to follow to adapt the code. When anything becomes too complex to be explained as one simple rule, it will contain one link to the [[dmllib_2.0_examples|examples page]].

For any problem in the migration of code, it's recommended to use the [http://moodle.org/mod/forum/view.php?id=55 General developer forum] at [http://moodle.org moodle.org]. Also if you find a bug in the process, please report it in the [http://tracker.moodle.org/browse/MDL-14679 Moodle Tracker], so that developers will be able to fix it ASAP.

The Glossary module was used as the basis for many of the examples below.

And finally, feel free to complete/fix the list below with the changes you find in the progress of migration; that will certainly help many developers. Thanks!

__TOC__

== check_db_syntax: One helper script ==

Before you start migrating your code to Moodle 2.0, it's recommended you install and run the [http://download.moodle.org/download.php/direct/tools/check_db_syntax.zip/ check_db_syntax.php] script. Simply copy it to the main folder of your plugin and execute it (from command line or via web). It will show you a list of old DB usages that need to be transformed following the information below in this article.

If you think that something is missing in the script or have any ideas to improve it, feel free to do that yourself, commenting about it in MDL-15237. Thanks!

Also, this (perl-compatible - works in Eclipse, hopefully elsewhere) regex:

(?<!->)(?<!function )(?<!\$)\b(?:(?:count|delete|get|insert|update)_record(?!s_csv)|[gs]et_field|record_exists|execute_sql)|\$CFG->prefix|rs_(?:fetch|close)|(add|strip)slashes(?!_js)

will find most of the things in your code that need attention, with few false positives.

== XMLDB/DDL changes ==

=== Some comments ===

* When changing DB structures it's highly recommended to use the [[XMLDB editor|XMLDB Editor]] (Admin->Development->XMLDB Editor). It is a safe way to edit install.xml files and to get correct PHP code to be used in upgrade.php scripts.
* If you have some doubts about the list of changes below, it's highly recommended to take a look at some code in core modules, blocks... whatever you need. They are a good reference.
* The most noticeable change (from a migration perspective) in the DDL stuff is that, starting with Moodle 2.0, we have decided to '''drop support for enum (check constraint) fields completely'''. See MDL-18577 and [http://moodle.org/mod/forum/discuss.php?d=118852 this discussion]. That implies changes in different parts of the DB stuff (XML files, function parameters, dropping existing enums...) and are commented with more detail below.

=== The changes ===
* STATEMENTS section was replaced by db/install.php code and db/log.php
* Few other changes are required in install.xml files (that's good news!). Although you must know these:
** The '''ENUM''' and '''ENUMVALUES''' attributes present in your install.xml files will be completely ignored both by the DLL generation stuff and by the XMLDB Editor.
** In Moodle 2.1, those attributes ('''ENUM''' and '''ENUMVALUES''') will be 100% forbidden, so it's highly recommended to erase them beginning now (Moodle 2.0).
** The XMLDB Editor will detect them when loading any install.xml file and will suggest you to fix that easily with one 1-click® option.
** No matter if you have fixed that with the 1-click® option when loading the files... the [[XMLDB editor|XMLDB Editor]] will save any edited install.xml files without those attributes.
** If your Moodle 1.9.x code '''has some enum defined in the database''', you will need to create one upgrade block (in db/upgrade.php) to drop it (the enum, not the field! ;-) as part of the migration from Moodle 1.9 to 2.0 by using the new '''[[DB layer 2.0 examples#Dropping one enum from one field|drop_enum_from_field()]]''' method.
** Of course, if you don't use/like the XMLDB Editor, you can erase them manually with something like this:
perl -p -e 's/ENUM(VALUES)?=".*?" //g' < install.xml > install.xml.new

* All upgrade.php scripts, within the main xxxx_upgrade function must have '''$DB''' (uppercase) in the globals declaration (along with others if needed). Example (from the Glossary module):
<syntaxhighlight lang="php">
function xmldb_glossary_upgrade($oldversion=0) {

global $CFG, $THEME, $DB;
</syntaxhighlight>
* All upgrade.php scripts must NOT have '''$db''' (lowercase) in the globals declaration. Delete it if present.
* After the global declaration in the points above, this line must be present (we'll need it later):
<syntaxhighlight lang="php">
$dbman = $DB->get_manager(); /// loads ddl manager and xmldb classes
</syntaxhighlight>
* All '''XMLDBTable''' instances in your upgrade code must be replaced by '''xmldb_table''' (no change in parameters)
* All '''XMLDBField''' instances in your upgrade code must be replaced by '''xmldb_field''' (with change in params, both $enum and $enumvalues are out from function declaration!)
* All '''XMLDBIndex''' instances in your upgrade code must be replaced by '''xmldb_index''' (no change in parameters)
* All '''XMLDBKey''' instances in your upgrade code must be replaced by '''xmldb_key''' (no change in parameters)
* All the '''addFieldInfo()''' methods must be replaced by '''add_field()''' (with change in params, both $enum and $enumvalues (the 7th and 8th parameters) are out from function declaration!)
* All the '''addIndexInfo()''' methods must be replaced by '''add_index()''' (no change in parameters)
* All the '''addKeyInfo()''' methods must be replaced by '''add_key()''' (no change in parameters)
* All the '''setAttributes()''' methods must be replaced by '''set_attributes()''' (with change in params, both $enum and $enumvalues (the 6th and 7th parameters) are out from function declaration!)
* All the DDL functions used in your upgrade code must be transformed as detailed below (it's simply about adding '''"$dbman->"''' - without the quotes - before each function call). No changes in parameters are required:
** table_exists ==> $dbman->table_exists
** field_exists ==> $dbman->field_exists
** index_exists ==> $dbman->index_exists
** find_index_name ==> $dbman->find_index_name
** find_check_constraint_name ==> $dbman->find_check_constraint_name ('''DEPRECATED in 2.0. OUT in 2.1''')
** check_constraint_exists ==> $dbman->check_constraint_exists ('''DEPRECATED in 2.0. OUT in 2.1''')
** find_sequence_name ==> '''OUT in 2.0''', see MDL-20349
** create_table ==> $dbman->create_table
** drop_table ==> $dbman->drop_table
** rename_table ==> $dbman->rename_table
** add_field ==> $dbman->add_field
** drop_field ==> $dbman->drop field
** rename_field ==> $dbman->rename_field
** change_field_type ==> $dbman->change_field_type
** change_field_precision => $dbman->change_field_precision
** change_field_unsigned ==> $dbman->change_field_unsigned
** change_field_notnull ==> $dbman->change_field_notnull
** change_field_enum ==> $dbman->change_field_enum ('''OUT in 2.0''', see '''[[DB layer 2.0 examples#Dropping one enum from one field|drop_enum_from_field()]]''' to get rid of remaining ENUMs in code).
** change_field_default ==> $dbman->change_field_default
** add_key ==> $dbman->add_key
** drop_key ==> $dbman->drop_key
** add_index ==> $dbman->add_index
** drop_index ==> $dbman->drop_index
* The DDL functions that change things (create/drop/rename/add)_(table/field/index) no longer return boolean. Instead, they throw an exception if they fail. So your upgrade.php no longer needs to use a '''$result''' variable, and instead should use the '''upgrade_mod_savepoint()''' function:
<syntaxhighlight lang="php">/** old way **/
if ($result && $oldversion < 2008061000) {
$table = new xmldb_table('facetoface_submissions');
$field = new xmldb_field('notificationtype');
$field->set_attributes(XMLDB_TYPE_INTEGER, '10', XMLDB_UNSIGNED, XMLDB_NOTNULL, null, '0', 'timemodified');

$result = $result && $dbman->add_field($table, $field);
}

/** new way **/
if ($oldversion < 2008061000) {
$table = new xmldb_table('facetoface_submissions');
$field = new xmldb_field('notificationtype');
$field->set_attributes(XMLDB_TYPE_INTEGER, '10', XMLDB_UNSIGNED, XMLDB_NOTNULL, null, '0', 'timemodified');

$dbman->add_field($table, $field);
upgrade_mod_savepoint(true, 2008061000, 'facetoface');
}</syntaxhighlight>

* Finally, and not less important, your code (module, block... plugin) must guarantee that it can be upgraded '''ONLY''' from Moodle 1.9, so any previous upgrade code can be safely deleted. '''Moodle 2.0 requires Moodle 1.9''' to be upgraded, so everybody will run the 1.9 => 2.0 upgrade (with other paths like 1.8 => 2.0 not being possible). This is a good time to clean-up your upgrade code a bit ;-). Don't forget to take a look at the [[XMLDB editor|XMLDB Editor]] and the core modules to see how [http://cvs.moodle.org/moodle/lib/db/upgrade.php?view=markup upgrade.php] files should look in Moodle 2.0.

== DML changes ==

=== Some comments ===
* The ENTIRE CODEBASE requires an update of ALL database query function calls. Expect most moodle files to be affected by this change.

* This is the more complex part to migrate to have the code working under Moodle 2.0, not because of the complexity of the changes themselves (90% of them will be really easy), but because you'll need to triple-check everything works as expected after changes.

* Along the changes below, you'll find links to some examples that will try to make things easier. Anyway, if you are blocked at any point, please ask in forums or tracker (see links at the beginning of the page). Sure it has a good enough solution.

* Once more it's highly recommended to take a look to Moodle core code, searching for similar examples. Of course, new meaningful examples are welcome, and also any clarification in the list of changes below. Feel free to do it, this is a wiki!

* Finally, one more explanation: The changes below have been split into three sections. First one, (called '''"The golden changes"''') are modifications that must be applied to ALL the transformations defined in the second section ('''"The iron changes"'''). Sure you'll understand that after reading them (it's basically a matter of not repeating the golden ones within each iron one, just imagine they are everywhere). Finally other changes details can be found in the '''"The tin changes"''' section.

=== The golden changes ===
''PLEASE read the API before going crazy with search & replace''! You can find all the new methods in lib/dml/moodle_database.php. This is essential because some method signatures have changed (params are different), and some method names have even changed (execute_sql() is now execute()).

Each of the golden changes below is given one short name (G1, G2, G3...) for further reference in the rest of the documentation. Let's go:

* G1: Wherever old functions are used (get_record*, get_field*, set_field, insert_record, update_record, count_records*, delete_records, record_exists), the global $DB must be used as the object on which these functions are called (e.g. get_record_select() becomes $DB->get_record_select()).
<syntaxhighlight lang="php">
Example:

// Old syntax
$sql = "WHERE id = 1";
get_record_select('user', $sql);

// New syntax
global $DB;
$sql = "WHERE id = 1";
$DB->get_record_select('user', $sql);
</syntaxhighlight>
::Note: for some functions, the $params array is not the second function parameter. For example, set_field:'''
<syntaxhighlight lang="php">
// Old syntax
set_field('user', 'firstname', 'Peter', 'id', 1);

// New syntax
global $DB;
$DB->set_field('user', 'firstname', 'Peter', array('id' => 1));
</syntaxhighlight>

* G2: All uses of addslashes() '''must be removed'''. They are no longer needed

* G3: All the functions that used to accept a list of string params in the form "param1, value1, param2, value2" now need to be given an array of key=>value pairs as a replacement for these params. Other params remain as before. Check the new API for any exceptions.
<syntaxhighlight lang="php">
Example:

// Old syntax:
$user = get_record("user", "firstname", "Peter", "lastname", "Cantrophus");

// New syntax:
global $DB;
$conditions = array("firstname" => "Peter", "lastname" => "Cantrophus");
$user = $DB->get_record("user", $conditions);
</syntaxhighlight>
::Note: The example above has been written out in full for clarity. You can use the array() directly within the function call, without using a temporary variable, if you prefer:''
<syntaxhighlight lang="php">
global $DB;
$user = $DB->get_record("user", array("firstname" => "Peter", "lastname" => "Cantrophus") );
</syntaxhighlight>

* G4: rs_fetch_next_record($rs) is deprecated, in favour of the simple foreach($rs as $var). Calls to rs_close() must be replaced by $rs->close();
<syntaxhighlight lang="php">
Example:

// Old syntax
while($result = rs_fetch_next_record($rs)) {
...
}
rs_close();

// New syntax
foreach ($rs as $result) {
...
}
$rs->close();
</syntaxhighlight>

* G5: Placeholders must be used for table names. Instead of {$CFG->prefix}tablename, use {tablename}.

<syntaxhighlight lang="php">
Example:

// Old syntax
$sql = "SELECT * FROM {$CFG->prefix}user";

// New syntax
$sql = "SELECT * FROM {user}";
</syntaxhighlight>

* G6: When PHP variables are used in SQL queries, they must be replaced by parameters. You have the choice between two approaches: ordered parameters, or named parameters.
** Ordered parameters use a simple array of values, which are given to the DML function as $params. The values in the SQL code are simply question marks (?) replacing the values. They are replaced by the DML code one by one, substituting each question mark (?) with the next value in the $params array.
** Named parameters use an associative array of name => value pairs as the $params array. The values in the SQL code are replaced with a colon (:) followed by the key associated with the value, in the $params array. Note that named params '''must be unique''', no matter if the value passed is the same.

<syntaxhighlight lang="php">
Examples:

// Old syntax
$sql = "SELECT id, firstname FROM {$CFG->prefix}user WHERE firstname = 'Peter' AND lastname = 'Cantrophus'";
$user = get_record_sql($sql);

// New syntax: ordered params
global $DB;
$params = array('Peter', 'Cantrophus');
$sql = "SELECT id, firstname FROM {user} WHERE firstname = ? AND lastname = ?";
$user = $DB->get_record_sql($sql, $params);

// New syntax: named params
global $DB;
$params = array('firstname' => 'Peter', 'lastname' => 'Cantrophus');
$sql = "SELECT id, firstname FROM {user} WHERE firstname = :firstname AND lastname = :lastname";
$user = $DB->get_record_sql($sql, $params);
</syntaxhighlight>

To obtain a value for the LIKE operator, include any % signs into the parameter string. For example, code that was previously <tt>"LIKE '$value%'"</tt> becomes <tt>"LIKE ?"</tt> with the parameter <tt>$value.'%'</tt>.

* G7: Replacement of the IN(...) syntax: We no longer hard-code this in our SQL queries, we use a function which determines whether the IN() syntax is needed, or, if there is only one value to compare, the equal (=) sign can be used.

<syntaxhighlight lang="php">
Example:

// Old syntax:
$depends_on = array(1, 43, 553);
$gis = implode(',', $depends_on);
$sql = "SELECT *
FROM {$CFG->prefix}grade_items
WHERE id IN ($gis)";
$items = $DB->get_records_sql($sql);

// new syntax
global $DB;
$depends_on = array(1, 43, 553);
list($usql, $params) = $DB->get_in_or_equal($depends_on);
$sql = "SELECT *
FROM {grade_items}
WHERE id $usql";
$items = $DB->get_records_sql($sql, $params);
</syntaxhighlight>

'''Note:''' to combine the last two, do the G7 IN SQL stuff first to generate the params array, then do something like
$params['firstname'] = 'peter';
to add the stuff for G6

=== The iron changes ===

*I1: Originally the '''sql_substr()''' function was used without parameters and it returned only the name of the "substring" function to be used under each DB. In Moodle 2.0 and upwards, it has 3 parameters (2 being mandatory) and it returns the complete SQL text to be used when handling substrings. Note that positions in this function are 1-based (first char has index 1).

<syntaxhighlight lang="php">
Example:

// Old syntax
$records = get_records_sql("SELECT " . sql_substr() . "(firstname, 1, 20)" . " FROM ... ..."

// New syntax
$records = $DB->get_records_sql("SELECT " . $DB->sql_substr('firstname', 1, 20) . " FROM ... ..."
</syntaxhighlight>

=== The tin changes ===
List of minor changes

* T1: Originally get_records() and similar functions were returning false if no records found. All these methods are now always returning arrays, empty array in case of no records found. Please note that get_record() still returns false if specified record not found.
<syntaxhighlight lang="php">
Example:

// Old syntax
if (!$posts = get_records('forum_posts', 'parent', 666)) {
$posts = array()
}

// New syntax
global $DB;
$posts = $DB->get_records('forum_posts', array('parent'=>666));
</syntaxhighlight>

* T2: Originally DML functions were returning ''false'' if error occurred - ''dml_exception'' is thrown now instead.
<syntaxhighlight lang="php">
Example:

// Old syntax
$record = new object();
$record->course = 5;
if (!$id = insert_record('sometable', $record)) {
error('can not insert new record');
}

// New syntax
global $DB;
$record = new object();
$record->course = 5;
$id = $DB->insert_record('sometable', $record);
</syntaxhighlight>

== See also ==

* [[XMLDB Documentation|XMLDB Documentation]]: where both xmldb and ddl stuff is explained.
* [[DDL functions|DDL functions]] - Documentation for all the Data Definition Language (DDL) functions available inside Moodle.
* [[DML functions|DML functions]] - Documentation for all the Data Manipulation Language (DML) functions available inside Moodle.
* [[DDL exceptions|DDL exceptions]] - DDL exceptions information.
* [[DML exceptions|DML exceptions]] - DML exceptions information.

DB layer 2.0 implementation plan

2025-02-10T08:10:37Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Template:Development:dmllib 2.0}}{{Moodle_2.0}}__NOTOC__This page contains information related to the process of development of the new xmldb/ddl/dml stuff coming with Moodle 2.0. It describes how the process has been split into some well identified milestones, and includes the summary of all the meetings and discussions about the new Moodle 2.0 DB layer.

For a complete list of tasks related with this development you can go to MDL-14679 (everything is there). Also, don't forget to visit the [[dmllib 2.0 problems|problems page]] if you are curious about the main stoppers we have found in the project.

Last, and not less important, the due date for all this stuff is '''June 24th 2008'''. Just in time to continue with all the rest of amazing features coming with [[Roadmap|next Moodle 2.0 release]].

== Milestones ==

=== M1: initial commit (due date: May 15th) - HEAD ===
:1. API should be stable, tested during conversion of several parts or moodle
:2. $db-> references are gone
:3. direct adodb function calls should be all gone (except auth and enrol)
:4. some functions from dmllib are deprecated/removed
:5. old ddllib function are not used at all now
:6. XMLDB editor should fully work now
:7. BC compatible 100%

=== M2: 4 DBs passing all tests (due date: May 27th) - HEAD ===

:1. mssql and ora related work
:2. use of adodb in enrol and auth plugins
:3. functional unit tests (own-db and multi-db)
:4. logging/profiling/exceptions
:5. xmldb public API refactoring
:6. install
:7. BC compatible 100%
:8. In general everything titled as [http://tracker.moodle.org/browse/MDL-14679 "M2" in the Bug Tracker].

=== M3: core stuff, pre magic_quotes off tasks (due date: June 24th) - HEAD ===

:1. Needs to be detailed in [[dmllib 2.0 migration docs|dmllib 2.0 migration docs]].
:2. Tasks between May28th and June 11th
:3. API should be available in the [http://phpdocs.moodle.org phpdocs site]
:4. BC compatible 100%
:5. In general everything titled as [http://tracker.moodle.org/browse/MDL-14679 "M3" in the Bug Tracker].

=== M4: big hacking, post magic_quotes off tasks (due date: June 24th) - In parallel with M3 - (HEAD, BRANCH, PATCH??) ===

:1. BREAKAGE with old code.
:2. Documentation finished (Docs (examples, architecture, migration guide...), PHP Docs).
:3. In general everything titled as [http://tracker.moodle.org/browse/MDL-14679 "M4" in the Bug Tracker].

=== M5: Moodle tests using real & mockup dmllib (starting on May 27th...) - In parallel and after M3 and M4 - HEAD ===

:1. Needs good documentation for developers
:2. Will be huge but useful
:3. Always try to be able to run tests from cli script (apart from UI) to be able to execute them daily and report status in some URL (html output).

=== ME1: Discuss/decide/implement/test logically nested (delegated) transactions ===

See these for more info:

# [http://moodle.org/mod/forum/discuss.php?d=135847 moodle.org initial discussion].
# MDL-20625 - Bug in the Tracker with different alternatives and agreement process.
# [[DB layer 2.0 delegated transactions|DB layer 2.0 delegated transactions]] article in Moodle Docs, where final implementation is detailed.

== Meetings ==

* [http://docs.google.com/Doc?id=dgzf39jp_1gkks3pd3 MDM-20080501 Dmllib 2.0] - Penny, Petr and Eloy.
* [http://docs.google.com/Doc?id=dgzf39jp_5fv3j3jd7 MDM-20080508 Dmllib 2.0] - Penny, Petr, Nicolas and Eloy.
* [http://docs.google.com/Doc?id=dgzf39jp_7tmcr5jc5 MDM-20080513 Dmllib 2.0] - Penny, Petr, Nicolas and Eloy.
* [http://docs.google.com/Doc?id=dgzf39jp_11fdj3jhg8 MDM-20080515 Dmllib 2.0] - Penny, Petr, Nicolas, Martin and Eloy.
* [http://docs.google.com/Doc?id=dgzf39jp_12hmwjmzfq MDM-20080522 Dmllib 2.0] - Penny, Petr, Nicolas, Martin and Eloy.
* MDM-20080526 Dmllib 2.0 - Penny, Petr, Nicolas, Martin and Eloy.

DB layer 2.0 functional testing

2025-02-10T08:10:27Z

Sarjona:

{{Template:WillNotMigrate}}

{{Template:Development:dmllib 2.0}}{{Moodle_2.0}}

Functional unit tests can be used to test the interaction of Moodle and database, it is testing following:
* SQL database server
* PHP database driver
* Moodle DB connection settings, driver configuration and server settings
* Moodle DDL generator
* Moodle DML driver

You can test current database specified in config.php, you can also specify other DB servers via following config.php settings, for example:
<syntaxhighlight lang="php">
$CFG->func_test_db_1 = array("native", "mysqli", "localhost", "root", "yourpassword", "moodle", "tst_", array('dbengine'=>'InnoDB'));
$CFG->func_test_db_2 = array("native", "mysqli", "localhost", "root", "yourpassword", "moodle2", "tst_", array('dbengine'=>'MyISAM'));
$CFG->func_test_db_3 = array("native", "pgsql", "localhost", "moodleuser", "yourpassword", "moodle2", "tst_", NULL);
$CFG->func_test_db_4 = array("native", "mssql", "192.168.15.41", "sa", "yourpassword", "moodle", "tst_", NULL);
</syntaxhighlight>

== DDL tests ==
All DDL test must pass on any production server.

== DML tests ==
Ideally all DML tests should pass on production servers.

Common problems:
* MySQL MyISAM engine does ACID compliant and does not support transactions, please consider upgrading to InnoDB.
* MySQL supports only a limited number of collations, this may cause significant problems for non-english languages
* Oracle is known to fail in multiple tests (work in progress)

DB layer 2.0 examples

2025-02-10T08:09:50Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Template:Development:dmllib 2.0}}{{Moodle_2.0}}__NOTOC__

=== Dropping one enum from one field ===

In Moodle 2.0, we have '''discontinued support for ENUM''' (check constraint) in DB columns. See MDL-18577 about that. So, any plugin using enums in Moodle 1.9 will need to drop them as part of the upgrade to Moodle 2.0. To achieve that, as commented in the [[DB layer 2.0 migration docs#XMLDB/DDL changes|migration docs]], the '''drop_enum_from_field()''' method will be used. Here it's one '''real''' example used to drop the enum defined in the forum->type column as part of the upgrade from Moodle 1.9 to 2.0 (just adjust it for your own needs):
<syntaxhighlight lang="php">
/// Dropping all enums/check contraints from core. MDL-18577
if ($result && $oldversion < 2009042700) {

/// Changing list of values (enum) of field type on table forum to none
$table = new xmldb_table('forum');
$field = new xmldb_field('type', XMLDB_TYPE_CHAR, '20', null, XMLDB_NOTNULL, null, 'general', 'course');

/// Launch change of list of values for field type
$dbman->drop_enum_from_field($table, $field);

/// forum savepoint reached
upgrade_mod_savepoint($result, 2009042700, 'forum');
}
</syntaxhighlight>

=== Mixing query params and IN params ===

As you know, in Moodle 2.0 we are using placeholders for all the parameters passed to any SQL statement (see [[DB layer 2.0 migration docs#g6|G6]]. Also, we use one special function to convert any list of values to the proper IN/EQUAL clause and associated params (see [[DB layer 2.0 migration docs#g7|G7]]).

But what happens when we want to mix both type of params (query params and IN params) in the same query? Here it's one example:

'''Objective:''' return the number of forum discussion per course belonging to a given list of courses (IN params) and one type of forum (query param).

<syntaxhighlight lang="php">
/// Here it's the query param (we are looking for 'general' forums in this example)
$queryparams = array('general');

/// Here we calculate the IN clause (the list of courses we are going to search)
/// it returns 2 values: the SQL IN clause needed and the params array to be applied
list($insql, $inparams) = $DB->get_in_or_equal(array(1, 2, 3, 4, 5, 6));

/// Here it's the query we are going to execute, with the IN clause injected in place
$sql = "SELECT f.course, COUNT(*) count
FROM {forum} f
JOIN {forum_discussions} d ON d.forum = f.id
WHERE f.type = ?
AND f.course $insql
GROUP BY f.course";

/// Here we merge all params (query ones and IN clause ones,
/// respecting the order they are used in the query!)
$params = array_merge($queryparams, $inparams);

/// Execute the query, returning the expected count per course
$records = $DB->get_records_sql($sql, $params);
</syntaxhighlight>

Note that '''is really important to respect the order of the params''' when merging them in case you are using question mark placeholders in your query. Alternatively, you can use named params if you want to skip that ordering potential issue, specially if your query is very complex or highly dynamic. Here it's the same example using named params (see the 2nd param used in the get_in_or_equal() method call), that's all :

<syntaxhighlight lang="php">
/// Here it's the query param (we are looking for 'general' forums in this example)
$queryparams = array('forum_type' => 'general');

/// Here we calculate the IN clause (the list of courses we are going to search)
/// it returns 2 values: the SQL IN clause needed and the params array to be applied
list($insql, $inparams) = $DB->get_in_or_equal(array(1, 2, 3, 4, 5, 6), SQL_PARAMS_NAMED);

/// Here it's the query we are going to execute, with the IN clause injected in place
$sql = "SELECT f.course, COUNT(*) count
FROM {forum} f
JOIN {forum_discussions} d ON d.forum = f.id
WHERE f.type = :forum_type
AND f.course $insql
GROUP BY f.course";

/// Here we merge all params (query ones and IN clause ones,
/// as we are using named params, order isn't important)
$params = array_merge($inparams, $queryparams);

/// Execute the query, returning the expected count per course
$records = $DB->get_records_sql($sql, $params);
</syntaxhighlight>

== See also ==

* [[XMLDB Documentation|XMLDB Documentation]]: where both xmldb and ddl stuff is explained.
* [[Database|Database coding guidelines]]: where some basic rules to follow are defined.
* [[DDL functions|DDL functions]] - Documentation for all the Data Definition Language (DDL) functions available inside Moodle.
* [[DML functions|DML functions]] - Documentation for all the Data Manipulation Language (DML) functions available inside Moodle

DB layer 2.0 delegated transactions

2025-02-10T08:09:33Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Work in progress}}{{Template:Development:dmllib 2.0}}{{Moodle_2.0}}__NOTOC__
=== General principles ===

# Everybody thinks it's a good idea to have those logical nested transactions in Moodle (but me and ML)
# No matter of they nested nature, they are really '''"delegated transactions"''' (so outer levels get the control over inner ones), so we are going to apply that naming to enforce the real concept.
# Code will '''never''' rely on rollback happening. it's only a maeasure to reduce (not to eliminate) DB garbled information.
# Any problem related with the use of transactions (unfinished ones, unbalanced, finished twice...) will end '''always''' with one transaction_exception that will '''always''' end performing one DB rollback.
# If one transaction (at any level) has been marked for rollback() there won't be any method to change it. Finally Moodle will perform the DB rollback.
# If one transaction (at any level) has been marked for commit() it will be possible to change that status to rollback() in any outer level.
# It will be '''optional''' to catch exceptions when using transactions, but if they are caught, then it's mandatory to mark the transaction for rollback()
# Any explicit rollback() call will pass the exception originating it, i.e. rollback($exception) to be re-thrown.
# API will work in a natural and similar fashion to current recordsets one.
# We'll start '''recommending''' to use InnoDB for 2.0 in environmental tests. Posibly, at some point in the future that will become a '''must'''. But '''it is not''' for now (be warned!).

=== The API ===

# All the handling must go, exclusively, to moodle_database object, leaving real drivers only implementing (protected) the old begin/commit/rollback_sql() functions.
# One array of objects of type moodle_delegated_transaction will be stored / checked from $DB
# $DB will be the responsible to instantiate / accumulate / pair / compare moodle_delegated_transactions
# Each moodle_transaction will be able to set the global mark for rollback. Commit won't change anything.
# Inner-most commit/rollback will printout one complete stack of moodle_transactions information if we are under DEBUG_DEVELOPER and new setting (delegatedtransactionsdebug) is enabled.
# Normal usage of the moodle_transaction will be:
<syntaxhighlight lang="php">
$transaction = $DB->start_delegated_transaction();
// Perform some $DB stuff
$transaction->allow_commit();
</syntaxhighlight>
7. If, for any reason, developer needs to catch exceptions when using transactions, it will be mandatory to use it in this way:
<syntaxhighlight lang="php">
try {
$transaction = $DB->start_delegated_transaction();
// Perform some $DB stuff
$transaction->allow_commit();
} catch (Exception $e) {
//extra cleanup steps
$transaction->rollback($e); // rethrows exception
}
</syntaxhighlight>
8. In order to be able to keep some parts of code out from top transactions completely, if we know it can lead to problems, we can use:
<syntaxhighlight lang="php">
$DB->transactions_forbidden(); // Instant check to confirm we aren't using transactions in this point. Will throw exception if transaction is found.
</syntaxhighlight>

===The Flow===

[[Image:TransactionsAndExceptionsFlow.png|thumb|right|caption]]
# Any default exception handler will:
## Catch uncaught transaction_exception exceptions,
## Properly perform the DB rollback
## debug/error/log honouring related settings.
## inform with as many details as possible (token, place... whatever).
# Any "footer" (meaning some place before ending <html> output) will:
## Detect "in-transaction" status.
## Let execution continue, transaction is automatically rolled back in $DB->dispose()
## inform with as many details as possible (token, place... whatever).
# $DB->dispose() will:
## Detect "in-transaction" status.
## log error (not possible to honour settings!)
## Properly perform the full DB rollback

===Related tasks===

# Move this to MoodleDocs and publicy in Dev Forum.
# Implement fulfilling current specs / review / test iterations
# Re-enforce in Docs, phpdocs, everywhere, the "Code will *never* rely on rollback happening" and the "delegated" nature of the whole thing.
# Be extremely careful about any use of delegated transactions until we get used to them, reviewing them in core often.
# Point somewhere about the move to InnoDB, pros/cons, migration process... to have it documented.

DB layer 2.0

2025-02-10T08:09:00Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Template:Development:dmllib 2.0}}{{Moodle_2.0}}__NOTOC__
== Objectives ==

* Switch to prepared statements - using placeholders and preparing statements protects against sql injection
* Remove the need for data to be add/strip slashed all over the place in the code.
* Enable easier and productive unit tests.

== Requirements ==

* 100% cross-db
* OOP implementation:
** Full abstraction: Hide underlying libraries (adodb, pdo...) and drivers to Moodle developers completely.
** Make it so that the database object can be subclassed - this means for unit tests that want to test database access, the test framework can override necessary methods
** support ? and :param parameter types (independently of the param types supported by each driver).
** global $DB
** profiling, logging and exceptions
* Easy to use (consistent and similar to current dmllib 1.0)
* Easy to migrate (provide documentation and utilities to help on that)
* Complete unit testing (self)
* Easy unit testing (moodle - real and mockup)
* Well documented (PHPDocs + use examples)
* Tasks, bugs and progress tracked in MDL-14679
* Due date: June 24th 2008

== See also ==

* [[XMLDB Documentation|XMLDB Documentation]]: where both xmldb and ddl stuff is explained.
* [[DDL functions|DDL functions]] - Documentation for all the Data Definition Language (DDL) functions available inside Moodle.
* [[DML functions|DML functions]] - Documentation for all the Data Manipulation Language (DML) functions available inside Moodle.

Customizing Moodle

2025-02-10T08:08:09Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

Many of us have been making small modifications to our Moodle installs, and this is the place to share them. Please take care with any of these modifications - they may have not been widely tested! Be sure to back up your files and database if required.

*[[Hard-coded Variables]]

*[[Course Approval]]
*[[Front Page]]
*[[Maintaining Moodle with Dreamweaver]]

Customisable user profiles

2025-02-10T08:06:34Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

== Overview ==

The main goal is to allow administrators to add/edit user profile fields. These fields may also be categorised, ordered, locked, hidden.

== Database Changes ==

=== New tables ===

There are 3 new tables:
* '''user_info_field'''
* '''user_info_category'''
* '''user_info_data'''

=== Splitting the current user table ===
In version 2.0, the following fields will be moved from the '''user''' table and placed in a category named '''optional'''
*icq
*skype
*yahoo
*aim
*msn
*phone1
*phone2
*institution
*department
*address
*url

The remaining fields will remain hardcoded in the user profile form.

== Admin's Interface ==

=== Various field flags ===
*'''required''' - a required field. Fields marked as required will also be displayed in the signup form;
*'''locked''' - can the user edit this field?;
*'''unique''' - the data entered must be unique;
*'''signup''' - the field should appear on the signup page;
*'''visible''' - can the user see this field? Options are:
**'''Not visible''' - only a site administrator can see and edit this field
**'''Visible to user''' - information is private to the user
**'''Visible to everyone''' - information is available to anyone who can view user profiles

=== Adding/Editing fields ===

[[Image:siteadmin_customprofiles.jpg|Link to the custom profiles interface from the site administration block]]

==== Steps ====
* 1. Make a category
** For example: "Class Information"
** Then in the lower left-hand part of the page, you'll see "Create a new profile field:."
* 2. Choose: "Menu of choices"
** Example: Enter "p-teacher" then "Teacher" then a list of teachers who teach a given course.
** Example: Enter "p-major" then "Major" then a list of the majors offered at your school
* 3. Make another category, for example: "Personal Info"
* 4. Choose: "Text"
** Example: Enter "p-hobby" then "Hobbies"
** Example: Enter "p-birthday" then "Birthday"
* 5. Now go to your own profile and click the "edit profile" tab to see how it looks.

== User's Interface ==

=== User profile page ===

=== The signup page ===
The signup form will be changed to include all required custom profile fields.

=== The "public" user profile page ===

==See also==

* [[:en:User profile fields|User profile fields]] for administrators
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=55814 Should I hack the mdl_user table, or add my own?] forum discussion

Course search

2025-02-10T08:05:53Z

Sarjona:

{{Template:WillNotMigrate}}

{{Work_in_progress}}
{{Infobox Project
|name = Course search
|state = Community bonding period
|tracker = CONTRIB-4335
|discussion = [https://moodle.org/mod/forum/discuss.php?d=230469 Writing Moodle's Course Search plugin]
[https://moodle.org/mod/forum/discuss.php?d=232803 Course Search plugin Progress]
|assignee = [https://moodle.org/user/profile.php?id=1565325 Shashikant Vaishnav]
}}

GSOC
 '13


== Introduction ==

Object of this google summer of code project is to Implement Advanced Course Search that is flexible, case-insensitive, fast and can sort results by relevance. Most importantly it should work consistently on different Database engines and different content languages. The deliverable includes a functional advance search plugin for Moodle that can be installed and configured to substitute basic core search. The project will be implemented integrating 3rd party search engine API with Moodle course schema.

== Problem Description ==

'''Non latin support with search queries:''' Database engines don't recognize word boundaries in non-english languages and can't do case-insensitive search.

'''Indexing:''' We don't want to reinvent the wheel as there are many awesome open source enterprise level search indexers available that can make our course search fast and efficient.

'''Sorting by relevance:''' We need to sort results according to relevance for example if a query result matches course name then it's more relevant then its other matches with summary of course. Implementing spelling correction (Did you mean?) feature. Also fuzzy search (alternate form of words) needs to be implemented.

'''Work consistently on different database engines and different content language:''' Course search should be implemented in a way that it can deal with as many databases possible. and it should be able to deal with different content language.

== Features ==

* works consistently on different DB engines and different content languages( Non latin languages support)

* Search results with relevance( Score )

* Case insensitive search capability

* Searchable Document Formats

* Hyper Text Markup Language
* XML and derived formats
* Microsoft Office document formats
* Open Document Format
* Portable Document Format
* Rich Text Format
* Compression and packaging formats [See Rebuilding Solr Cell]
* Text formats

* Autocomplete ( autosuggest with non-latin languages too )

* Very fast than existing course search implementation.

* Spell Checking capability ( Did you mean ?)

* Keyword Matching (Searching within specific field)

Example :- "summary:Getting started with python" searches for the "Getting started with python" in summary field of courses.

* Proximity Search

Example :- "moodle perth"~4 Search for "moodle perth" within 4 words from each other.

* Wildcard Search

* Fuzzy search support ( Alternate form of words )

* Filtering results by startdate (Range queries)

* Pagination & sorting results by relevance, startdate, shortname.

== Implementation ==

Earlier we had two choices for this purpose - Apache Solr and Sphinx. Both Apache solr and Sphinx has extensive documentation and community support and have very powerful indexing capabilities, but eventually faceted search and fuzzy search features that works out of the box with some other key points explained below for Apache Solr made it the winning solution.

=== Why Apache Solr ===

* As in Courses we are going to deal with Different types of summary documents & Solr can index proprietary formats like Microsoft Word, Pdf, etc. Sphinx can't.

* Solr supports field collapsing to avoid duplicating similar results. Sphinx doesn't seem to provide any feature like this.

* As we were concerned about the non-latin character support, Solr supports unicode character search out of the box.

* Solr, being an Apache project, is obviously Apache2-licensed. So the real challenge is now to integrate Apache Solr with moodle course search functionality. Advance course search will be installed as a plugin to substitute basic core search.

=== Project Roadmap ===

* '''Preparing course search schema to integrate with Apache solr :''' Solr reads the schema to be indexed using a xml based configuration file, lets call it schema.xml. When user will install advance search plugin, it will contain its schema file that will be automatically replaced by the corresponding files located on the Solr server, and it can usually be found in the main Solr directory solr/conf. We will need to design moodle course search schema.xml depending on what fields we want to index and how. Available field types and filter options in Solr makes it very flexible how we want to do that. Fortunately similar problem has already been sorted out by Drupal folks and I am quite familiar with that so here we can use this knowledge reference. Searchable fields in course are idnumber, shortname, fullname, summary. We will start with these fields for designing the schema for moodle course search.

* '''Extending apache Solr integration library with php to work with moodle :''' It is the Solr Php Client library that will talk between moodle and Solr. Here we need to extend these files to make it work with moodle course search plugin.

* '''Indexing the course search data:''' The entry point of indexing courses is the Cron task. Whenever the cron will run, an associated callback will trigger the indexing procedure. The plugin will look for courses which are marked for indexing, then for each course an object that contains all the relevant field contents to be indexed, will be individually converted into XML query and sent to the Solr server for indexing. We can also create a custom event to notify other entities that we just performed an indexing operation. How much courses can be indexed at once can be an admin setting. On admin side we will also have means to mark a course as a candidate for reindexing, so -

* We need to perform re-indexing(by Cron listening)
- If a new coursed is created.

- If a existing course is deleted or updated.

- Or it is marked by admin to index again

* '''Plugin search API functions :''' Internal search API functions will have these objectives -

1. Getting the basic search query via form submission

2. Translation of this search query into appropriate Apache Solr query and adding appropriate parameters for extra search options

3. Trigger the search by sending this query to locally running Apache Solr instance

4. Getting the search response and rendering the search results via proper theme function.

As we know Advance search is plugin type code base so when installed it will overtake the responsibility of search system. So when the user activates advance search plugin, then moodle will interact with its internal search and to interact with apache solr in backend. These search functions will be responsible to 'generate' the required apache solr query and to speak with solr running instance.

'''On caching -''' While retrieving the list of courses that match search string Apache Solr has the mechanism to cache repetitious search queries. It has two built-in in-memory caches. one for search results and one for documents. They are typically limited to several thousands entries each.

Finally we will prepare the list of courses to show to the user, with filtering out hidden courses that user can not see, retrieve all additional information such as category name, course contacts, etc.

* '''Achieving relevancy by using Solr's awesome faceted search feature:''' We can achieve relevancy by dynamic filtering results like searching start date(by days,months,years etc.) or spelling correct feature (Did you mean?) and in back-end Solr supports that out of box.

Relevancy is made using the ''boost'' clause on the field you want to give higher relevance. These "boost" clause will be added on search fields by internal search API functions as per the need while generating the search query for Apache Solr. From the Solr docs I found these key points to achieve for relevant results.[2]

By default Apache solr sorts given search results in order of relevancy, and relevancy is defined in terms of how much 'boost' we have given to particular field and if some field has to remain more relevant by default than other Apache Solr by altering the schema file.

* '''Solr with alternate form of words(fuzzy search):-''' In Apache Solr Text fields are typically indexed by breaking the text into words and applying various transformations such as lower casing removing plurals, or stemming to increase relevancy. The same text transformations are normally applied to any queries in order to match what is indexed.So when you are searching for "Fly" it also looks for "Flies" or "Flew"

* '''Solr with intra-word delimiters:-''' The filter 'WordDelimiterFilter' can be used in the analyzer for the field being queried to match words with intra-word delimiters such as dashes or case changes. By default apache solr provides lots of filters for text field type to configure these things. Properly configured schema.xml is the key point to handle this.

== Installation ==

=== Prerequisite ===

Java 5 or higher (a.k.a. 1.5.x), PHP 5.1.4 or higher, moodle 2.5 or higher.

=== Installing admin tool ===

1. Download the admin tool from here. (https://moodle.org/plugins/view.php?plugin=tool_coursesearch)

2. Extract the Course Search folder. Put it under moodle installation/admin/tool directory.

3. It should be named coursesearch. If you are already logged in just refreshing the browser should trigger your moodle
site to begin the install 'Plugins Check'.

4. If not then navigate to Administration > Notifications.

=== Installing search_cleantheme OR replacing/copying the renderer.php file ===

Here is two options either you may replace/copy your existing theme renderer with the one found in
search_cleantheme(https://github.com/shashirepo/moodle-theme_cleantheme).
OR you may install cleantheme itself.

replacing /copying the renderer file to your theme.

1. Copy renderer.php file from search_cleantheme replace it with your theme's renderer file.

2. Standard moodle theme doesn't have any renderer file so you may simply copy this to your
theme directory.

3. Rename renderer class name according to your theme name.

for example if you are using theme 'clean'.
then rename the class names to 'theme_clean_core_renderer' & 'theme_clean_core_course_renderer'.

OR you may either use search_cleantheme. This is based on bootstrap clean theme.

1. Download the cleantheme from here (https://github.com/shashirepo/moodle-theme_cleantheme)

2. Extract the theme folder. and put it under moodle installation theme directory.

3. If you are already logged in just refreshing the browser should trigger your Moodle
site to begin the install 'Plugins Check'.

4. If not then navigate to Administration > Notifications.

=== Installing Solr & placing the plugin Schema ===

Download the latest Solr 4.4.0 release from:
http://lucene.apache.org/solr/

Unpack the tarball somewhere not visible to the web (not in your apache docroot
and not inside of your moodle directory).

The Solr download comes with an example application that you can use for
testing, development, and even for smaller production sites. This
application is found at apache-solr-4.4.0/example.

Move apache-solr-4.4.0/example/solr/collection1/conf/schema.xml and rename it to
something like schema.bak. Then move the schema.xml that comes
with moodle course search admin tool plugin to take its place.

Similarly, move apache-solr-4.4.0/example/solr/collection1/conf/solrconfig.xml and rename
it like solrconfig.bak. Then move the solrconfig.xml that comes with the
moodle course search admin tool plugin to take its place.

Finally, move apache-solr-4.4.0/example/solr/collection1/conf/protwords.txt and rename
it like protwords.bak. Then move the protwords.txt that comes with the
moodle course search admin tool plugin to take its place.

Make sure that the conf directory includes the following files - the Solr core
may not load if you don't have at least an empty file present:
solrconfig.xml
schema.xml
elevate.xml
mapping-ISOLatin1Accent.txt
protwords.txt
stopwords.txt
synonyms.txt

Now start the solr application by opening a shell, changing directory to
apache-solr-4.4.0/example, and executing the command java -jar start.jar

Test that your solr server is now available by visiting
http://localhost:8983/solr/admin/

=== Testing with ping to solr ===

1. Advance Course can be found under :-

Administration->course->Course search settings(URL:- http://127.0.0.1/MoodleInstalltionURL/admin/tool/coursesearch)

2. Give the solr configuration options here:-

Solr Host:- localhost or 127.0.0.1
Solr Port:- 8983 (Default port for Solr )
Solr path :- /solr (Configuration directory for solr)

3. Click on "Check Solr instance Setting". if it Shows ping successful(with an success image). Now click save changes.

4. Now click on "Index courses" to index all the courses. After successful indexing. It will come up with a success image.

5. Click on "Optimize" to optimize the existing indexes And improve solr performance.

Enjoy the Search by going on page (http://127.0.0.1/MoodleInstallationURL/course/search.php)

To configure navigation with the course search page goto Site administration -> Front page -> Front page settings.

== Design ==

'''Course search plugin snapshots:-'''

'''* Course search admin tool'''

[[File:Course_search_Adminui.png|700px|thumb|left]]

'''* Course search results'''

[[File:Course_Search_IntraWordQuery.png|700px|thumb|left]]

'''*Advance course search auto-suggestions'''

[[File:autocomplete.png|700px|thumb|left]]

== Schedule ==

'''May 28 - June 17 ( Community Bonding Period)'''

➢ Discuss the further ideas with the mentor .

➢ Final list of tasks to be implemented under this project.

➢ Read & study the documentations on moodle and its Database Schema.

➢ Study the plugin development in moodle.

➢ Study the Apache Solr Documentation & its complete working

➢ Set up the development and testing environment.

'''June 18- july 10( Interim Period )'''

➢ Start Coding!

➢ Prepare moodle course search schema xml configuration

➢ Create moodle plugins (admin tool and theme) that allow to substitute core search with alternative solution. At first it will duplicate the existing functionality but it is ready for modifications without changing the core.

➢ Create function for manual reindexing of all courses, add button for admin on the plugin page to perform manual reindexing.

➢ Implement the search in the plugin just to make sure it works with the simple result output (no filtering, no pagination, no additional information retrieval, etc)

➢ Document the work.

'''July 11- August 02( Interim Period )'''

➢ Display courses properly, filtered, with all additional information

➢ Add caching of search results so everything is not retrieved again when user requests the second page

➢ Prepare search plugin for distrubution: create install/upgrade/uninstall scripts, write Readme file how to install and configure Solr.

Mid Term Evaluation

Submit code of completed tasks along with documentation.

'''August 3- August 25 (Interim period)'''

➢ Listen to events and mark courses for reindexing

➢ Implement cron function that does reindexing

➢ Add configurable settings to the plugin (when/whether to run automatic re indexing)

➢ Document the work.

➢ Debug the code and reduce code complexity.

'''August 26- Sep 16 (Interim period)'''

➢ Filtering results by dates, tags.

➢ Spell correction capability.

➢ Fuzzy search support.

➢ Implement extra functionality (if any other feature required and time permits).

'''Sep 17- Sep 23(Pencils down)'''

➢ Testing, documentation & debugging.

➢ Final Release

== Requirements ==

Require moodle 2.5 and Apache solr 4.x

== Credits ==

* '''Mentors:''' [https://moodle.org/user/profile.php?id=1334243&course=5 Marina Glancy] & [https://moodle.org/user/profile.php?id=381842 Michael de Raadt]

== Tracker ==

* CONTRIB-4335 Course Search Plugin

== See also ==

* [[GSOC/2013|Moodle GSoC projects for 2013]]
* [[GSOC|Moodle GSoC Overview page]]
* [http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/shashitechno/1 GSOC Proposal]
* [https://docs.moodle.org/dev/Projects_for_new_developers#Course_search Original idea]

[[Category:GSOC]]
[[Category:Project]]

Course reports

2025-02-10T08:05:25Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

A course report plugin is just another folder inside course/report/. It follows standard plugin practice and may have lang, db etc. sub-folders if these are required. A version.php file must be included.

In order to add a menu entry for your plugin, you must define a function named ''FOOBAR_report_extend_navigation'' in your ''lib.php'' file, where FOOBAR is your plugin name.
For example, for a module named ''synopsis'' (coursereport_synopsis in standardized form), the code will be :

function synopsis_report_extend_navigation($reportnav, $course, $context) {
$url = new moodle_url('/course/report/synopsis/index.php', array('id' => $course->id));
$reportnav->add(get_string('Synopsis', 'coursereport_synopsis'), $url);
}

[[Category:Plugins]]

Course formats 2

2025-02-10T08:05:09Z

Sarjona:

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Course formats refactoring
|state = FINAL DISCUSSION OF SPECIFICATION
|tracker = MDL-35218
|assignee = [[User:Marina Glancy|Marina Glancy]]
|discussion = http://moodle.org/mod/forum/discuss.php?d=212405
}}

{{Moodle 2.4}}

We will refactor the course formats to support a proper object-oriented design and flexibility
==Database changes==
* change course.format from varchar(10) to varchar(21)
* add table course_format_options that will store format-specific options for the whole course and for specific secions (fields: id, courseid, format, sectionid[optional], name, value)
* remove existing fields in table course: numsections, hiddensections, coursedisplay

==Object model==

Course formats must be classes inheriting base '''class format_base''' instead of the current collection of callbacks. (Although some callbacks will be converted to methods)

Method '''course_get_format($course)''' will return an instance of this class for the particular course. May be called with specific format but with empty course id (i.e. when course is being created)

===Class format_base===

{| class="wikitable"
|-
! method
! description
|-
| get_default_blocks()
| replaces config.php with $format[‘defaultblocks’]
|-
| course_format_options()
| definitions of the additional options that this course format uses for course
|-
| section_format_options()
| definitions of the additional options that this course format uses for section
|-
| edit_form_validation()
| performs additional validation for edit course form
|-
| page_set_course()
| is called from moodle_page::set_course() allowing course formats to run custom code at that point
|-
| page_set_cm()
| is called from moodle_page::set_cm()
|-
| output_course_header()
| displays the course-specific header. It will be included in all core themes, custom themes need to add support for it. Inside it should call function from renderer
|-
| output_course_footer()
| displays the course-specific footer
|-
| output_course_content_header()
| displays the course-specific header to be displayed in main content section (i.e. prev-next module navigation)
|-
| output_course_content_footer()
| displays the course-specific footer to be displayed in main content section (i.e. prev-next module navigation)
|-
| editsection_form()
| returns an instance of editsection_form (the format can overwrite this form)
|-
| is_section_current()
| replaces format_section_renderer_base::is_section_current()
|-
| get_section_name()
| is called from global function get_section_name()
|-
| uses_sections()
| is called from global function course_format_uses_sections()
|-
| supports_ajax()
| is called from global function course_format_ajax_support()
|-
| extend_course_navigation()
| replaces callback_FORMAT_load_content()
|-
| get_view_url()
| is called from course_get_url() and replaces callback_FORMAT_get_section_url()
|}

==Backward compartibility==

Define class format_legacy extends format_base that will call the existing callbacks and get blocks from config.php if format class is not defined (2.0-2.3 backward compartibility). Function course_get_format() will return instance of this class if the course format does not define its own class

==Course sections hierarchy==

Add support for nested course sections:
* avoid loops,
* store visibleold;
* Process moving, deleting sections;
* Make sure the hierarchy appears in navigation menu and breadcrumb;
* Make sure changing of availability rules for both parent and child sections works correctly together

Core formats will NOT support hierarchy, we just want to make sure that non-plugin code can deal with it

==Course add/edit form==

* When course is created/edited, the options specific for the format are displayed in separate form section and it dynamically changes when format is changed (with support of non-js mode). Each course format defines which display options it needs. For the standard weeks/topics formatd they are [numsections, hiddensections, coursedisplay], for scrom and social there are no options
* Make Course format selector on create/edit course page looking similar to "Add activity" with help text for each format

==Course sections management==

* ? Add events_triggers in functions that create/delete/hide/move course sections
* Refactor class editsection_form so it is easier to overwrite and implements functions set_data() and get_data() instead of pre/post processing data in editsection.php

==Add course formats as plugin to site administration==

Course formats are plugins in the code, but they are not handled as plugins in the administration. Replace course default settings by this page. Move page to plugins.

* option to enable/disable a course format
* each course format may have it's own configurable options such as default and/or sticky blocks, default settings, etc.

==Other changes related to course formats==

* Make sure backup/restore correctly works with sections hierarchy and new options. Also backup made in previous versions restores correctly in 2.4
* Make sure course format can influence navigation menu and breadcrumb. This probably will be done already by set_course/set_cm callbacks
* Course formats may want to extend course settings navigation. Implement additional callback or do it in set_course() ?
* Improvement: file_info (Server files repository) should list modules inside the course groupped by sections
* Describe in course formats dev documentation how formats can watch the events triggers

==Changes to course-related functions in 2.4==
(see MDL-35339)
* add function get_module_types_names() to replace $modnames and $modnamesplural in get_all_mods()
* add course_modinfo::get_used_module_types() to replace $modnamesused in get_all_mods()
* deprecate function get_all_mods(), change it's usage
* deprecate function get_all_sections()
* deprecate add_mod_to_section() and replace it with course_add_cm_to_section() to fix the mess in arguments

==Comments to the changes of the specification==

During actual development the specification was changed a little.
* table course_sections will not have additional fields 'parent' and 'visibilityold'. If course format wants to support hierarchy, they should be defined as additional format options. There will be no performance change if we add those fields to the course_sections table because the information about all sections is cached anyway in course.sectioncache and should be accessed only using get_fast_modinfo()
* there is no need in trigger 'course_format_changed' because there is already a trigger 'course_updated' and before it the format_base::update_course_format_options() is called with the before-update value of $course object
* field course.format has the length 21 because if format wants to define it's own tables the table name should start with 'format_FORMATNAME' and at the same time it's name should not be longer than 28 symbols. Therefore there is 21 char left for FORMATNAME
* function format_base::is_setup_completed() is not necessary because this functionality can be done in page_set_course() hook.

==Wishlist==

* Add field course_module.sortorder and deprecate course_section.sequence (not in 2.4!)

==Class course (for discussion, NOT for 2.4)==
There are number of course-related functions in the core with random names. The argument name/property 'section' is used for both {section}.id and {section}.section, sometimes even the same variable changes it's meaning. Some very important functions completely miss phpdocs.

Besides it will be more understandable for developers of modules and other plugins to relate to course object and not to course format (for example to get section name, etc.)

The proposal is:
* move code of all those functions into new class 'course'
* leave the functions themselves in course/deprecatedlib.php with developer warning and call to corresponding function from course class
* update usage of those functions in the core
* add function get_course() or course_get_course() to retrieve the cached instance of the course, make sure cache is emptied inside rebuid_course_cache()
* try to replace multiple similar queries $DB->get_record('course', array('id'=>$courseid)) in the core code

Source of course/lib.php: https://github.com/moodle/moodle/blob/master/course/lib.php

{| class="wikitable"
|-
! Existing function
! New function
|-
| get_fast_modinfo()
| ? course::get_modinfo()
|-
| get_array_of_activities()
| course::get_array_of_activities() [used only by get_fast_modinfo()]
|-
| course_set_marker()
| course::set_marker()
|-
| set_section_visible
| course::set_section_visible()
|-
| add_course_module()
| course::add_cm_raw() This function only creates an entry in table {course_module}
|-
| course_add_cm_to_section()
| course::cm_add_to_section()
|-
| -
| course::add_cm() calls previous two functions and rebuild_course_cache()
|-
| get_course_section()
| course::get_or_create_section() will return section_info
|-
| -
| course::get_section() will return section_info, alias to get_fast_modinfo()->get_section_info()
|-
| -
| course::get_sections() alias to get_fast_modinfo()->get_section_info_all()
|-
| set_coursemodule_groupmode()
| course::set_cm_groupmode()
|-
| set_coursemodule_idnumber()
| course::set_cm_idnumber()
|-
| set_coursemodule_visible()
| course::set_cm_visible()
|-
| delete_course_module()
| course::delete_cm_raw()
|-
| delete_mod_from_section()
| course::delete_cm_from_section()
|-
| -
| course::delete_cm() will call both previous functions
|-
| move_section_to()
| course::move_section(), also call rebuild_course_cache()
|-
| reorder_sections()
| course::reorder_sections(), also call rebuild_course_cache()
|-
| moveto_module()
| course::move_cm()
|-
| course_format_name()
| course::get_formatted_name()
|-
| get_section_name()
| format_base::get_section_name() with aliases: course::get_section_name() and section_info::get_name()
|-
| can_delete_course()
| course::can_delete()
|-
| create_course()
| course::create() [static]
|-
| update_course()
| course::update()
|-
| course_ajax_enabled()
| course::is_ajax_enabled()
|-
| include_course_ajax()
| course::include_ajax()
|-
| course_get_url()
| course::get_view_url()
|}

Other course-related functions in course/lib.php

* get_print_section_cm_text()
* print_section()
* print_section_add_menus()
* get_module_metadata()
* print_course
* make_editing_buttons()
* course_allowed_module()

Course Tags

2025-02-10T08:03:56Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Course tags
|state = Specification draft
|tracker = MDL-36648
|assignee = [[User:Andrew Nicols|Andrew Nicols]]
|discussion =
}}

{{Moodle 2.5}}

The existing course tagging system in Moodle is quite restrictive and is preventing use of course tags in more complex use cases. It would
be ideal if course tags could be used to inform other areas of Moodle as to which courses may be of particular interest to a user. As an
example, course tagging could be used to influence which courses are displayed in:
* block_course_overview - perhaps by use of course tag filters; and
* navigation - perhaps by using the same filters as in the block_course_overview or maybe looking at a users current context and showing them courses with similar tags to the course they are currently viewing.

Course tags should not be tied directly to a context and they should be an admin-configurable system-wide setting.

Course tags could also be linked closely with cohorts to allow restriction of /listing/ of courses based on cohorts. This is a widely requested feature in Moodle and would have a relatively small performance overhead.

==User Stories==

We have three users, Geoff, Jane, and Bob. They are all taking courses as Noodle University which has a number of Departments.

* Noodle University has been using Moodle as its VLE for several years and allows students to have access to the courses they have taken in previous years.
* All students in Noodle University are automatically enrolled onto courses using the Database Enrolment mechanism which also manages their cohort membership based upon various factors including their faculty, department, and major choices.
* Noodle has several departments including Modern Languages, Maths, and Physics:
** The Modern Language department offers courses in French, Italian, German, and Spanish; as well as a beginners TEFL course;
** The Math department offers a variety of courses most of which are available to any math student, but with some only available to those studying a particular field.
** The Physics department offers a variety of courses and requires its students to choose at least one math course in their first year.

The following tags have been set up at Noodle University (these are just a subset of them):
{| class="wikitable"
|-
! Tag
! Description
! Requirements
|-
| currentyear
| Courses run in the academic year starting 2012
| None
|-
| year2011
| Courses run in the academic year starting 2011
| None
|-
| year2013
| Courses run in the academic year starting 2013
| None
|-
| languagemajor
| Courses in the language department which are taken by Language majors
| Membership of the 'languagemajor' cohort
|-
| languageminor
| Courses in the language department which are taken by Language minors
| Membership of the 'languageminor' cohort
|-
| language-french
| French courses in the Language department
| Membership of the 'language-french' cohort
|-
| language-german
| German courses in the Language department
| Membership of the 'language-german' cohort
|-
| language-spanish
| Spanish courses in the Language department
| Membership of the 'language-spanish' cohort
|-
| language-italian
| Italian courses in the Language department
| Membership of the 'language-italian' cohort
|-
| mathmajor
| Courses in the math department which are taken by math majors
| Membership of the 'mathmajor' cohort
|-
| mathminor
| Courses in the math department which are taken by math minor
| Membership of the 'mathminor' cohort
|-
| math-stats
| Statistics courses offered by the Math department
| Membership of the 'math-stats' cohort
|-
| math-trig
| Trigonometry courses offered by the Math department
| Membership of the 'math-trig' cohort
|}

Looking at some of Noodle's departments, staff have tagged all of the courses such that the courses have the following tags:

{| class="wikitable"
|-
! Year
! Course
! tags
|-
| 2011-2012
| FREN200
| language-french, year2011
|-
| 2011-2012
| FREN201
| language-french, year2011
|-
| 2011-2012
| FREN202
| language-french, year2011
|-
| 2011-2012
| GERM200
| language-german, year2011
|-
| 2011-2012
| GERM201
| language-german, year2011
|-
| 2011-2012
| GERM202
| language-german, year2011
|-
| 2011-2012
| ITAL200
| language-italian, year2011
|-
| 2011-2012
| ITAL201
| language-italian, year2011
|-
| 2011-2012
| ITAL202
| language-italian, year2011
|-
| 2011-2012
| SPAN201
| language-spanish, year2011
|-
| 2011-2012
| SPAN202
| language-spanish, year2011
|-
| 2011-2012
| SPAN203
| language-spanish, year2011
|-
| 2011-2012
| MATH100
| math-major, math-minor, year2011
|-
| 2011-2012
| MATH110
| math-major, math-minor, year2011
|-
| 2011-2012
| MATH120
| math-major, math-minor, year2011
|-
| 2011-2012
| MATH130
| math-major, year2011
|-
| 2011-2012
| MATH140
| math-major, year2011
|-
| 2011-2012
| MATH210
| math-stats, year2011
|-
| 2011-2012
| MATH220
| math-trig, year2011
|-
| 2012-2013
| FREN300
| language-french, currentyear
|-
| 2012-2013
| FREN301
| language-french, currentyear
|-
| 2012-2013
| FREN302
| language-french, currentyear
|-
| 2012-2013
| GERM300
| language-german, currentyear
|-
| 2012-2013
| GERM301
| language-german, currentyear
|-
| 2012-2013
| GERM302
| language-german, currentyear
|-
| 2012-2013
| ITAL300
| language-italian, currentyear
|-
| 2012-2013
| ITAL301
| language-italian, currentyear
|-
| 2012-2013
| ITAL302
| language-italian, currentyear
|-
| 2012-2013
| SPAN301
| language-spanish, currentyear
|-
| 2012-2013
| SPAN302
| language-spanish, currentyear
|-
| 2012-2013
| SPAN303
| language-spanish, currentyear
|-
| 2012-2013
| TEFL350
| language-major, currentyear
|-
| 2012-2013
| MATH100
| math-major, math-minor, currentyear
|-
| 2012-2013
| MATH110
| math-major, math-minor, currentyear
|-
| 2012-2013
| MATH120
| math-major, math-minor, currentyear
|-
| 2012-2013
| MATH130
| math-major, currentyear
|-
| 2012-2013
| MATH140
| math-major, currentyear
|-
| 2012-2013
| MATH210
| math-stats, currentyear
|-
| 2012-2013
| MATH220
| math-trig, currentyear
|-
| 2013-2014
| FREN300
| language-french, year2013
|-
| 2013-2014
| FREN301
| language-french, year2013
|-
| 2013-2014
| FREN302
| language-french, year2013
|-
| 2013-2014
| GERM300
| language-german, year2013
|-
| 2013-2014
| GERM301
| language-german, year2013
|-
| 2013-2014
| GERM302
| language-german, year2013
|-
| 2013-2014
| ITAL300
| language-italian, year2013
|-
| 2013-2014
| ITAL301
| language-italian, year2013
|-
| 2013-2014
| ITAL302
| language-italian, year2013
|-
| 2013-2014
| SPAN301
| language-spanish, year2013
|-
| 2013-2014
| SPAN302
| language-spanish, year2013
|-
| 2013-2014
| SPAN303
| language-spanish, year2013
|-
| 2013-2014
| TEFL350
| language-major, year2013
|-
| 2013-2014
| MATH100
| math-major, math-minor, year2013
|-
| 2013-2014
| MATH110
| math-major, math-minor, year2013
|-
| 2013-2014
| MATH120
| math-major, math-minor, year2013
|-
| 2013-2014
| MATH130
| math-major, year2013
|-
| 2013-2014
| MATH140
| math-major, year2013
|-
| 2013-2014
| MATH210
| math-stats, year2013
|-
| 2013-2014
| MATH220
| math-trig, year2013
|}

Noodle University have enabled the /my course page and by default show several blocks including:
* block_course_overview - the standard Course Overview block listing courses you are currently enrolled on
* block_course_available - a custom block developed by Noodle listing all courses within a defined set of course categories

===User Story 1 - Jane===
Jane is a second-year Language student majoring in French and Italian. She is currently preparing for her third year and wishes to find out
more about her courses for the year to come. She only wants to be presented with information on the courses which she can actually take part
in.

Jane has been placed into appropriate cohorts for her study including:
* language-major
* language-french
* language-german

* Jane opens her /my page and clicks the option on the block_course_available page to only show courses for the 2013-2014 academic year.
* She is only interested in courses which she is eligible to take and is presented with a list of French, and Italian courses. She is also offered the option to take the TEFL course as she is a language major.
* Jane is only able to view courses in which she is currently enrolled in, and those she is interested in:
** FREN300
** FREN301
** FREN302
** ITAL300
** ITAL301
** ITAL302
** TEFL350

===User Story 2 - Geoff===
Geoff is a first year physics student and needs to look at his options for his second term. He has to choose from a selection of Math modules in addition to the compulsory Physics modules he has already been enrolled on.

* Geoff opens his /my page and clicks the option on the block_course_available page to only show courses for the current academic year
* Geoff is presented with a list of modules that he is able to take:
** MATH100
** MATH110
** MATH120

===User Story 3 - Bob===

Bob is a third-year undergraduate Language student. He has taken 10-12 courses in each year of his degree and still has access to these courses for his studies.
He wants to be able to limit the courses shown on his Course Overview block to just the courses he is actively studying and hide the courses he is not.
He also wants the same courses to be shown on the 'My courses' section of his Navigation tree.

* Geoff opens Moodle and is directed to his /my page
* Geoff is presented with a list of modules that he is currently enrolled in and is taking this academic year:
** GERM301
** GERM302
** TEFL350
** SPAN301
** SPAN303
** /several more/
* Geoff wishes to view some of the courses he took last year, so he clicks from the drop-down list in the course overview block and selects pre-defined filter option for '2011-2012 Academic year'. The block updates to show:
** GERM204
** GERM205
** GERM206
** SPAN201
** /several more/

==Database changes==

New Tables:

coursetag
* id
* idnumber
* name
* description
* descriptionformat
* timecreated
* timemodified

coursetag_courses
* id
* coursetagid
* courseid

coursetag_cohorts
* id
* coursetagid
* cohortid

===Sample queries===

Select all courses with any of tags a, b, or c and any of tags d, e, or f and that user matches any cohort membership requirements
SELECT
c.*
FROM {course} c
INNER JOIN {coursetag_courses} ctc ON ctc.courseid = c.id
INNER JOIN {coursetags} ct ON ct.id = ctc.coursetagid
LEFT JOIN {coursetag_cohorts} ctch ON ctch.coursetagid = ct.id
LEFT JOIN {cohort_members} chm ON chm.id = ctch.cohortid
WHERE chm.userid = ? AND (
ct.id IN (a, b, c) AND
ct.id IN (d, e, f)
) AND
( ctch.id IS NULL OR ch.id IS NOT NULL )

==Object model==

===Class course_tag===
{| class="wikitable"
|-
! method
! type
! description
|-
| create()
| static
| creates a new course tag
|-
| remove()
| static
| removes a tag and all associations
|-
| fetch_by_name()
|
| Fetches a tag and it's details by its unique name
|-
| fetch_by_id()
|
| Fetches a tag and it's details by its unique id
|-
| add_to_course()
|
| Add a course to the current tag
|-
| remove_from_course()
|
| Remove the specified course from the current tag
|-
| fetch_courses()
|
| List all courses under the current tag
|}

==Backwards compatibility==
None - we should get rid of the old interface if possible

==User interface==

==Future thoughts to consider==

Core plugins review for Moodle 4.0

2025-02-10T08:03:37Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Core plugins review
|state = Completed
|tracker = MDL-72046 (epic)
|discussion = [https://moodle.org/mod/forum/discuss.php?d=426053 Moodle core plugins review]
|assignee = Sara Arjona
}}
{{Template:Moodle 4.0}}
==Introduction==
This project is about reviewing the plugins in core Moodle LMS with the aim of removing any which are no longer or hardly used, and if appropriate, adding them to the Moodle plugins directory.
==Plugins to be deleted from core==
The following plugins will be deleted from core but not put in the plugins directory because the technology is discontinued.
* WebCT question import/export format (qformat_webct)
* Examview question import/export format (qformat_examview)
* Flash animation media player (media_swf)
* VideoJS Flash plugin
* Picasa repository (repository_picasa)
* Picasa portfolio (portfolio_picasa)
* Microsoft OneDrive (legacy) (repository_skydrive)
==Plugins to be removed from core and added to the plugins directory==
Plugins which have been removed from core and added to the plugins directory will initially be listed with Moodle HQ as maintainer while we seek new maintainers via the [[Plugins adoption programme]].
* Word censorship filter (filter_censor)
* Health center admin tool (tool_health)
* Jabber notification (message_jabber)
* Quiz results block (block_quiz_results)
* Box repository (repository_boxnet)
* Box portfolio (portfolio_boxnet)
Note the plugins can be added to the Plugins directory only once the target version 4.0 is registered there, which happens on beta release.

==Plugins we are thinking about removing from core in the future and adding to the plugins directory==
We still need to decide which of the following plugins should be removed from core and added to the plugins directory. It will be done in MDL-73136 (epic). Please let us know your thoughts by posting in the discussion on moodle.org [https://moodle.org/mod/forum/discuss.php?d=426053 Moodle core plugins review]. We will collate all your feedback and review what to do with each plugin.
* Algebra notation filter (filter_algebra)
* Assignment 2.2 module (mod_assignment): MDL-72350
* Equella repository (repository_equella)
* Flickr block (block_tag_flickr): MDL-72614
* Flickr portfolio (portfolio_flickr): MDL-72614
* Flickr repository (repository_flickr): MDL-72614
* Flickr public repository (repository_flickr_public): MDL-72614
* HTML tidy filter (filter_tidy)
* Legacy course files repository (repository_coursefiles)
* Mahara ePortfolio (portfolio_mahara)
* Merlot.org repository (repository_merlot)
* Survey activity (mod_survey)
* URL downloader repository (repository_url)
== How will these plugins be removed from core? ==
* The plugin folder (for instance, question/format/webct/ for qformat_webct), will be completely removed from Moodle core. IMPORTANT: if you want to keep any of the plugins removed from core in your Moodle site, you will need to download and copy the plugin folder to the right place BEFORE running the upgrading process.
* Each plugin will be removed from the standard_plugins_list() method and added to the is_deleted_standard_plugin() method (both placed in lib/classes/plugin_manager.php).
[[File:jabber tobedeleted.png|center|thumb|The plugins will be marked as "To be deleted" if their code is not placed again in the Moodle folder.]]
* The upgrading steps will be added to lib/db/upgrade.php, to remove, when it applies, specific:
** DB tables (drop table statements).
** settings, using unset_all_config_for_plugin().
** capabilities, using capabilities_cleanup().
** ...

The plugins data will be removed only if the plugins files are not present anymore in the code. So, if a site wants to keep any of the plugins removed from core, they should download and copy the plugin folder to the right place (as they use to do with third-party plugins) BEFORE running the upgrading process.

Community hub - technical specification

2025-02-10T08:01:55Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Moodle 2.0}}
= Implementation =
The community hub project is implemented in core (site related code), and as two external plugins.
== Moodle core ==
In Moodle core we added:
* a new registration form
* a community block (search course, import and restore course)
* some course publication operations

== Hub server ==
A hub server is a plugin in /local/hub/. Note that in Moodle core, there is a little hack that detect the plugin, and display a specific hub front page.

The plugin can be found into Contrib CVS.

== Hub directory ==
A hub directory is a plugin in /local/hubdirectory.

The plugin is not released.

= Hub directory =
== Data structure==
on the hub directory we have a table named hub_directory containg all registered hubs :
{| class="wikitable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|name
|varchar
|Name of the hub
|-
|description
|text
|Description of the hub
|-
|url
|varchar
|The full URL to the hub front page
|-
|token
|varchar
|The token used to call the hub
|-
|trusted
|int
|Is the hub trusted?
|-
|language
|varchar
|What is the primary language of this hub? (blank for multilanguage)
|-
|timeregistered
|int
|Time that the hub was first registered
|-
|timemodified
|int
|Time that the hub was last modified
|-
|contactname
|varchar
|Name of the contact person
|-
|contactemail
|varchar
|Email of the contact person
|-
|imageurl
|varchar
|hub logo url
|-
|visible
|int
|is hub visible (i.e. enable field)
|-
|prioritise
|int
|is this hub prioritised
|-
|courses
|int
|Number of courses on this hub
|-
|sites
|int
|Number of sites on this site
|-
|privacy
|varchar
|"public"/"private"
|}

on the hub directory we have a table named hub_global_course_directory containg all public published courses into all public hub:

{| class="wikitable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|hubid
|int
|Hub ID from the table hub_directory
|-
|sitename
|varchar
|Site name - can be blank
|-
|siteurl
|varchar
|Site URL- can be blank
|-
|fullname
|varchar
|Fullname of the course
|-
|description
|text
|Description of the course
|-
|courseurl
|varchar
|The full URL to the course
|-
|contributornames
|varchar
|Contributor names
|-
|coverage
|varchar
|Coverage
|-
|language
|varchar
|What is the language of this hub?
|-
|timemodified
|int
|Time that the course was last published
|-
|creatorname
|varchar
|Name of the creator
|-
|publishername
|varchar
|Name of the publisher
|-
|format
|varchar
|url or Zip
|-
|shortname
|varchar
|course short name
|-
|licenseshortname
|varchar
|license shortname
|-
|subject
|varchar
|subject
|-
|audience
|varchar
|
|-
|educationallevel
|varchar
|
|-
|coursemapid
|varchar
|
|-
|creatornotes
|varchar
|
|-
|creatornotesformat
|varchar
|
|-
|privacy
|varchar
|
|-
|downloadurl
|varchar
|
|-
|originaldownloadurl
|varchar
|
|-
|demourl
|varchar
|
|-
|trusted
|int
|
|-
|enrollable
|int
|
|-
|screenshotsids
|varchar
|
|-
|enrolcost
|int
|
|-
|enrolcostcurrency
|varchar
|
|-
|downloadcost
|int
|
|-
|downloadcostcurrency
|varchar
|
|}

== communication with hub ==
Communications between hub and hub directory are two ways, they can call each other by web service. For any hub/hub directory communication, we record the remote entity (i.e. hub directory/hub) in a table named hub_communication or hub_directory_communication. This is mainly used to remember the token used by the remote entity and the name of the remote entity. It's also used as a flag to know if a registration attempt has been confirmed.
{| class="wikitable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|localtype
|varchar
|Is our Moodle site a: Site, Hub or Hub directory
|-
|token
|text
|the token used for this communication
|-
|localws
|varchar
|What kind of entity is our site in this communication. Are we server or client?
|-
|remotetype
|varchar
|Is the remote Moodle site a: Site, Hub or Hub directory
|-
|remotename
|varchar
|Full name of the remote site
|-
|remoteurl
|varchar
|URL of the remote entity
|-
|confirmed
|int
|Is this confirmation confirmed (in case the registration/update failed)
|}

=== registration process ===
# the hub admin goes on hub settings page => settings are saved with set_config
# the hub admin presses register and is redirected to the hub directory registration page. This redirection has the token used by the hub directory.
# the hub admin enters a recaptcha on the hub directory registration page. It is mandatory to avoid people to write script automatically registering.
# the hub directory redirect the hub admin to his own site on a confirmation page. The redirection has the token used by the hub.
=== update process ===
# the hub admin changes the settings.
# the hub admin presses update registration.
# the hub calls by web service the update info function on the hub directory.

== security design ==
* because there is a recaptcha, only human being can register.
* all other communications are protected by Moodle ws security design
* In order to use web service we automatically create Users/Services/Roles/Functions. All created users, web services functions, web services and web service tokens are visible in the admin user interface. Hub admin should not to delete them, neither create some with the same names. Hub admin can only modify the roles in order to restrict the capabilities to use some of the functions. To know about automatically created Users/Services/Roles, see their respective sections in this same page.

= Hub server =
== Data structure==
Primarily this hub_site_directory table will store information about the sites that have registered course information on that Hub. On hub.moodle.org this information will also be used for [http://moodle.org/stats general statistics] and the listing of [http://moodle.org/sites registered sites]:
{| class="wikitable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|name
|varchar
|Name of the site
|-
|description
|text
|Description of the site
|-
|url
|varchar
|The full URL to the site front page
|-
|secret
|varchar
|The site secret used to confirm the registration and to not register a site twice.
|-
|trusted
|int
|Is the site trusted?
|-
|language
|varchar
|What is the primary language of this site? (blank for multilanguage)
|-
|timeregistered
|int
|Time that the site was first registered
|-
|timemodified
|int
|Time that the site was last modified
|-
|contactname
|varchar
|Name of the contact person
|-
|contactemail
|varchar
|Email of the contact person
|-
|contactphone
|varchar
|Phone of the contact person
|-
|contactable
|int
|can we contact the person
|-
|imageurl
|varchar
|site logo url
|-
|visible
|int
|is site visible (i.e. enable field)
|-
|prioritise
|int
|is this site prioritised
|-
|countrycode
|varchar
|country code ISO 3166 (AU, FR etc) [http://cvs.moodle.org/moodle/lang/en_utf8/countries.php?view=markup lang/XX_utf8/countries.php]
|-
|regioncode
|varchar
|region code ISO 3166-2 [http://www.commondatahub.com/live/geography/state_province_region/iso_3166_2_state_codes ISO 3166-2 (XX-XXX)] (alphanumeric codes)''' (TODO: MDL-24020)'''
|-
|street
|varchar
|street
|-
|geolocation
|varchar
|lattitude and longitute (like in googlemap/twitter)
|-
|moodleversion
|varchar
|Moodle version
|-
|moodlerelease
|varchar
|Moodle releasel
|-
|ip
|varchar
|last IP of this site
|-
|courses
|int
|Number of courses on this site
|-
|users
|int
|Number of users on this site
|-
|enrolments
|int
|Number of enrolments on this site
|-
|resources
|int
|Number of resources on this site
|-
|questions
|int
|Number of questions on this site
|-
|modulenumberaverage
|int
|Module number average on this site
|-
|participantnumberaverage
|int
|Participant number average on this site
|-
|emailalert
|int
|Do we send email notification - Subscribed to securityalerts@lists.moodle.org
|-
|privacy
|varchar
|"public"/"private"
|-
|posts
|int
|Number of posts on this site
|-
|timevalidationfailed
|int
|The time the last time the site was not reach
|-
|deleted
|int
|is the site deleted
|-
|publicationmax
|int
|how many publication are allowed on the hub every day
|}

On the hub server, the hub_course_directory table stores registered courses, one record per course. Some courses will be "downloadable", some will be enrollable, so different fields can be used. Note that from these data you can build the exact Dublin Core Metadata Element Set, Version 1.1:

{| class="wikitable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|siteid
|int
|Site ID from the table hub_site_directory
|-
|fullname
|varchar
|Fullname of the course
|-
|description
|text
|Description of the course
|-
|courseurl
|varchar
|The full URL to the course
|-
|contributornames
|varchar
|Contributor names
|-
|coverage
|varchar
|Coverage
|-
|language
|varchar
|What is the language of this hub?
|-
|timemodified
|int
|Time that the course was last published
|-
|creatorname
|varchar
|Name of the creator
|-
|publishername
|varchar
|Name of the publisher
|-
|format
|varchar
|url or Zip
|-
|shortname
|varchar
|course short name
|-
|licenseshortname
|varchar
|license shortname
|-
|subject
|varchar
|subject
|-
|audience
|varchar
|Audience: Educators | Students | Admin
|-
|educationallevel
|varchar
|Educational level being discussed (for educators audience only): Tertiary | Secondary | Primary | Government | Corporate | Association | Other
|-
|coursemapid
|varchar
|Is a course map supplied? (Simple XML description of course structure, could be rendered graphically later [http://kn.open.ac.uk/public/workspace.cfm?wpid=8690 CompendiumLD] )
|-
|creatornotes
|varchar
|Creator notes (describes how to use the course, where it came from, context, more description etc)
|-
|creatornotesformat
|varchar
|Creator notes format (HTML etc)
|-
|privacy
|varchar
|Availability (public/private)
|-
|downloadurl
|varchar
|Download URL (usually a local cached zip but could be anything else, including empty for non-downloadable)
|-
|originaldownloadurl
|varchar
|Original Download URL (usually a download script on the original Moodle site, used by Hub to get cache)
|-
|demourl
|varchar
|Demo URL (a URL, if any, where the course can be seen in action)
|-
|trusted
|int
|Is the course trusted? (all downloadable courses from non-trusted sites start as "no", then this gets changed by someone who checks it)
|-
|enrollable
|int
|Is the course enrollable anyone with an account?
|-
|screenshots
|varchar
|Number of supplied screenshots
|-
|enrolcost
|int
|Enrol Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]
|-
|enrolcostcurrency
|varchar
|
|-
|downloadcost
|int
|Download Cost (and currency) [http://en.wikipedia.org/wiki/ISO_4217 ISO 4217]
|-
|downloadcostcurrency
|varchar
|
|}

Dublin Core Metadata Element Set, Version 1.1
*# Contributor - course manager names or whoever the publisher nominates
*# Coverage - User tags
*# Creator - main teacher name or copyright holder or whoever the publisher nominates
*# Date - date this was last published/updated
*# Description - course description
*# Format - zip / url
*# Identifier - course shortname (unique on the original site)
*# Language - based on lang.php
*# Publisher - the name of the person who caused this record to be entered here
*# Relation - the site id that it came from
*# Rights - one of a standard set of open source, creative commons and other licenses
*# Source - original URL of the course
*# Subject - The best-matching item from ([[Standard Classification of Educational Fields]])
*# Title - Course fullname
*# Type - "course" (later there might other types such as activities or SCORM packages etc)

TODO:
*# Is guest access allowed?

==== Course feedback ====

* id
* course id
* type (bug / comment)
* text
* rating (probably a rating ID => futur rating API)

TODO: a simple way to alert the publisher of new feedback on a course.

==== Course content ====

* id
* course id
* module type (activity / block)
* module name (forum, resource etc)
* count

==== Course outcomes ====

* id
* course id
* outcome (text)

== communication between site and hub ==
The site registration process is similar to "Hub registration on hub directory", except that the site doesn't create any ws token for the hub. However the site creates a secret key in order to confirm the registration process, the hub sending it back at the end of the process. The communication between site and hub are one way only, site to hub.

= Registered site =
== tables==
On the registered sites we have a table named hub_course_published containg all published courses.

== communication ==
Sites send files calling a upload.php script on the hub.

= List of communications between the three entities =
Following the different communication operations expected between Moodle.org, hub servers and Moodle site.

== Moodle site and Hub server==
One way communications, site to hub.

== Moodle.org Hub directory and (Moodle.org) Hub server ==
[[Image:Hubdirectory_moodleorg2hubserver_moodle.org.png|900x950px]]

== Moodle site and Moodle.org Hub directory ==
[[Image:Moodlesite2moodleorg.png|900x950px]]

= How does the communication work =
We are going to use Moodle web services. We will create a new /hub/webservice.php entry point It will bypass $CFG->enablewebservice and it will consider a choosen protocol as activated.

== Registration operations ==
#The hub creates a specific ws user, a specific ws role, a specific ws service and a specific token.
#The hub sends by POST the web service token to the site/hub directory.

== Unknown caller operations ==
the webservice.php entry point should by pass token authentication for some public functions.
=== public function list ===
* global search
* search courses on a hub
* get hub list from the hub directory

= Required roles for community hub web services =

==Moodle.org Hub list ==

"Public Directory User" - Role for any sites :
*moodle/hubs:view (public token for any sites) for searching the global listing

"Directory User" - Role for hub to update the listing:
*moodle/hubs:updateinfo (private token for any registered hub) for updating hub information (it creates a new private token different from the one used to call this function)

==Hub server==

Will have one new user per registered site, plus one for Moodle.org hub directory and one for pubic users.

"Public Hub User" - Role for any site (public token)
*moodle/hub:view for course searches
*moodle/hub:rate for rating a course
*moodle/hub:comment for commenting a course
*moodle/hub:download for downloading a course template

"Registered Hub User" - Role for registered sites (private token -> each site gets a private user)
*moodle/hub:view for course searches
*moodle/hub:rate for rating a course
*moodle/hub:comment for commenting a course
*moodle/hub:download for downloading a course template
*moodle/hub:publish for publishing a course template
*moodle/hub:updateinfo (private token for any registered site) for updating site information (it creates a new private token different from the one used to call this function)

"Moodle.org Hub Directory" - Role for Moodle.org Hub Directory (private token)
*moodle/hub:viewinfo for getting hub information
*moodle/hub:view for getting course information
*moodle/hub:confirmhubregistration confirm the registration

= Required community hub web services =
We will have one hidden service per role. Following their name:

==Moodle.org Hub list ==
the following service will exist only on Moodle.org Hub directory

"Hub directory public site":
*global search function

"Hub directory hub server":
*update info function

==Hub server==
the following services will exist on any Moodle site (but disabled till a first token is linked to it)

"Public site":
* course searches function
* rating a course function
* commenting a course function
* downloading a course template function

"Registered site"
*course searches function
*rating a course function
*commenting a course function
*downloading a course template function
*publishing a course template function
*update info function

"Hub directory"
*getting hub information function
*getting course information function
*confirm the hub registration function

= Required users for community hub web services =

==Moodle.org Hub list ==
A user is be linked to one role only and one service only

"Public sites": they all use the same ''public_directory_user'' user.
*His role is 'Public Directory User'
*His service is 'Hub directory public site'

"Hub servers": they all have their own $huburl."_directory_hub_user" user.
*Their role is 'Directory user'
*Their service is 'Hub directory hub server'

==Hub server==

"Public sites": they all use the same 'public_hub_user' user.
*His role is 'Public Hub User'
*His service is 'Public site'

"Registered sites": they all have their own $siteurl.'_registered_site_user' user.
*Their role is 'Registered Hub User'.
*Their service is 'Registered site'.

"Hub directory": they use their own $hubdirectoryurl.'_directory_user' (in case the hub directory change his url)
*Their role is 'Moodle.org Hub Directory'.
*Their service is 'Hub directory'.

==See also==
* [https://docs.moodle.org/en/Community_hub Community hub]
* [https://docs.moodle.org/en/Development:Community_hub Development: community hub project specification]

[[Category:Hub]]

Community hub

2025-02-10T08:01:20Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Moodle 2.0}}

* '''PROJECT STATE: implemented'''
* '''MAIN TRACKER ISSUE''': MDL-19309
* '''DISCUSSION AND COMMENTS''': [http://moodle.org/mod/forum/view.php?id=7330 Hub servers] forum in Using Moodle
* '''MAIN AUTHORS''': [[User:Martin_Dougiamas|Martin Dougiamas]] and [[User:jerome_mouneyrac|Jerome Mouneyrac]]

This page describes an overall functional specification for the "Moodle Community Hub" project, which consists of a new system (the Moodle Hub Server) and several new features in Moodle 2.0.

= Goals and rationale =

The main goals of the Community hub project are:

# to allow people to easily find courses around the world that they want to enrol in:
#* educators want to find '''communities of practice''' that are subject or region-oriented, so that they can associate with their peers on a long-term basis.
#* other learners want to find and study courses on various other subjects
# to make it easy for educators to find and download '''course templates''' from other people. This will help educators share and identify examples of '''best practice''' in online pedagogy and hopefully improve the average quality of online courses.

Finally, we want to do all this in the simplest, safest way possible, while allowing a range of scenarios such as courses that are public or private, free or paid, so that the Moodle community can build solutions for themselves.

= Overview =

The diagram below shows the basic idea. The systems in this diagram are:

;Ordinary Moodle site: A typical Moodle site with teachers who want to download course templates and/or users who want to connect (enrol) with external communities
;Publishing site: A Moodle site that wants to make some of its courses available for download
;Community site: A Moodle site that provides courses that are enrollable
;Moodle Hub Server: A new Moodle plugin for listing registered courses that are '''downloadable''' or '''enrollable'''. The default hub will be installed at hub.moodle.org, but there can be many others.

[[Image:Community-hubs-flowchart.png]]

Downloadable courses
* (A) Sites that want to publish certain courses and make them downloadable can register them with one or more Hub Servers.
* (B) The Hub will check the data and make sure the course zip is downloadable, caching a copy locally. The Hub may also have a security process to check the download for trojan horses, bad content, etc.
* (C) The download process may trigger the backup process on the original server if it hasn't been done already.
* (D) Later, Moodle users (who have permissions to do so) can connect to a Hub to search for downloadable courses and choose one.
* (E) The Moodle site downloads the file and makes it available to the Moodle user so they can now continue to restore it normally.

Enrollable courses
* (1) Sites that want to publish certain courses for the public to enrol in can register them with one or more hub (including the main one at moodle.org)
* (2) Later, any Moodle user can connect to a hub (via Community block in their site) to search and find courses they want to join
* (3) They click on a link to be sent to the other site so that they can enrol there.

= Use Cases =

== New teacher creating a course ==

# New teacher needs some help with a new course for "Alligator farming 101"
# Teacher sees the "Community" block into the "Alligator farming 101" course page and presses "Search course"
# Teacher browses a list of downloadable courses in the community page (the data comes from one or more Hubs via web services)
# Teacher searches for "Alligator"
# Teacher finds 4 courses that look good, and after reading reviews and ratings, chooses one.
# The course is downloaded and unpacked in Moodle.
# The teacher now has a good starter course they can keep developing.

== New teacher needs help ==

A teacher decides they need some help and wants to talk with others teaching Alligator farming.

# Teacher goes to their "Community" block and clicks "Search course".
# Moodle displays a page to search for courses (the data comes from one or more Hubs via web services)
# Teacher searches courses for "educator" courses on "Alligators" in their country/language.
# Teacher finds two, selects one, and is returned to the page where is was before clicking on "Search course". The selected course is now permanently listed in the Community block.
# Teacher clicks on the link and is taken to the course, where they can enrol and interact/learn with peers over time, subscribe to forums etc.

== University consortium ==

A group of five universites wants to share courses among themselves and not to the outside world. They also want to prevent teachers from downloading courses from outside the consortium.

# Someone downloads Moodle and installs it as a private Moodle Hub Server
# Admins of all five Moodle sites in the group add the URL of the private Hub to their settings and register their sites there
# The default Hub at hub.moodle.org is (optionally) disabled in the site-wide settings.
# Admins register their courses with the Hub.
# Teachers can now import, export or join courses via the private Hub.

== Course creation business ==
NOT IMPLEMENTED

CoolCourses Inc have produced a set of 50 good Moodle courses which they wish to sell.

# They set up a Moodle site with all their courses in them.
# They set up a Hub with a payment system, and register it with the Hub List at moodle.org so people can find it
# They register all their courses with their own Hub with appropriate metadata
# When looking for courses, users can either
#* find this Hub by browsing through the Hub List, or
#* type the URL of the Hub directly into their Moodle site
# When users try to download a course, they may see a payment button to download it (credit card, paypal etc)
# CoolCourses could provide limited access to the courses on their Moodle site using Roles, as a preview.

= Components =

There are several components:

;'''Hub List''': A list of known Hub Servers, kept on moodle.org
;'''Hub Server''': A new Moodle plugin for publishing a list of registered courses that are '''downloadable''' or '''enrollable'''
;'''Course registration''': A new mechanism in every Moodle to register particular courses with one or more Hub Servers
;'''Community membership block''': to search Hub Servers to find enrollable courses to join and bookmark
;'''Import/Export block''': Makes it easy to find downloadable course templates in a Hub Server, then download them from the Hub Server and restore them locally

==Moodle Hub List==
The Hub List is a list of known Hub Servers (see the next section). This makes it easy for Moodle users to find the most appropriate Hub Servers for their needs. To get on the Hub List, Hub Servers choose to register with moodle.org via their administration interface.

Moodle.org will store the following information, and make it available via a browseable interface at [http://hubdirectory.moodle.org/ hhttp://hubdirectory.moodle.org/].

==Moodle Hub Server==
[[Image:Registerhub.png| thumb |Mockup: hub registration page]]
The Moodle Hub Server (aka Hub) is a separate system (based on Moodle technology) that allows Moodle sites to register their courses for listing there. More technically, the hub server is a Moodle plugin.

A default installation of this software will be running at '''hub.moodle.org''', but anyone else can download it and set up their own hub for private or public uses. A hub can also be used as a Moodle site, even though the Moodle front page will be replaced by the hub front page.

Hubs can optionally register themselves in the Hub List so that they are easier to find and so they can become a "Trusted Hub".

A hub server has some config fields (saved into its database):
* name (site name by default, changing the value here, do not change the site name)
* description (front page summary as default value)
* language (choose the language, set site language as default)
* contact name (current user by default)
* contact email
* enable
* password (only for private hub)
* logo url (need to have a limited size of 150x150)
* protected web search interface '''(TODO: MDL-24015)'''

=== Data structure ===
Most of the data structure can be found in the [https://docs.moodle.org/en/Development:Community_hub_-_technical_specification community hub technical specification].

=== User interface ===
[[Image:Webinterface.png|thumb|Mockup: search course UI]]
If visiting the hub via the web, it will provide an interface for full searching and browsing.

The web interface can be protected from access. The hub at moodle.org will of course be open to all.

[[Image:Search_hub_moodle.png|thumb|Mockup: search hub UI]]

The web interface allows users to:

* search by keyword (descriptions, titles, tags, subject etc)
* browse a list of courses by subject
* go directly to a course (if marked for public use)
* preview a course (if screenshots have been provided, or the original URL location)
* download the course to desktop (only if an download url has been set)
* If logged in to the Hub, users can also:
** give a rating to the course
** write a comment for the course - use comment 2.0 API

When displaying courses, you can see and sort by:

* Title - ''Sortable''
* Description
* Tags - ''Sortable (first tag retrieved by the request is considered)''
* Screenshot(s)
* Cost (if any) - ''Sortable''
* Rating (10-point scale displayed as 5 stars, and only if you are logged in to moodle.org) - ''Sortable''
* Comments
* Moodle site name
* Date added to directory
* Date last updated in directory
* Audience (teachers, students, admins)
* Teacher name(s) - ''Sortable''

=== Web service interface ===
'''TODO: MDL-24031'''
A REST-based web services interface will be provided for other systems (eg Moodle sites) to use directly.

Web services can search on:
* string search
* array language
* array cost
* array Moodle url
* Others?

=== Hub admin interface ===

The hub will have a Hub admin interface. Admin processes include:

* Listing, approving and editing the sites registered with the hub
* Listing, approving and editing the course descriptions, metadata etc.
* Registering/updating the Hub with the Hub List
* Configuring Hub behaviour and the appearance of the home page.

== Course global search functionality ==
In order to quickly search a course on all public hubs, Moodle.org will have a table equivalent to the course 'directory' table with dew additional field as "public hub id", "site url", "site name"...

== Site registration ==
[[Image:SiteRegistration.png|thumb|Mockup: site registration UI]]
The existing site registration form in Moodle will be extended so that admins can:

# choose one or more Hubs to register with (hub.moodle.org and/or others in the Hub List, or directly to a particular Hub specified by URL)
# choose to enable cron to re-send statistics to the hub on a periodic basis. (TODO/TBD)
# choose to enable the hub to harvest courses on a periodic basis (TODO: not shown on image/TBD)

== Community membership ==

The "Community" block allows people to find and subscribe to external courses that they want to be part of.

Visibility of the block and the features within it are controlled by roles, and contains:

# 'Bookmarks' of previously-selected (subscribed) external courses (to make revisiting easy) grouped by site, which can be edited/deleted etc
# A link to a search script - "Add new courses..."
# A search script to browse/search one or more Hubs (via web services to get the data, with the interface rendered by the local script). Users can select joinable courses from the list and they'll get added to the list in the block.

Generally the links will be just be an ordinary URL and the remote site will be responsible for authentication.

If the foreign site has an Mnet connection set up with the current site then login will be immediate.

[[Image:Addacourse.png|thumb|Mockup: community block]]

community block database structure:
{| class="wikitable"
|-
! Name
! Type
! Description
|-
|id
|int
|Standard autoincrement
|-
|userid
|int
|foreign key - ID of the user
|-
|-
|coursename
|varchar
|Name of the community course
|-
|coursedescription
|text
|Description of the community course - display by the tag link
|-
|courseurl
|varchar
|The full URL to the community course front page
|-
|image
|varchar
|community course logo url - it could be displayed as icon
|}

== Publish courses ==
'''Publish course''': to publish or update the description of the current course in one or more Hubs

The '''Publish''' button only exists if the current user has the appropriate capabilities and if the current Moodle site has been registered with a Hub.

[[Image:Coursepublishing.png|thumb|Mockup: course publishing]]

Choosing "Publish" goes to a script where you can chose from the registered Hubs and whether you want to publish the course as:
* enrollable/advertise, so that others can come here and use the course where it is, and/or
* downloadable/share, so that a Hub can offer this course for download to others

If the user wants to offer this course for download, then they are directed to the standard backup process to create and define the backup file (without users!). If the backup is successful the zip is stored in a standard place and then the user is returned to the publish script to continue. (If downloads are not required then this whole step is skipped).

It allows the user to set up full , and especially whether you want to advertise this course as being:

Now the script presents a form with metadata that this course will be published with on the chosen Hub(s) (this is also available in the course settings page). Metadata includes information such as description, licensing, categories, screenshots etc (see the [[#Courses|Courses]] section above for more info).

After checking/updating the metadata, the script will push the data to the selected Hub.

If the checkbox to allow download was selected, then the URL to a course upload script in the current Moodle is included with the metadata. This URL contains a token (eg an MD5 stored in the course table) that only the Hub knows.

The course upload script (eg /local/hub/webservice/upload.php?id=55&token=XXXXX) will expect the cached .zip file for the given course.

==== Publish course settings ====

Some publish settings and info will also be available anytime via the course settings page under a "Publish" tab:

* Which hubs has this course been published on, and when
* Full metadata
* Screenshots

== Harvest courses ==
'''NOT IMPLEMENTED'''
''Note: site to hub communication is one way only, the following text may change.''

Each hub will use cron to call every site that has registered a harvesting url on a periodic basis. This will be done at the same time as the link is checked to ensure the site is reachable, so the "time link was last checked" field in the site table also indicates when the site was last harvested.

The harvesting url will be an RSS feed which will list all the courses to be included in the hub and their metadata. This might be the feed of all visible courses on the site, or courses in a given category. TODO: should we allow them to enter multiple category feeds so they can say "arts", "business" and "languages" but not "science"?

Course list RSS feeds are an existing tracker item for Moodle 2.0 See http://tracker.moodle.org/browse/MDL-13248 This patch allows admins to pick which categories have individual feeds created and are included in the "all courses" feed. Each course becomes an <item> in the RSS feed as follows:

* <category> the Moodle course category in which the course belongs
* <title> the course fullname
* <link> the course url
* <pubdate> the date the course (or any of its resources and activities) last updated
* <description> the course summary

The current tracker item will need to be extended to include appropriate course metadata in the RSS feed. There is a [http://purl.org/dc/elements/1.1/ Dublin Core extension to RSS 2.0] which can be implemented.

TODO: If we choose an alternative metadata format we will need to locate or create an alternative RSS extension. There is a [http://www.downes.ca/xml/RSS_LOM.htm LOM extension] but not from an official IEEE namespace.

We will need to declare our own namespace RSS extension to identify whether a course should be listed in the hub as downloadable and/or enrollable. This extension will add tags to the RSS feed as follows:

* <moodlehub:downloadable>
* <moodlehub:enrollable>

Both tags will take either "yes" or "no" values and will be set by course creators at the same time as they enter course metadata.

The hub will check the published date for each item in the RSS feed to identify whether it needs to update its records. TODO: if we use OAI-PMH for harvesting we can request courses updated since x see http://moodle.org/mod/forum/discuss.php?d=127488

If the course has been updated and is <moodlehub:downloadable> is yes, then the hub will request the site to create a new backup of the entire course (less user data).

= See also =
* [https://docs.moodle.org/en/Community_hub Community hub]
* [https://docs.moodle.org/en/Development:Community_hub_-_technical_specification Development: community hub technical specification]

[[Category:Hub]]

[[ja:開発:コミュニティハブ]]

Comments UI Update

2025-02-10T08:00:20Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

=== Scenarios ===

==== Teacher Posts a Text Comment on Assignment Submission ====

The teacher creates a text comment about the user’s assignment submission. The comment is posted and then a message is sent informing the student that a new comment for the assignment has been created by the teacher.

==== Student Attaches File to a Comment on a Blog ====

A Carl Monk wants to show Xao Xin Mei a mathematical article article with a proof that confirms the theory she proposed in her latest blog post on music and math. After creating the text of the post Carl would like to drag the article file to the comment and have it attached for Xao to download later.

==== Student Posts Video Comment on an Assignment Submission ====

Kristen Sanchez doesn’t agree with the grade that Alex Souza gave her on her english paper. She wants to make sure the Alex sees her frustration with the lack of comments on her face and wishes to post a video comment to the assignment. After setting up her web cam Kristen clicks on the web cam button and begins to record her video message to her Alex. After she stops the recording and saves the comment the video is displayed in the commenting area.

==== Teacher Posts and Audio Comment to a Student’s Assignment ====

Phill O’Neil prefers not to have to type out his comments to students, instead he like to save a running commentary as he reviews their assignment. Phill opens up the assignment and then starts and audio comment in the comments area of the assignment. As Phill reads he states areas of the document that need to change. After he has finished reviewing the assignment submission he saves the audio comment and the student can review it.

==== Student Receives an Email That a new Comment has Been Posted ====

Phill O’Niel has posted a comment on a math proof that Carl Monk submitted to his course. Carl has configured his message output to send an email to him whenever a new comment is created for an assignment. Carl receives an email stating that Phill has created a comment on his math submission and that he can view the comment by clicking on a link.

=== Feature Information ===

==== Commenting Configuration ====

===== Description =====

Not all sites will want to allow file attachments in their comments. Site administrators will be able to enable or disable the robust commenting features.

===== Requirements =====

# A new link will be added to the Settings block under the Site administration group called Comments. See [[#Comments_Settings|Mockup: Comments Settings]]
# The comments link will display the comments settings page when clicked. See [[#Comments_Settings|Mockup: Comments Settings]]
# A new checkbox setting for comments will be added called Allow file attachments. See [[#Comments_Settings|Mockup: Comments Settings]]
# The allow file attachments checkbox will be checked by default. See [[#Comments_Settings|Mockup: Comments Settings]]
# The allow file attachments checkbox will have the descriptive text of ''Allow user’s to upload files to comments.'' below the checkbox. See [[#Comments_Settings|Mockup: Comments Settings]]
# A new drop down setting for comments will be added called maximum file upload. See [[#Comments_Settings|Mockup: Comments Settings]]
# The maximum file upload drop down will have a default value of 2MB. See [[#Comments_Settings|Mockup: Comments Settings]]
# The maximum file upload drop down will have the descriptive text of ''Define the largest size of file that can be uploaded to a comment, limited by the site-wide setting.''. below the drop down. See [[#Comments_Settings|Mockup: Comments Settings]]
# The maximum file upload drop down will use the Moodle default upload size values with a maximum of the site upload limit setting.
# The the allow file attachments setting is unchecked then the maximum upload size setting will be disabled.

===== Mockups =====

====== Settings Comments Link ======

[[Image:settingsCommentsLink.png|settingsCommentsLink.png]]

====== Comments Settings ======

[[Image:commentSettings.png|commentSettings.png]]

===== Use Cases =====

====== Site Administrator Disables File Attachments to Comments ======

'''Description'''

The site administrator determines that files should not be attached to comments and disables the feature at the site level

'''Preconditions'''

# The user is logged in
# The user is configured to be a site administrator
# The user is at the site level

'''Steps'''

# The site administrator expands the Site administration group in the settings block
# The site administrator clicks on the comments link
# The site administrator unchecked the Allow file uploads checkbox
# The site administrator clicks the ''Save changes'' button

'''Postconditions'''

# The file attachments area of comments doesn’t display
# users can’t upload files to a comment

====== Site Administrator Lowers the Maximum Upload Size in Comments ======

'''Description'''

The site administrator determines that the maximum size of a file uploaded to a comment should be lower than the site maximum upload size.

'''Preconditions'''

# The user is logged in
# The user is configured to be a site administrator
# The user is at the site level

'''Steps'''

# The site administrator expands the Site administration group in the settings block
# The site administrator clicks on the comments link
# The site administrator selects 100 KB for the Maximum upload size drop down
# The site administrator clicks the ''Save changes'' button

'''Postconditions'''

# When a user drags a file larger than 100 KB to the file area of a comment and error appears stating the file is too large.

==== Commenting Updates ====

===== Description =====

Moodlerooms will update the commenting API to add file upload support and anonymous display of comments.

===== Requirements =====

# The Moodle comment API will support a minified file uploader if Allow file uploads is checked in the comments site settings. (See [[#Viewing_and_Adding_Comments|Mockup: Viewing and Adding Comments]])
# The mini file uploader will display the following information: (See [[#Viewing_and_Adding_Comments|Mockup: Viewing and Adding Comments]])
## Add file with icon
## Drag and drop area if supported by the browser
## A list of files with their file type icon under the add file and drag and drop area.
# A new file manager form type will be created to support the mini file uploader.
# Comments will not require text in the text area to be saved if a file is uploaded.
# The user will click the save comment button to record the comment in the comment display area. (See [[#Viewing_and_Adding_Comments|Mockup: Viewing and Adding Comments]])
# The comment display will be updated to display the following information about the comment:
## The user’s profile picture
## The user’s fist and last name
## The date and time the comment was posted.
# The comment display area will display comments based on the plugins display preferences. (See [[#Viewing_and_Adding_Comments|Mockup: Viewing and Adding Comments]]) for an example.
# The comment API will allow a developer to determine the order comments are displayed in. The options will be:
## Newest first
## Oldest first
# The comment API will allow the developer to load all comments or a range of comments.
# A comment with a file attached to it will display the file below the comment text. (See [[#File_Attachment_to_Comment|Mockup: File Attachment to Comment]])
# If the comment site settings allow file attachments setting is unchecked then any previously attached files will not display in the comments.
# When the user clicks the save comment button the comment and any attachments will immediately display in the comment display area.
# When a user deletes or saves a comment the comments api will return any new comments to be displayed to the user.
# The comments API will support a plugin requesting to renderer comments with anonymised user data
# When a comment is set to render with anonymised user data then the work Participant with a number will display instead of the user's name. See [Mockup: Anonymous Comment!#AnonymousComment].
# When a comment is set to render with anonymised the number displayed with the participant text will be the user's id, context id for the comment and the item id all added together. See [Mockup: Anonymous Comment!#AnonymousComment].
# When a comment is set to render with anonymised the user's identification will change based on the context and plugin that the user's is commenting on. See [Mockup: Anonymous Comment!#AnonymousComment].
# The picture displayed with an anonymised comment will be the default user avatar for the Moodle theme. See [Mockup: Anonymous Comment!#AnonymousComment].
# The comment API will display comments for users with the permission to grade the activity when the comment is associated with an activity. See [Mockup: Anonymous Comment Stream|#AnonymousCommentStream]
# The comment API will allow user's to post content from repositories when set to be anonymous, even if the repository could give away the user's identity (for example video).
# The user that is viewing the comments will see all of their comments with their user information and not anonymised. See [Mockup: Anonymous Comment Stream|#AnonymousCommentStream]

===== Mockups =====

====== Viewing and Adding Comments ======

[[Image:viewcomments.png|viewcomments.png]]

====== Video Comment ======

[[Image:videocomment.png|videocomment.png]]

====== File Attachment to Comment ======

[[Image:fileattachmentcomment.png|fileattachmentcomment.png]]

====== Anonymous Comment ======

[[Image:anonymousComment.png|anonymousComment.png]]

====== Anonymous Comment Stream ======

[[Image:anonymousCommentStream.png|anonymousCommentStream.png]]

===== Use Cases =====

====== Teacher Uploads a File as a Comment to an Assignment Submission via Add Button ======

'''Description'''

The teacher has commented on a student’s submission offline and wants to upload the file as a submission comment and isn’t using a browser that supports drag and drop. They will upload the file via the add button and the upload repository.

'''Preconditions'''

# The user is logged in
# The user is enrolled as a teacher in a course
# An assignment has been created that allows submission comments
# A student has posted a submission
# The teacher has a file to upload on their desktop
# The user has navigated to the course
# Comment settings has the ''Allow file uploads'' checked

'''Steps'''

# The teacher clicks on the assignment name
# The teacher clicks the add button below the textarea
# The teacher clicks the ''Upload repository'' link
# The teacher clicks the ''Choose file'' button
# The teacher selects the file from their computer
# The teacher clicks the ''Upload file'' button
# The teacher clicks the ''Save comment'' button

'''Postconditions'''

# The teachers comment is displayed in the comment display area with the file attached
# If more than 2 comments have been created the scroll bar appears.

====== Teacher Uploads a File as a Comment to an Assignment Submission via Drag and Drop ======

'''Description'''

The teacher has commented on a student’s submission offline and wants to drag the file to the comment area to upload it.

'''Preconditions'''

# The user is logged in
# The user is enrolled as a teacher in a course
# An assignment has been created that allows submission comments
# A student has posted a submission
# The teacher has a file to upload on their desktop
# A browser that supports drag and drop is used
# The user has navigated to the course
# Comment settings has the ''Allow file uploads'' checked

'''Steps'''

# The teacher clicks on the assignment name
# The teacher drags the file from their pc to the drag and drop file area
# The teacher clicks the ''Save comment'' button

'''Postconditions'''

# The teachers comment is displayed in the comment display area with the file attached
# If more than 2 comments have been created the scroll bar appears.

====== Teacher Records a Video Comment for an Assignment Submission ======

'''Description'''

The teacher wants to record a visual comment about the student’s assignment submission instead of typing or commenting on a file.

'''Preconditions'''

# The user is logged in
# The user is enrolled as a teacher in a course
# An assignment has been created that allows submission comments
# A student has posted a submission
# The teacher has a web camera installed
# The site has the kaltura web cam TinyMCE button enabled
# The user has navigated to the course

'''Steps'''

# The teacher clicks on the assignment name
# The teacher clicks the web cam button in the file upload area
# The teacher records their web cam video
# The teacher clicks the ''Save comment'' button

'''Postconditions'''

# The teachers comment is displayed in the comment display area with a video player to play the video
# If more than 2 comments have been created the scroll bar appears.

====== Student Views More than 2 Assignment Submission Comments ======

'''Description'''

The student is viewing the submission comments for their assignment submissions. A conversation has been going on and the student is scrolling into the history to view some of the past comments by the teacher.

'''Preconditions'''

# The user is logged in
# The user is enrolled as a student in a course
# An assignment has been created that allows submission comments
# The student has posted a submission
# The teacher has posted more than 1 submission comment
# The student has posted more than 1 submission comment
# The user has navigated to the course

'''Steps'''

# The student clicks on the assignment name
# The student clicks up on the scrollbar

'''Postconditions'''

# As the scroll bar goes up previously created comments are displayed

====== Teacher Deletes a Comment With Attached Files ======

'''Description'''

The teacher wants to remove a comment they have made with files that we incorrectly attached.

'''Preconditions'''

# The user is logged in
# The user is enrolled as a teacher in a course
# An assignment has been created that allows submission comments
# A student has posted a submission
# The teacher has attached a file to a comment and saved it
# Comment settings has the ''Enable file uploads'' checked
# THe teacher has navigated to the course

'''Steps'''

# The teacher clicks on the assignment name
# The teacher clicks the delete button to the right of the comment

'''Postconditions'''

# The comment and all file attachments are deleted
# The comment is removed from the screen.

====== Student Views Assignment Submission Comments With a Screen Reader ======

'''Description'''

The student is visually impaired and reviewing the comments for their assignment submission using a screen reader.

'''Preconditions'''

# The user is logged in
# The user is enrolled as a student in a course
# An assignment has been created that allows submission comments
# A student has posted a submission
# The student has navigated to the course

'''Steps'''

# The student skips to the main content
# The student tabs to the activity name
# The student hits the enter key
# The student tabs to the comment area

'''Postconditions'''

# The student clearly understand the order of the comments
#
# ====== Student Views a Blind Marking Assignment Submission With Comments ======

'''Description'''

The student is viewing the submission comments for their assignment submissions. A conversation has been going on and the student is scrolling into the history to view some of the past comments by the teacher.

'''Preconditions'''

# The user is logged in
# The user is enrolled as a student in a course
# An assignment has been created that allows submission comments and is set to blind marking
# The student has posted a submission
# The teacher has posted more than 1 submission comment
# The student has posted more than 1 submission comment
# The user has navigated to the course

'''Steps'''

# The student clicks on the assignment name

'''Postconditions'''

# As the scroll bar goes up previously created comments are displayed

====== Teacher Views a Blind Marking Assignment Submission With Comments ======

'''Description'''

The teacher is views a student’s submission comments for an assignment that has been set to blind marking

'''Preconditions'''

# The user is logged in
# The user is enrolled as a teacher in a course
# An assignment has been created that allows submission comments and is set to blind marking
# The student has posted a submission
# The teacher has posted more than 1 submission comment
# The student has posted more than 1 submission comment
# The user has navigated to the course

'''Steps'''

# The teacher clicks on the assignment name
# The teacher clicks the ''View/grade all submissions'' link
# The teacher clicks on the grade icon for one of the students in the grade table

'''Postconditions'''

# All comments made by the student are set to Participant and a number
# The teacher’s comment displays their name above it.

==== Comments Backup and Restore ====

===== Description =====

Moodlerooms will update the commenting API to support files in the backup and restore process.

===== Requirements=====
# If a file is attached to a comment it will be backed up with the comment following the current backup process.
# Anonymous comments will not be anonymous in the course backup and will be associated with the user who created the comment.

===== Use Cases =====

====== Site Administrator Backs up a Course with Comments ======

'''Description'''

The site administrator wants to backup the current course with the user’s data.

'''Preconditions'''

# The user is logged in
# The user is set as a site administrator
# An assignment has been created that allows submission comments
# A student has posted a submission
# A teacher has commented on the assignment submission
# A student has commented on the assignment submission
# The site administrator has navigated to a course

'''Steps'''

# The site administrator clicks the ''Backup'' link in the Settings block under the Course Administrator group
# The site administrator leaves the default settings
# The site administrator click the ''Next'' button
# The site administrator leaves the default settings
# The site administrator clicks the ''Next'' button
# The site administrator clicks the ''Perform backup'' button
# The site administrator clicks the ''Continue'' button

'''Postconditions'''

# The files attached to user comments in the backup are in the backup file
# If the course is restored the comments will show with the files attached to the correct comments.

====== Site Administrator Restores a Course with Comments ======

'''Description'''

The site administrator wants to restore a course that has user’s data and comments on assignments.

'''Preconditions'''

# The user is logged in
# The user is set as a site administrator
# The site administrator has a course backup that contains the following:
## An assignment has been created that allows submission comments
## A student has posted a submission
## A teacher has commented on the assignment submission
## A student has commented on the assignment submission
# The site administrator is at the site level
# The backup file is less than 50 MB in size.

'''Steps'''

# The site administrator clicks the ''Restore'' link in the Settings block under Front page administration
# The site administrator drags the backup file to the drag and drop file area.
# The site administrator clicks the ''Restore'' button
# The include comments is checked under backup settings
# The site administrator clicks the ''Continue'' button
# The site administrator selects a category radio button under Restore as a new course
# The site administrator clicks the ''Continue'' button under Restore as a new course
# The site administrator keeps the default settings
# The site administrator clicks the ''Next'' button
# The site administrator clicks the ''Next'' button
# The site administrator clicks the ''Perform restore'' button
# The site administrator clicks the ''Continue'' button

'''Postconditions'''

# The site administrator can view the comments within the assignment.
# The comments have files correctly attached to each comment.

==== Comment Message Output ====

===== Description =====

When a new comments is created it is not communicated to the student or teacher. This makes comments less useful for many plugins that user comments as an important communication to both users. Comments will be updated to have a message output event that message outputs can display and a student or teacher can set to send to each message output type they want.

===== Requirements =====

# A new message output event will be created for comments.
# All comments when created will trigger a comment event that the message outputs can listen for.
# The comment message event sender will be set to the user that made the comment
# The comment message event recipient will be all users with the role to view the comment who are not the comment creator.
# The comment message event subject will be “New comment for <context>” where context is the location that the comment was created:
## Comment block - the course or activity the block is associated with
## Assignment submission - the assignment the comment is associated with
## Blog comment - the blog the comment is associated with.
# The comments message event full message will contain the following:
## The full comment in plaintext
## Text stating “View original message” that is linked to url to the comment in the location in Moodle where the user can view the comment (Comment block in course or assignment submission)
# The comment message event full message format will be plaintext.
# The comments message event short message will contain the following:
## Up to 80 character of the original comment in plain text
## The text “View original message at <url>” where the <url> is the url to the location in Moodle where the user can view the comment
# By default the message output settings for the comments event will be enabled for: (see [[#User_Message_Output_Settings|Mockup: User Message Output Settings]])
## Email
### When logged in
### When not logged in
## Alert
### When logged in
### When not logged in
## Streams
### When logged in
### When not logged in

===== Mockups =====

====== User Message Output Settings ======

[[Image:commentmessageoutput.png|commentmessageoutput.png]]

===== Use cases =====

====== Student Accesses an Alert After a Teacher Posts a Comment to an Advanced Forum in Joule Grader ======

'''Description'''

A teacher posts a comment for a student’s submission to an activity in the Joule grader and the student receives an alert when they login.

'''Preconditions'''

# User is logged in
# User is enrolled in a course as a student
# User has posted a submission to an advanced forum
# A teacher has posted an activity comment in the Joule grader for the student and activity

'''Steps'''

# The student views the front page
# The student sees a number of alerts in the upper right of the page
# The student clicks on the icon
# The student sees a Joule grader comment for an activity
# The student clicks on the link to the full comment in the Joule grader

'''Postconditions'''

# The student is show the activity in the Joule grader and the comment shows in the Activity comments area

====== Student Accesses an Alert After a Teacher Posts a Comment to an Assignment in Joule Grader ======

'''Description'''

A teacher posts a comment for a student’s submission to an activity in the Joule grader and the student receives an alert when they login.

'''Preconditions'''

# User is logged in
# User is enrolled in a course as a student
# User has posted a submission to an Assignment
# A teacher has posted an activity comment in the Joule grader for the student and activity

'''Steps'''

# The student views the front page
# The student sees a number of alerts in the upper right of the page
# The student clicks on the icon
# The student sees a Joule grader comment for an activity
# The student clicks on the link to the full comment in the Joule grader

'''Postconditions'''

# The student is show the activity in the Joule grader and the comment shows in the Activity comments area

====== Student Changes Their Comments Alert Message Output ======

'''Description'''

A student changes their message outputs to not display alerts when they are online for comments.

'''Preconditions'''

# User is logged in
# User is enrolled in a course as a student

'''Steps'''

# The student clicks on the ''My profile'' link
# The student selects message outputs in the settings block
# The student clicks on the alert when online for the comments setting.
# The student clicks the ''Save changes'' button

'''Postconditions'''

# The next comment in the Joule grader the student receives and email.

====== Student Changes Their Offline Comments Email Message Output Setting ======

'''Description'''

A student changes their message outputs to receive emails when they are offline for comments.

'''Preconditions'''

# The user is logged in
# The user is enrolled in a course as a student

'''Steps'''

# The student clicks on the ''My profile'' link
# The student selects ''Message outputs'' in the settings block
# The student clicks on the email when offline for the Comments setting.
# The student clicks the ''Save changes'' button

'''Postconditions'''

# The next comment on the student’s assignment submission will be emailed to the student if they are not logged into Moodle.

====== Student Clicks the URL to the Comment in the Message Output Email ======

'''Description'''

The student has received a comment message output in their email. The student clicks on the link to view the comment in Moodle.

'''Preconditions'''

# The user is not logged in
# The user received an email notifying them that a new comment exists

'''Steps'''

# The student clicks on the link in the email
# The student enters their username
# The student enters their password
# The student clicks the ''Login'' button

'''Postconditions'''

# The student is taken to the Moodle page where the comment can be read

=== Document Information ===

==== Revision Summary ====

==== Revision History ====

* Jason Hardin 20130131: Split out Joule features from Moodle features. Added new mockups for Moodle specific interfaces. Updated the Comments update use cases to include deletion and screen readers.
* Jason Hardin 20130205: Added message output event information. Added a new use case for navigating to the comment in Moodle from email, and updated screen shots to remove old information and add some more descriptive information.
* Jason Hardin 20130212: Removed the HTML editor setting and migrated video and audio comments to using the file picker.
* Jason Hardin 20130221: Added Alerts and streams back to the specification as these will be released to the Moodle Community.
* Jason Hardin 20130221: Added anonymous comment support to allow for Blind marking in assignment submission comments. See tracker ticket [https://tracker.moodle.org/browse/MDL-37497| MDL-37497]
* Jason Hardin 20130222: Moved Joule Comments changes back into this specification because Moodlerooms will be releasing all Joule features that caused the specification separation.

==See also==
[https://moodle.org/mod/forum/discuss.php?d=221619| Comments Forum Discussion]
[[Category: Project]]

Cohorts

2025-02-10T07:59:39Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Work in progress}}
{{Infobox Project
|name = Cohorts
|state = Work in progress
|tracker = MDL-21781
|discussion = n/a
|assignee = [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]]
}}
{{Moodle 2.0}}
=Goals=
Site-wide groups (aka cohorts) is one of the most requested missing features.
# Simplify manual enrolments - instead of enrolling students one by one, it would be possible to enrol a cohort with single click.
# Cohort enrolment plugin - new enrolment plugin synchronising users in cohort with enrolments in a course (including role assignment and group membership)
# Synchronisation with external systems - some external systems do not know the actual courses, they only contain some user groups, at present we do not have a simple way to reuse these groups in Moodle.
# Partially replace meta courses
# Replace category enrolments - category enrolments have major design issues and are not compatible with incoming enrolment changes.
=DB tables=
Table ''cohort'' definition of site-wide groups (aka cohorts)
{| class="wikitable"
! Field
! Type
! Default
! Description
|-
| '''id'''
| int(10)
| auto-incrementing
|
|-
| '''contextid'''
| int(10)
|
| foreign key, references context.id
|-
| name
| char(254)
|
| human readable cohort name
|-
| '''idnumber'''
| char(100)
|
| unique identifier of the cohort, can be used in external systems
|-
| description
| text
|
| longer description
|-
| descriptionformat
| int(2)
|
| text format
|-
| component
| char(100)
|
| component name of a plugin responsible for assignment of users (ex: auth_ldap, etc.), NULL means manual assignments
|-
| timecreated
| int(10)
|
| timestamp, creation date
|-
| timemodified
| int(10)
|
| timestamp, last modification
|}
Context specified can be system or course category level, defining of cohort a course context would not make much sense.

Table ''cohort_members'' stores cohort members
{| class="wikitable"
! Field
! Type
! Default
! Description
|-
| '''id'''
| int(10)
| auto-incrementing
|
|-
| '''cohortid'''
| int(10)
|
| foreign key, references cohort.id
|-
| '''userid'''
| int(10)
|
| foreign key, references user.id
|-
| timeadded
| int(10)
|
| timestamp, when added
|}
=New capabilities=
* moodle/cohort:assign - add/delete members (only for manual assignment cohorts with source == null)
* moodle/cohort:manage -add/delete/move cohorts
* moodle/cohort:view - view membership and use cohort elsewhere
Context id defined in cohort table is used for access control only, the cohort may be actually used in any context (this may happen when moving courses, categories or cohorts).
=User interface=
# Cohort edit link in CONTEXT_SYSTEM and each CONTEXT_COURSECAT- most probably from the settings block
# Option for manual cohort enrolment - part of new enrolment UI
# New UI in cohort enrolment plugin
# New options in group creation UI
# New options for sync with external groups in auth or enrol plugins
=Implementation steps=
# add db tables and cohort membership UI
# add option to assign role to all cohort users (one time only, no sync)
# enrolment rewrite
# cohort enrolment plugin
=Upgrade=
Cohorts are designed to replace course category enrolments because the new enrolment plugin is not compatible with this.
=See also=
* [[Enrolment rewrite and role tweaks proposal]]
* [[New permissions evaluation in 2.0]]
* [[New permission overriding UI]]
* [[New enrolments in 2.0]]
[[Category:Roles]]

Caliper

2025-02-10T07:57:35Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

== Introduction ==

The Caliper Logstore component uses the Moodle Logging interface to capture user events and emit them to a Caliper event store. The [https://www.imsglobal.org/caliper Caliper Framework] is a specification from IMS Global which provides a data representation of learning activities and an API for transmitting these to an event store for later analysis. Metric profiles are used to describe different types of learning activity, allowing representations to be matched against the nature of the activity. Events may be sent immediately to the event store, or captured for sending later in batches.

== Events supported ==

The following table shows the mapping of Moodle URLs to Caliper events supported by the current version of this component:

{| class="wikitable"
|+Supported Caliper Events
|-
!Metric Profile
!Action
!Moodle URL
|-
|rowspan="2"|Session
|Logged In
|\core\event\user_loggedin
|-
|Logged Out
|\core\event\user_loggedout
|-
|Navigation
|Navigated To
|\core\event\course_viewed
|-
|View
|Viewed
|
\mod_book\event\course_module_viewed 
\mod_chat\event\course_module_viewed 
\mod_choice\event\course_module_viewed 
\mod_data\event\course_module_viewed 
\mod_facetoface\event\course_module_viewed 
\mod_feedback\event\course_module_viewed 
\mod_folder\event\course_module_viewed 
\mod_forum\event\course_module_viewed 
\mod_forum\event\user_report_viewed 
\mod_glossary\event\course_module_viewed 
\mod_imscp\event\course_module_viewed 
\mod_lesson\event\course_module_viewed 
\mod_lti\event\course_module_viewed 
\mod_page\event\course_module_viewed 
\mod_quiz\event\attempt_reviewed 
\mod_quiz\event\attempt_viewed 
\mod_quiz\event\course_module_viewed 
\mod_resource\event\course_module_viewed 
\mod_scorm\event\course_module_viewed 
\mod_survey\event\course_module_viewed 
\mod_url\event\course_module_viewed 
\mod_wiki\event\course_module_viewed 
\mod_workshop\event\course_module_viewed
|-
|rowspan="2"|Assessment
|Started
|\mod_quiz\event\attempt_started
|-
|Submitted
|
\mod_quiz\event\attempt_submitted 
\mod_assign\event\assessable_submitted
|-
|Outcome
|Graded
|\mod_assign\event\submission_graded
|-
|}

== How does it work? ==

The component adopts the same implementation method as the logstore component for [https://moodle.org/plugins/logstore_xapi xAPI]. It is made up of three parts: an [https://github.com/LearningLocker/Moodle-Log-Expander Expander], a Translator, and an Emitter. Each log entry follows a six step process before finally reaching the event store:

# The component passes the log entry from the logstore_standard_log to the Expander.
# The Expander expands the log entry with data from the Moodle database.
# The component passes the expanded event from to the Translator.
# The Translator translates the expanded event to Caliper metric profile options.
# The component passes the translated event to the Emitter.
# The Emitter emits the event to the event store using the Caliper Sensor API.

== Installation ==

The component can be installed onto a Moodle 2.7+ instance as follows:

# [https://moodle.org/plugins/logstore_caliper Download the component].
# Log into your instance of Moodle as a System Administrator.
# Go to ''/admin/tool/installaddon/'' on your Moodle instance.
# Drag and drop your download from step 1.
# Click ''Install plugin from the ZIP file''.
# Click ''Install plugin!''.
# Click ''Upgrade Moodle database now''.
# Click ''Continue''.
# Complete the component's settings page:
#* ''Event Store URL'';
#* ''API Key'';
#* ''Send statements immediately to event store?'';
#* ''Batch size''.
# Click ''Save changes''.
# Go to ''/admin/settings.php?section=managelogging'' on your Moodle instance.
# Enable the ''Caliper log store'' component (use the ''Settings'' option to update the component's settings values).

NB If zip installation is disabled, you can unzip the zip file to ''/admin/tool/log/store'' instead of steps 3 to 5 above.

== About the Contributors ==

This plugin was contributed by the Blackboard Product Development team in collaboration with Stephen Vickers. Blackboard is an education technology company dedicated to bringing excellent online teaching to institutions across the globe. We serve colleges and universities, schools and organizations by supporting the software that educators use to manage and deliver instructional content to learners in virtual classrooms. We are proud to be a Moodle Partner company.

CSS styles moz.css

2025-02-10T07:54:33Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

== styles_moz.css ==
This [[CSS]] file uses the non-standard Mozilla CSS extensions to add round corners to the current theme. Styles are organised into the following sections: core, header, footer, admin, blocks, calendar, course, doc, login, message, tabs, user, various modules

<h3>Core</h3>

.headingblock {
-moz-border-radius:3px;
}

.notifyproblem {
-moz-border-radius:10px;
}

.notifysuccess {
-moz-border-radius:10px;
}
.generalbox {
-moz-border-radius-topleft:3px;
-moz-border-radius-topright:3px;
-moz-border-radius-bottomleft:15px;
-moz-border-radius-bottomright:15px;
}

.generalboxcontent {
-moz-border-radius-topleft:3px;
-moz-border-radius-topright:3px;
-moz-border-radius-bottomleft:15px;
-moz-border-radius-bottomright:15px;
}

.noticebox {
-moz-border-radius:5px;
}

.informationbox {
-moz-border-radius-topleft:3px;
-moz-border-radius-topright:3px;
-moz-border-radius-bottomleft:15px;
-moz-border-radius-bottomright:15px;
}

.informationboxcontent {
-moz-border-radius-topleft:3px;
-moz-border-radius-topright:3px;
-moz-border-radius-bottomleft:15px;
-moz-border-radius-bottomright:15px;
}

.sitetopiccontent {
-moz-border-radius:15px;
}

.headingblock {
-moz-border-radius:3px;
}

.categorybox, .categoryboxcontent,
.coursebox, .courseboxcontent {
-moz-border-radius:20px;
}

/* kept for backward compatibility with some non-standard modules
which use these classes for various things */
.generaltab, .generaltabinactive{
-moz-border-radius-topleft:15px;
-moz-border-radius-topright:15px;
}

.generaltabselected {
-moz-border-radius-topleft:15px;
-moz-border-radius-topright:15px;
}

<h3>Blocks</h3>

.sideblock.hidden {
-moz-border-radius: 0px;
}

.sideblock .content {
-moz-border-radius-bottomleft:20px;
-moz-border-radius-bottomright:20px;
}

.block_course_summary, .block_course_summary .content {
-moz-border-radius:20px;
}

.editing .block_course_summary .content {
-moz-border-radius-topleft:0;
-moz-border-radius-topright:0;
}

<h3>Calendar</h3>

#calendar .eventlist .event {
-moz-border-radius-bottomleft:15px;
-moz-border-radius-bottomright:15px;
}

#calendar .eventlist .event .side {
-moz-border-radius-bottomleft:15px;
}

#calendar .eventlist .event .description {
-moz-border-radius-bottomright:15px;
}

#calendar .maincalendar,
#calendar .sidecalendar
{
-moz-border-radius-bottomright:20px;
-moz-border-radius-bottomleft:20px;
}

#calendar .maincalendar .filters table,
#calendar .sidecalendar .filters table,
.sideblock.block_calendar_month .filters table
{
-moz-border-radius:4px;
}

table.minicalendar {
-moz-border-radius:10px;
}

table.minicalendar td {
-moz-border-radius:4px;
}

<h3>Course</h3>

body#course-user .section {
-moz-border-radius:20px;
}

<h3>Login</h3>

.loginbox {
-moz-border-radius-bottomleft:20px;
-moz-border-radius-bottomright:20px;
}

.loginbox .content.left {
-moz-border-radius-bottomleft:20px;
}
.loginbox .content.right {
-moz-border-radius-bottomright:20px;
}

<h3>User</h3>

.userinfobox {
-moz-border-radius-bottomleft:20px;
-moz-border-radius-bottomright:20px;
}

.groupinfobox {
-moz-border-radius-bottomleft:20px;
-moz-border-radius-bottomright:20px;
}
#user-view .left {
-moz-border-radius-bottomleft:20px;
}

<h3>Modules: Forum</h3>

.forumpost {
-moz-border-radius-bottomleft:20px;
-moz-border-radius-bottomright:20px;
}

.forumpost .side {
-moz-border-radius-bottomleft:20px;
}

.forumpost .content {
-moz-border-radius-bottomright:20px;
}

.forumpost .message {
-moz-border-radius-bottomright:20px;
}

<h3>Modules: Glossary</h3>

.categoryheader {
-moz-border-radius-topleft:15px;
-moz-border-radius-topright:15px;
}

.glossaryformatheader {
-moz-border-radius-topleft:15px;
-moz-border-radius-topright:15px;
}

.entryboxheader {
-moz-border-radius-topleft:10px;
-moz-border-radius-topright:10px;
}

.entrybox {
-moz-border-radius-bottomleft:10px;
-moz-border-radius-bottomright:10px;
}

.glossarypost {
-moz-border-radius-bottomleft:15px;
-moz-border-radius-bottomright:15px;
}

.glossarypost .side {
-moz-border-radius-bottomleft:15px;
}

.encyclopedia .entrylowersection {
-moz-border-radius-bottomright:15px;
}
.glossarycomment {
-moz-border-radius-bottomleft:20px;
-moz-border-radius-bottomright:20px;
}

.glossarycomment .side {
-moz-border-radius-bottomleft:20px;
}

.glossarycomment .entry {
-moz-border-radius-bottomright:20px;
}

<h3>Modules: Journal</h3>

#mod-journal-view .feedbackbox {
-moz-border-radius-bottomleft:15px;
-moz-border-radius-bottomright:15px;
}
#mod-journal-view .feedbackbox .side {
-moz-border-radius-bottomleft:15px;
}
#mod-journal-view .feedbackbox .entrycontent {
-moz-border-radius-bottomright:15px;
}

Blog 2.0

2025-02-10T07:51:27Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Moodle 2.0}}

* '''PROJECT STATE: Complete'''
* '''MAIN TRACKER ISSUE''': MDL-19676 Blog 2.0 improvements
* '''DISCUSSION AND COMMENTS''': http://moodle.org/mod/forum/discuss.php?d=133348

== Description of improvements ==
=== Who can view blog entries? ===
Blog entries are either in draft mode (only the author can view it), or in public mode. In public mode, everyone on the entire site can view the blog entry.

Before 2.0 there was an attempt to restrict who can view certain blog entries, based on course enrolment and capabilities. However, after extensive discussion and feasibility testing it became clear that this could lead to serious performance and usability issues on large sites, and was turning the blog into something more akin to a forum. It was thus decided to make all blogs public. (See MDL-19676)

This simplification means that sites using the old BLOG_GROUP_LEVEL and BLOG_COURSE_LEVEL and values of $CFG->bloglevel have to perform an special upgrade which copies all the site's blog entries into a special "blog-type" forum in each course in which the blog entry's author is enrolled, then disables blogging at site level.

Capabilities:
*moodle/blog:view
*moodle/blog:viewdrafts

=== Associations ===
A blog entry can optionally be associated with a course. This makes it possible for a user to blog "about" that course. All blog entries associated in that way can be viewed on a page like blog/index.php?courseid=3. This type of filtering of blog entries does not take into account course enrolments.

Additionally, blog entries can be associated with an activity module.

This requires the creation of a new table, in which the associations are recorded.
Tracker issue: MDL-14408

Capabilities:
*moodle/blog:associatecourse
*moodle/blog:associatemodule

=== Improved navigation ===
Before 2.0, the navigation for any listing of blog entries was either "Site > User > Blogs" (for a user's blog entries) or "Site > Blogs" for the whole site's blog entries, optionally filtered by tag. With the new association features, we need a better way to display what type of blog listing we are looking at, based on the parameters passed to blog/index.php. The navigation should also reflect additional filters such as tag and search.

=== External blogs ===
A user can specify external blogs which publish an RSS/ATOM feed. This feed is then checked periodically through a cron task, and entries are copied into the user's blog in Moodle, as read-only entries.

This synchronisation checks if external entries have been modified or deleted since the last sync, and updates the Moodle entries accordingly.

These external blogs are a user preference, and two types of tags can be added to each of them: "Filter tags" and "Automatic tags":
*Filter tags are used to filter the external blog entries that get copied into Moodle. They must match the tags used by that external blog. An external entry will be selected if it has at least one of the filter tags. (Tags are called "categories" in RSS feeds)
*Automatic tags are automatically added to each blog entry copied into Moodle from an external blog that uses such tags.

This requires the creation of a new DB table.
Tracker issue: MDL-19683

Capabilities:
*moodle/blog:manageexternal

=== Search blog entries ===
It is now possible to search blog entries using a search box. The results maintain the current context, so that if you are viewing a list of blog entries for a particular user, entering a term in the search box will return only the blog entries for that user that match the search term. The search term also appears in the navigation breadcrumbs.

Tracker issue: MDL-19686

Capabilities:
*moodle/blog:search

=== Contextual blog menu ===
Previously, the "blog menu" block was the same on every page on which it appeared. In 2.0 it changes depending on which page you are. For example, if you are on course/view.php, it will include a link to blog entries associated with that course. Also, the link for adding a new entry will include the courseid, making the course association automatically pre-selected in the blog entry edit form.

Tracker issue: MDL-19687

=== File attachments ===
The [[File_API|new file manager]] must be implemented to allow for multiple file attachments per blog entry.

Tracker issue: MDL-19744

=== Comments ===
The new [[Comments_2.0|Comments API]] makes it possible for anyone having the correct capability to comment on blog entries.

Tracker issue: MDL-8776

=== New "Recent blog entries" block ===
This block can be configured to display the last N blog entries, filtered by context. For example, if you are viewing an assignment activity, this block would display the last N blog entries that are associated with that assignment.

Tracker issue: MDL-19688

== Potential problems and limitations ==

===Upgrade from "Users can only see blogs for people who share a course"===

This mode was always a slightly quirky and uncomfortable hack. It was mostly useful for sites with very distinct courses and users, such as those where each course consists of the employees from a separate company, and My Moodle was used to hide the companies from each other. However, for the general case, the main problem is that you see ALL blog entries from those people, not just ones that are about your courses.

This mode has no direct equivalent in Moodle 2.0 because we have resolved not to emulate "course-like" modes within a system that is at system level, and outside the courses. This helps understanding of the blog system, simplifies the implementation and improves performance.

However some people may be using that mode so we do need to provide an upgrade path for them.

Informationally, the idea of just seeing all the blogs from people who are in your course is the same as a course forum.

So a possible upgrade would be to do this:
If the mode is set to "Users can only see blogs for people who share a course" then
Set the new mode to "Users can only see their own blog"
Foreach user who has a blog
Foreach course that user is enrolled in
If a "Course blogs (recovered)" forum doesn't exist yet in the course (section 0) then create one
Foreach blog entry that the user created
Create a new discussion from the blog post with the same dates, attachments etc

This way no data is lost. The teachers can choose to delete the whole forum if they choose to. The original blog entries should not be touched.

== DB Structure ==
2 new tables need to be added: blog_external and blog_association

=== blog_external ===

{| class="wikitable"
|-
! Field
! Type
! Default
! Info
|-
| id
| int(10)
| auto-incrementing
| The unique ID for this external blog.
|-
| userid
| int(10)
|
| The owner of the external blog
|-
| name
| char(255)
|
| A descriptive name for the external blog. Automatically fetched during initial import, can be overridden.
|-
| description
| text(small)
|
| A long description of the external blog. Automatically fetched during initial import, can be overridden.
|-
| url
| text(small)
|
| The URL to the external blog (e.g. http://moodle.org/rss.xml)
|-
| failedlastsync
| int(1)
|
| Whether or not the last synchronisation failed
|-
| timemodified
| int(10)
|
|
|-
| timefetched
| int(10)
|
| The last time the entries from this external blog were fetched by Moodle.
|}

=== blog_association ===

{| class="wikitable"
|-
! Field
! Type
! Default
! Info
|-
| id
| int(10)
| auto-incrementing
| The unique ID for this blog entry<->contextid association.
|-
| contextid
| int(10)
|
| The context id defined in context table - identifies the instance of the course or plugin associated with the blog entry.
|-
| blogid
| int(10)
|
| The id of the blog entry (from the post table) being associated with a course or module instance
|}

== Upgrade process ==
The only task required by the upgrade process is to install the new DB tables.

== See also ==
*[[Blogs|Early wishlist]]
*[[Student_projects/Blog_improvements|2008 GSoC project addressing some of these improvements]]

[[Category:Blog]]

Blocks/Appendix A

2025-02-10T07:50:37Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

== Appendix A: ''block_base'' Reference ==
{{main|Blocks}}
This Appendix will discuss the base class '''block_base''' from which all other block classes derive, and present each and every method that can be overridden by block developers in detail. Methods that should '''not''' be overridden are explicitly referred to as such. After reading this Appendix, you will have a clear understanding of every method which you should or could override to implement functionality for your block.

The methods are divided into three categories:
:#[[Blocks/Appendix_A#Methods_you_can_freely_use_and_override:|those you may use and override in your block]];
:#[[Blocks/Appendix_A#Methods_which_you_should_not_override_but_may_want_to_use:|those that you may '''not''' override but might want to use]];
:#[[Blocks/Appendix_A#Methods_which_you_should_not_override_and_not_use_at_all:|those internal methods that should '''neither''' be used '''nor''' overridden]].
In each category, methods are presented in alphabetical order.

== Methods you can freely use and override: ==

{{Moodle 1.7}}
=== after_install() ===

<syntaxhighlight lang="php">
function after_install() {
}
</syntaxhighlight>

Available between Moodle 1.7 and Moodle 1.9

This method is designed to be overridden by block subclasses, and allows you to specify a set of tasks to be executed after the block is installed. For example, you may wish to store the date on which the block was installed. However, each database type has its own way of getting the current date, and when using XMLDB to install your block, these operations are also unsupported. So the best way to complete such a task while maintaining database abstraction is to use XMLDB to install the block, and then use the after_install() method to perform the insertion before the block is used.

Please note that after_install() is called once per block, not once per instance.

{{Moodle 2.0}}
The after_install() method is no longer present in Moodle 2.0. Instead, you should use an install.php file, located within your /blocks/<yourblock>/db/ folder, to perform these actions.

=== applicable_formats() ===

<syntaxhighlight lang="php">
function applicable_formats() {
// Default case: the block can be used in courses and site index, but not in activities
return array(
'all' => true,
'mod' => false,
);
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method allows you to control which pages your block can be added to. Page formats are formulated from the full path of the script that is used to display that page. You should return an array with the keys being page format names and the values being booleans (true or false). Your block is only allowed to appear in those formats where the value is true.
Example format names are: '''course-view''', '''site-index''' (this is an exception, referring front page of the Moodle site), '''course-format-weeks''' (referring to a specific course format), '''mod-quiz''' (referring to the quiz module) and '''all''' (this will be used for those formats you have not explicitly allowed or disallowed).

The full matching rules are:

# Prefixes of a format name will match that format name; for example, '''mod''' will match all the activity modules. '''course-view''' will match any course, regardless of the course format. And finally, '''site''' will also match the front page (remember that its full format name is '''site-index''').
# The more specialized a format name that matches our page is, the higher precedence it has when deciding if the block will be allowed. For example, '''mod''', '''mod-quiz''' and '''mod-quiz-view''' all match the quiz view page. But if all three are present, '''mod-quiz-view''' will take precedence over the other two because it is a better match.
# The character '''<nowiki>*</nowiki>''' can be used in place of any word. For example, '''mod''' and '''mod-*''' are equivalent. At the time of this document's writing, there is no actual reason to utilize this "wildcard matching" feature, but it exists for future usage.
# The order that the format names appear does not make any difference.
The format name for the Dashboard (or My Moodle in earlier versions) is '''my'''.
=== before_delete() ===

<syntaxhighlight lang="php">
function before_delete() {
}
</syntaxhighlight>

Available in Moodle 1.7 and later

This method is called when an administrator removes a block from the Moodle installation, immediately before the relevant database tables are deleted. It allows block authors to perform any necessary cleanup - removing temporary files and so on - before the block is deleted.

=== instance_create() ===

<syntaxhighlight lang="php">
function instance_create() {
}
</syntaxhighlight>

Available in Moodle 1.5 and later

Do any additional initialization you may need at the time a new block instance is created.

=== instance_copy() ===

<syntaxhighlight lang="php">
function instance_copy($fromid) {
}
</syntaxhighlight>

Available in Moodle 2.9 and later

Copy any block-specific data when copying to a new block instance.

=== instance_delete() ===

<syntaxhighlight lang="php">
function instance_delete() {
}
</syntaxhighlight>

Available in Moodle 1.5 and later

Delete everything related to this instance if you have been using persistent storage other than the configdata field.

=== config_print() ===

<syntaxhighlight lang="php">
function config_print() {
// Default behavior: print the config_global.html file
// You don't need to override this if you're satisfied with the above
if (!$this->has_config()) {
return FALSE;
}
global $CFG, $THEME;

print_simple_box_start('center', '', $THEME->cellheading);
include($CFG->dirroot.'/blocks/'. $this->name() .'/config_global.html');
print_simple_box_end();
return TRUE;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method allows you to choose how to display the global configuration screen for your block. This is the screen that the administrator is presented with when he chooses "Settings..." for a specific block. Override it if you need something much more complex than the default implementation allows you to do. However, keep these points in mind:

* If you save your configuration options in $CFG, you will probably need to use global $CFG; before including any HTML configuration screens.
* The HTML <input> elements that you include in your method's output will be automatically enclosed in a <form> element. You do not need to worry about where and how that form is submitted; however, you '''must''' provide a way to submit it (i.e., an <input type="submit" />.
You should return a boolean value denoting the success or failure of your method's actions.

=== config_save() ===

<syntaxhighlight lang="php">
function config_save($data) {
// Default behaviour: save all variables as $CFG properties
// You don't need to override this if you 're satisfied with the above
foreach ($data as $name => $value) {
set_config($name, $value);
}
return TRUE;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method allows you to override the storage mechanism for your global configuration data. The received argument is an associative array, with the keys being setting names and the values being setting values. The default implementation saves everything as Moodle $CFG variables.
Note that $data does not hold all of the submitted POST data because Moodle adds some hidden fields to the form in order to be able to process it. However, before calling this method it strips the hidden fields from the received data and so when this method is called only the "real" configuration data remain.

You should return a boolean value denoting the success or failure of your method's actions.

=== get_content() ===

<syntaxhighlight lang="php">
function get_content() {
// This should be implemented by the derived class.
return NULL;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method should, when called, populate the [[#.24this-.3Econtent| $this->content]] variable of your block. For details of how to do this, see the [[#.24this-.3Econtent|$this->content]] section below.

=== has_config() ===

<syntaxhighlight lang="php">
function has_config() {
return FALSE;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method should return a boolean value that denotes whether your block wants to present a configuration interface to site admins or not. The configuration that this interface offers will impact all instances of the block equally.
To actually implement the configuration interface, you will either need to rely on the default [[#config_print.28.29|config_print()]] method or override it. The full guide contains [[Blocks#The_Effects_of_Globalization|more information on this]].

=== hide_header() ===

<syntaxhighlight lang="php">
function hide_header() {
//Default, false--> the header is shown
return FALSE;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method should return a boolean value that denotes whether your block wants to hide its header (or title). Thus, if you override it to return true, your block will not display a title unless the current user is in editing mode.

=== html_attributes() ===

<syntaxhighlight lang="php">
function html_attributes() {
// Default case: an id with the instance and a class with our name in it
return array('id' => 'inst'.$this->instance->id, 'class' => 'block_'. $this->name());
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method should return an associative array of HTML attributes that will be given to your block's container element when Moodle constructs the output HTML. No sanitization will be performed in these elements at all.

If you intend to override this method, you should return the default attributes as well as those you add yourself. The recommended way to do this is:

<syntaxhighlight lang="php">
function html_attributes() {
$attrs = parent::html_attributes();
// Add your own attributes here, e.g.
// $attrs['width'] = '50%';
return $attrs;
}
</syntaxhighlight>

=== init() ===

<syntaxhighlight lang="php">
function init() {
$this->title = get_string('simplehtml', 'block_simplehtml');
$this->version = 2004111200;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method must be implemented for all blocks. It has to assign meaningful values to the object variables [[#.24this-.3Etitle|$this->title]] and [[#.24this-.3Eversion|$this->version]] (which is used by Moodle for performing automatic updates when available).

No return value is expected from this method.

=== instance_allow_config() ===
{{Moodle 1.9}}

<syntaxhighlight lang="php">
function instance_allow_config() {
return FALSE;
}
</syntaxhighlight>

Available in Moodle 1.5 through 1.9.

This method should return a boolean value. True indicates that your block wants to have per-instance configuration, while false means it does not. If you do want to implement instance configuration, you will need to take some additional steps apart from overriding this method; refer to the full guide for [[Blocks#Configure_That_Out|more information]].

This method's return value is irrelevant if [[#instance_allow_multiple.28.29|instance_allow_multiple()]] returns true; it is assumed that if you want multiple instances then each instance needs its own configuration.

=== instance_allow_multiple() ===

<syntaxhighlight lang="php">
function instance_allow_multiple() {
// Are you going to allow multiple instances of each block?
// If yes, then it is assumed that the block WILL USE per-instance configuration
return FALSE;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method should return a boolean value, indicating whether you want to allow multiple instances of this block in the same page or not. If you do allow multiple instances, it is assumed that you will also be providing per-instance configuration for the block. Thus, you will need to take some additional steps apart from overriding this method; refer to the full guide for [[Blocks#Configure_That_Out|more information]].

=== instance_config_print() ===

<syntaxhighlight lang="php">
function instance_config_print() {
// Default behavior: print the config_instance.html file
// You don't need to override this if you're satisfied with the above
if (!$this->instance_allow_multiple() && !$this->instance_allow_config()) {
return FALSE;
}
global $CFG, $THEME;

if (is_file($CFG->dirroot .'/blocks/'. $this->name() .'/config_instance.html')) {
print_simple_box_start('center', '', $THEME->cellheading);
include($CFG->dirroot .'/blocks/'. $this->name() .'/config_instance.html');
print_simple_box_end();
} else {
notice(get_string('blockconfigbad'),
str_replace('blockaction=', 'dummy=', qualified_me()));
}
return TRUE;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method allows you to choose how to display the instance configuration screen for your block. Override it if you need something much more complex than the default implementation allows you to do. Keep in mind that whatever you do output from [[#instance_config_print.28.29|config_print()]], it will be enclosed in a HTML form automatically. You only need to provide a way to submit that form.

You should return a boolean value denoting the success or failure of your method's actions.

=== instance_config_save() ===

<syntaxhighlight lang="php">
function instance_config_save($data) {
$data = stripslashes_recursive($data);
$this->config = $data;
return set_field('block_instance', 'configdata', base64_encode(serialize($data)),
'id', $this->instance->id);
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method allows you to override the storage mechanism for your instance configuration data. The received argument is an associative array, with the keys being setting names and the values being setting values.

The configuration must be stored in the "configdata" field of your instance record in the database so that Moodle can auto-load it when your block is constructed. However, you may still want to override this method if you need to take some additional action apart from saving the data. In that case, you really should do what data processing you want and then call parent::instance_config_save($data) with your new $data array. This will keep your block from becoming broken if the default implementation of instance_config_save changes in the future.

Note that $data does not hold all of the submitted POST data because Moodle adds some hidden fields to the form in order to be able to process it. However, before calling this method it strips the hidden fields from the received data and so when this method is called only the "real" configuration data remain.

If you want to update the stored copy of the configuration data at run time (for example to persist some changes you made programmatically), you should not use this method. The correct procedure for that purpose is to call [[#instance_config_commit.28.29|instance_config_commit()]].

You should return a boolean value denoting the success or failure of your method's actions.

{{Moodle 1.9}}
=== preferred_width() ===

<syntaxhighlight lang="php">
function preferred_width() {
// Default case: the block wants to be 180 pixels wide
return 180;
}
</syntaxhighlight>

Available in Moodle 1.5 to Moodle 1.9

This method should return an integer value, which is the number of pixels of width your block wants to take up when displayed. Moodle will try to honor your request, but this is actually up to the implementation of the format of the page your block is being displayed in and therefore no guarantee is given. You might get exactly what you want or any other width the format decides to give you, although obviously an effort to accomodate your block will be made.

Most display logic at this point allocates the maximum width requested by the blocks that are going to be displayed, bounding it both downwards and upwards to avoid having a bad-behaving block break the format.

=== refresh_content() ===

<syntaxhighlight lang="php">
function refresh_content() {
// Nothing special here, depends on content()
$this->content = NULL;
return $this->get_content();
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method should cause your block to recalculate its content immediately. If you follow the guidelines for [[#get_content.28.29|get_content()]], which say to respect the current content value unless it is NULL, then the default implementation will do the job just fine.
You should return the new value of [[#.24this-.3Econtent|$this->content]] after refreshing it.

=== specialization() ===

<syntaxhighlight lang="php">
function specialization() {
// Just to make sure that this method exists.
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method is automatically called by the framework immediately after your instance data (which includes the page type and id and all instance configuration data) is loaded from the database. If there is some action that you need to take as soon as this data becomes available and which cannot be taken earlier, you should override this method.

The instance data will be available in the variables [[#.24this-.3Einstance|$this->instance]] and [[#.24this-.3Econfig|$this->config]].

This method should not return anything at all.

{{Top}}

== Methods which you should ''not'' override but may want to use: ==

=== get_content_type() ===

<syntaxhighlight lang="php">
function get_content_type() {
return $this->content_type;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method returns the value of [[#.24this-.3Econtent_type|$this->content_type]], and is the preferred way of accessing that variable. It is guaranteed to always work, now and forever. Directly accessing the variable is '''not recommended'''<nowiki>; future library changes may break compatibility with code that does so.</nowiki>

=== get_title() ===

<syntaxhighlight lang="php">
function get_title() {
return $this->title;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method returns the value of [[#.24this-.3Etitle|$this->title]], and is the preferred way of accessing that variable. It is guaranteed to always work, now and forever. Directly accessing the variable is '''not recommended'''<nowiki>; future library changes may break compatibility with code that does so.</nowiki>

{{Moodle 1.9}}
=== get_version() ===

<syntaxhighlight lang="php">function get_version() {
return $this->version;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method returns the value of [[#.24this-.3Eversion|$this->version]], and is the preferred way of accessing that variable. Directly accessing the variable is '''not recommended'''<nowiki>; future library changes may break compatibility with code that does so.</nowiki>

{{Moodle 2.0}}
In previous versions of the documentation, this method was noted as being "guaranteed to always work, now and forever." This turned out to not be the case, as [[#.24this-.3Eversion|$this->version]] is no longer present in Moodle 2.0. Instead, you should use a [[version.php]] file as described on the main blocks documentation page.

=== instance_config_commit() ===

<syntaxhighlight lang="php">
function instance_config_commit() {
return set_field('block_instance','configdata', base64_encode(serialize($this->config)), 'id', $this->instance->id);
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method saves the current contents of [[#.24this-.3Econfig|$this->config]] to the database. If you need to make a change to the configuration settings of a block instance at run time (and not through the usual avenue of letting the user change it), just make the changes you want to [[#.24this-.3Econfig|$this->config]] and then call this method.

=== is_empty() ===

For blocks that extend class '''block_base'''<nowiki>:</nowiki>

<syntaxhighlight lang="php">
function is_empty() {
$this->get_content();
return(empty($this->content->text) && empty($this->content->footer));
}
</syntaxhighlight>

Available in Moodle 1.5 and later

For blocks that extend class '''block_list'''<nowiki>:</nowiki>

<syntaxhighlight lang="php">
function is_empty() {
$this->get_content();
return (empty($this->content->items) && empty($this->content->footer));
}
</syntaxhighlight>

This method returns the a boolean true/false value, depending on whether the block has any content at all to display. Blocks without content are not displayed by the framework.

=== name() ===

<syntaxhighlight lang="php">
function name() {
static $myname;
if ($myname === NULL) {
$myname = strtolower(get_class($this));
$myname = substr($myname, strpos($myname, '_') + 1);
}
return $myname;
}
</syntaxhighlight>

Available in Moodle 1.5 and later

This method returns the internal name of your block inside Moodle, without the '''block_''' prefix. Obtaining the name of a block object is sometimes useful because it can be used to write code that is agnostic to the actual block's name (and thus more generic and reusable). For an example of this technique, see the [[#config_print|config_print()]] method.

{{Top}}

== Methods which you should ''not'' override and ''not'' use at all: ==

=== _add_edit_controls() ===
This is a private method; no description is given.

=== _load_instance() ===
This is a private method; no description is given.

=== _print_block() ===
This is a private method; no description is given.

=== _print_shadow() ===
This is a private method; no description is given.

=== _self_test() ===
This is a private method; no description is given.

The class '''block_base''' also has a few standard member variables which its methods manipulate. These variables, the purpose of each and the type of data they are expected to hold is explained in the next section of this Appendix.

{{Top}}

== Class variables: ==

=== $this->config ===

This variable holds all the specialized instance configuration data that have been provided for this specific block instance (object). It is an object of type stdClass, with member variables directly corresponding to the HTML <input> elements in the block's config_instance.html file.

The variable is initialized just after the block object is constructed, immediately before [[#specialization|specialization()]] is called for the object. It is possible that the block has no instance configuration, in which case the variable will be NULL.

It is obvious that there is a direct relationship between this variable and the configdata field in the mdl_block_instance table. However, it is ''strongly'' advised that you refrain from accessing the configdata field yourself. If you absolutely must update its value at any time, it is recommended that you call the method [[#instance_config_commit|instance_config_commit()]] to do the actual work.

=== $this->content ===

This variable holds all the actual content that is displayed inside each block. Valid values for it are either NULL or an object of class stdClass, which must have specific member variables set as explained below. Normally, it begins life with a value of NULL and it becomes fully constructed (i.e., an object) when [[#get_content|get_content()]] is called.

After it is fully constructed, this object is expected to have certain properties, depending on the value of [[#.24this-.3Econtent_type|$this->content_type]].

Specifically:

* If [[#.24this-.3Econtent_type|$this->content_type]] is [[#BLOCK_TYPE_TEXT|BLOCK_TYPE_TEXT]], then [[#.24this-.3Econtent|$this->content]] is expected to have the following member variables:

# '''text''' This is a string of arbitrary length and content. It is displayed inside the main area of the block, and can contain HTML.
# '''footer''' This is a string of arbitrary length and contents. It is displayed below the text, using a smaller font size. It can also contain HTML.

* If [[#.24this-.3Econtent_type|$this->content_type]] is [[#BLOCK_TYPE_LIST|BLOCK_TYPE_LIST]], or if your block derives from '''block_list''', then [[#.24this-.3Econtent|$this->content]] is expected to have the following member variables:

# '''items''' This is a numerically indexed array of strings which holds the title for each item in the list that will be displayed in the block's area. Since usually such lists function like menus, the title for each item is normally a fully qualified HTML <a> tag.
# '''icons''' This is a numerically indexed array of strings which represent the images displayed before each item of the list. It therefore follows that it should have the exact number of elements as the items member variable. Each item in this array should be a fully qualified HTML <img> tag.
# '''footer''' This is a string of arbitrary length and contents. It is displayed below the text, using a smaller font size. It can also contain HTML.
{{Moodle 2.0}}
* As of Moodle 2.0, if [[#.24this-.3Econtent_type|$this->content_type]] is [[#BLOCK_TYPE_TREE|BLOCK_TYPE_TREE]], or if your block derives from '''block_tree''', then [[#.24this-.3Econtent|$this->content]] is expected to have the following member variables:

# '''items''' This is an array of '''tree_item''' objects, representing the top level of the tree to be displayed. Each tree_item::children property may contain more tree_item objects for the next level down, which in turn contain more tree_item objects, and so on. Note that the tree block type has no footer.

If you set ''all'' of these variables to their default "empty" values (empty arrays for the arrays and empty strings for the strings), the block will '''not''' be displayed at all except to editing users. This is a good way of having your block hide itself to unclutter the screen if there is no reason to have it displayed.

Before starting to populate [[#.24this-.3Econtent|$this->content]], you should also include a simple caching check. If [[#.24this-.3Econtent|$this->content]] is exactly equal to NULL then proceed as normally, while if it is not, return the existing value instead of calculating it once more. If you fail to do this, Moodle will suffer a performance hit.

=== $this->content_type ===

This variable instructs Moodle on what type of content it should assume the block has, and is used to differentiate text blocks from list or tree blocks. It is essential that it has a meaningful value, as Moodle depends on this for correctly displaying the block on screen. Consequently, this variable is closely tied with the variable [[#.24this-.3Econtent|$this->content]]. The variable is expected to have a valid value after the framework calls the [[#init|init()]] method for each block.

Prior to Moodle 2.0, the only valid values for this variable are the two named constants [[#BLOCK_TYPE_TEXT|BLOCK_TYPE_TEXT]] and [[#BLOCK_TYPE_LIST|BLOCK_TYPE_LIST]]. Moodle 2.0 adds a third content type, [[#BLOCK_TYPE_TREE|BLOCK_TYPE_TREE]].

{{Moodle 2.0}}
=== $this->context ===

As of Moodle 2.0, every block now has its own context, and you can always access it via $this->context. However when checking permissions you need to decide which of two contexts is more appropriate:

# The block context ($this->context)
# The page context the block is appearing on ($this->page->context). For sticky blocks, this may be a more appropriate choice.

For example, when deciding whether the user can edit the block settings, or see the block, you should use the block context. When deciding whether the user can do something relating to the context where the block appears (can the user see participants here) you should probably use the page context.

{{Moodle 1.9}}
=== $this->instance ===

This member variable holds all the specific information that differentiates one block instance (i.e., the PHP object that embodies it) from another. It is an object of type stdClass retrieved by calling get_record on the table mdl_block_instance. Its member variables, then, directly correspond to the fields of that table. It is initialized immediately after the block object itself is constructed.

This field no longer exists in Moodle 2.0. You should use the [[#.24this-.3Epage|$this->page]] variable instead.

{{Moodle 2.0}}
=== $this->page ===

As of Moodle 2.0, very block now has access to the page it appears on, via $this->page. (Therefore, you do not have to use the global $PAGE object in blocks!)

For upgraders, any code that previously relied on $this->instance->... will probably break. Information about the page the block is appearing on is available from $this->page->.... Specifically:
* $this->instance->pagetype should be changed to $this->page->pagetype
* $this->instance->pageid - there is no longer a concept of page id. Instead, you are probably looking for $this->page->course, $this->page->cm or $this->page->activityrecord.

=== $this->title ===

This variable is a string that contains the human-readable name of the block. It is used to refer to blocks of that type throughout Moodle, for example in the administrator's block configuration screen and in the editing teacher's add block menu. It is also the title that is printed when the block is displayed on screen, although blocks can specifically change this title to something else if they wish (see below). The variable is expected to have a valid value after the framework calls the [[#init|init()]] method for each object.

In the case of blocks which may want to configure their title dynamically through instance configuration, it is still essential to provide a valid title inside [[#init|init()]]. This title may then be overridden when the [[#specialization|specialization()]] method is called by the framework:

<syntaxhighlight lang="php">
function specialization() {
// At this point, $this->instance and $this->config are available
// for use. We can now change the title to whatever we want.
$this->title = $this->config->variable_holding_the_title;
}
</syntaxhighlight>

A lot of blocks seem to use

<syntaxhighlight lang="php">
$this->title = get_string('blockname', ... );
</syntaxhighlight>

to set the title of the block (and then put a more specific title inside the language file).

If there is no proper language string, the title of the block will then be set to ''blockname''. If there is another block with the same generic title, then an error will show up: Naming conflict.

To avoid this error on installations with missing language strings, use a more specific name when calling the language string...

<syntaxhighlight lang="php">
$this->title = get_string('simplehtml', ... );
</syntaxhighlight>

That way all blocks will show up with a unique title in the admin area, even if people have not yet succeeded in placing language files in the correct location

{{Moodle 1.9}}
=== $this->version ===

This variable should hold each block's version number in the form '''YYYYMMDDXX''', as per the convention throughout Moodle. The version number is used by Moodle to detect when a block has been upgraded and it consequently needs to run the block's upgrade code to bring the "old" version of the block's data up to date. The variable is expected to have a valid value after the framework calls the [[#init|init()]] method for each block.

Most blocks do not keep complex data of their own in the database the way that modules do, so in most cases nothing actually happens during a block version upgrade. However, the version number is displayed in the administration interface for blocks. It is good practice therefore to change your block's version number when it gains new functionality or receives important bug fixes, to enable site administrators to easily identify the exact version of the block they are working with.

{{Moodle 2.0}}
$this->version is no longer present in Moodle 2.0. Instead, you should use a version.php file as described on the main blocks documentation page.

{{Top}}

== Named constants: ==

Appearing throughout the code related to the Blocks API, there are a number of predefined constants that are utilized to avoid the use of "magic numbers" in the code. These constants are:

=== BLOCK_TYPE_LIST ===

This is one of the valid values for the [[#.24this-.3Econtent_type|$this->content_type]] member variable of every block. Its value specifies the exact requirements that Moodle will then have for [[#.24this-.3Econtent|$this->content]].

=== BLOCK_TYPE_TEXT ===
This is one of the valid values for the [[#.24this-.3Econtent_type|$this->content_type]] member variable of every block. Its value specifies the exact requirements that Moodle will then have for [[#.24this-.3Econtent|$this->content]].

{{Moodle 2.0}}
=== BLOCK_TYPE_TREE ===

Introduced in Moodle 2.0, this is one of the valid values for the [[#.24this-.3Econtent_type|$this->content_type]] member variable of every block. Its value specifies the exact requirements that Moodle will then have for [[#.24this-.3Econtent|$this->content]].

== Extended block types ==

Several additional classes are defined in the block library that extend block_base. These are basically shorthand ways of creating blocks with list or tree content types, rather than instantiating a block_base object and setting values on it. The '''block_list''' class can be used to create list-based blocks as described above, and as of Moodle 2.0, the '''block_tree''' class will allow you to create tree-structured blocks easily. If you are using one of these blocks, you will not need to set $this->content_type as described above.

[[Category:Blocks]]
[[Category:Tutorial]]

[[es:Desarrollo de bloques]]
[[ja:開発:ブロック/付録A]]
[[ru:Blocks/Appendix_A]]

BioAuth Plugin

2025-02-10T07:48:41Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Work_in_progress}}
{{Infobox Project
|name = BioAuth: A Moodle plugin for determining Quiz authorship
|state = Community bonding period
|tracker = CONTRIB-4337
|discussion = XXX
|assignee = [https://moodle.org/user/profile.php?id=1595676 Vinnie Monaco]
}}

GSOC
 '13


==Introduction==

The purpose of the BioAuth plugin is to provide a mechanism for verifying a user's identity based on behavioral biometrics. This is accomplished by capturing keystrokes from a user and matching it against a known template for that user. The initial release of BioAuth will only support biometric authentication for essay-type questions on quizzes. Other sources of keystrokes may be added in future releases.

==Installation==

First, install the BioAuth local plugin. This contains everything needed to authenticate students but is not able to collect any data. Then install the quiz access rule BioLogger plugin. This allows keystroke timing information to be captured on client computers during quiz attempts.

===Requirements===

The BioAuth plugin requires a Moodle installation with a MySQL backend and java (>1.5) installed on the server.

===Instructions===

TODO: local_bioauth installation instructions

TODO: quiz_accessrule installation instructions

==Usage==

The BioAuth and BioLogger plugins must both be installed for the BioAuth plugin to work properly.

Once the plugin is installed, it can be enabled for existing courses through the report page. It will automatically be enabled for newly created courses.

Important: The course must contain at least one quiz with one essay question. The plugin can only log keystrokes from essay questions which use the rich html editor.

==Background==

The raw data is processed in several stages in order to make an authentication decision, and either confirm or deny the identity of an individual:

'''Feature extraction → Fallback Procedure → Outlier Removal → Normalization → Classification'''

A '''session''' is the duration in which some data is continuously captured from a user. This could be a quiz or some activity on a forum. A user may have multiple sessions capture while they are logged in. Sessions should capture data from an independent activity or task which lasts anywhere from roughly 10 to 60 minutes depending on the task involved.

A '''keystroke event''' is the atomic event captured by the hardware keyboard of a desktop or laptop computer. It consists of a press time, release time, and key identity. The key is identified by it's location on the keyboard, not the ASCII code of the letter which was actually printed on screen. For example, 'A' is the same as 'a,' even though they have different ASCII codes, and left shift is not the same as right shift, even though they have the same ASCII codes. The identity of the key can usually be determined by the key code, which should be unique for every key on the keyboard. Care must be taken to correlate key codes across different browsers and operating systems, as they may be platform dependent. For more information on events and keycodes, see [http://www.quirksmode.org/js/keys.html Quirksmode on JavaScript keys].

A '''stylometry event''' is a portion of text that was emitted to the screen in a continuous manner. Stylometry events are separated by a change in focus or cursor position. Events that segment consecutive stylometry events (ending the current stylometry event and beginning a new one) include:

* Changing the window focus
* Clicking on a different area of text in the current entry
* Using the arrow keys to navigate a text area
* Moving to a different text area.

Using the delete key to modify text which was already printed on screen does not end the current stylometry event, although it does modify the text which is contained in the current stylometry event. Upon completion of a subtask, the sequence of stylometry events will roughly consist of the final text that the user actually typed and appeared on screen.

===Feature Extraction===

A "keystroke feature" is a measurement made on the time differences between the press and release events of keystrokes. The most commonly used keystroke features are means and standard deviations of key duration and transition times.

During feature extraction, the raw data (keystroke, stylometry) is mapped to a feature space. Features usually consist of measurements on some distribution in the raw data. The hold time is the duration a key is held, or press time – release time. There are several types of transition times, the most common being release-press and press-press latencies. For example, take two consecutive keystrokes, [A,B]. The hold time of A would be (A_release - A_press)
and the transition times, (B_press – A_release), (B_press – A_press).

The hold times of A form a distribution from which the mean and standard deviation may be taken. Similarly for the transition times between A and B, assuming that the sequence [A,B] occurs with a high enough frequency in the sample provided. For missing data, a fallback procedure is used, described in the next section.

===Fallback Procedure===

Dealing with arbitrary can lead to missing observations. To compensate for this, a fallback procedure is used to compensate for missing data. Missing features may be computed from observations which are known to be correlated with the missing data.

It is known that the timing information for closely grouped keys correlate well enough to used them in an instance of missing data. For this reason, a fallback hierarchy based on the physiology of the touch-typist is used.

===Outlier Removal===

Due to inconsistencies in the data provided, outliers must be removed. It is common for a user to take a break while typing, creating a large transition time between keystrokes. These can easily be removed by excluding observations which fall outside the mean observation, usually +/- 2 standard deviations.

===Normalization===

Features are normalized so that each feature is weighted equally in the KNN classification. The normalization clamps each feature between 0 and 1.

===Classification===

The feature space is first transformed into a feature difference space by taking the differences between every combination of feature vectors. The differences make up two classes: differences within a user and differences between users. The unknown sample (query) is compared to the feature vectors of it's claimed identity. Differences between the query vector and the user's template are taken. These differences are then classified as either within user or between user by comparing them to the vectors that make up the difference space. A KNN algorithm is used to classify the unknown sample by looking at the closest neighbors, which came from either the same user or different users.

==Settings==

===Mode===

Currently, the plugin can either be Enabled or Disabled. Setting the mode to Enabled will activate biometric authentication for any new courses which are created. The plugin can be enabled for existing courses through the overview report page.

===Weeks keep active===

The number of weeks to keep a course active, after the plugin has been enabled. During this time, the plugin will continuously look for new data and re-authenticate students. The results are updated as new data is collected.

===Min keystrokes per quiz===

The desired number of keystrokes per quiz. This setting will only affect the time at which the plugin has determined enough data has been collected to begin authenticating students. See Percent data needed.

===Percent data needed===

How much data is needed before authentications should begin to take place. This only affects the initial results, which are continuously updated as new data is collected. The default setting is 50%, which would be 50% of the total data needed (students X quizzes X keystrokes-per-quiz)

===Max concurrent jobs===

The number of jobs which may be run simultaneously during a cron job.

===Cache key codes===

Use cache for looking up the keycodes when enrolling new data. This works very similarly to the language cache used in the string api.

===Knn===

The model parameter K, where K is the number of neighbors to use when making an authentication decision.

===Min key frequency===

The minimum number of keystroke occurrences before a fallback procedure is used. The fallback procedure is defined in the features file.

===Decision mode===

How the classifier should behave when making an authentication decision. In reality, there will always be at least a small error in the accuracy of the classifier. This setting will determine whether a false acceptance or false rejection should be weighted more heavily. A more secure system would reduce the number of false acceptances at the cost of increasing the number of false rejections. The tradeoff can be seen on the ROC curve in the quiz report.

===Feature set===

Which feature set to use. The features are defined in the feature files and loaded during installation.

==Report==

===Overview===

The overview report gives a summary of each course. The plugin can be enabled or disabled for any particular course by clicking the appropriate action button.

===Quiz===

The quiz report displays the authentication results for every student in the course. In each cell, a student can either be authenticated or rejected. A '-' will appear in cells where enough data has not been collected to make a decision.

The graph at the top of the page displays the tradeoff between the false acceptance and false rejection rate. This is the receiver operating characteristic (ROC) curve. It can be used to determine the overall performance of the classifier for the given population of students.

==Multi-language support==
The BioAuth plugin was designed to be easily extensible to other languages and locales. This can be done by defining the physical keys which may be pressed on the keyboard and creating the keystroke features. Defining the keys themselves is straightforward and only requires a mapping of the different agent/locale key codes to the name of the key. Creating the keystroke features requires some knowledge of the target language and application in order to create features which may easily identify an individual. Usually, keys which occur with a high frequency are good to use as features as are transitions between commonly-occuring keys.

===Keys===

Keycodes for various languages are defined in the keys/[language]/keycode.php file. The system will detect the current language and use the appropriate keycode file to translate the keycodes. This is needed because the keycodes vary across different browser agents and platforms. The different codes must all be mapped to the physical key that they were generated by.

===Features===

Features are defined in the features/ folder. Feature sets are not tied to any particular language because the same feature set may be used for multiple languages or there may be several feature sets for one language. The installation comes with a feature set designed for standard QWERTY keyboards and uses a touch-type hierarchy fallback procedure.

==Schedule==

The work will be completed under the following schedule:

{| class="wikitable"
|-
! Dates
! Task
! Status
|-
| May 27 - June 17
| Draft of design, to be accomplished during Community Bonding Period.
Also, deadline for submitting a paper to MRC2013.
| Complete
|-
| June 17 - July 1
| Binary classifier and authentication decision functions
| Complete
|-
| July 1 - July 15
| Key logger
DB model
| Complete
|-
| July 15 - August 1
| Keystroke Feature extractor
| Complete
|-
| August 1 -August 11
| UI for results and settings
| Complete
|-
| August 15- Sept. 1
| Beta testing with trusted volunteers.
Bug fixes and final report.
| Complete
|-
| Sept. 1 - Sept. 23
| Prepare for release.
Scrub code, tests, documentation.
Live testing during Fall 2013 academic semester
| Complete
|}

== See also ==
* [[GSOC/2013|Moodle GSoC projects for 2013]]
* [[GSOC|Moodle GSoC Overview page]]

[[Category:GSOC]]
[[Category:Project]]

Better handling of overdue quiz attempts

2025-02-10T07:48:17Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Handling of overdue quiz attempts
|state = Implementation complete. Testing.
|tracker = MDL-3030, MDL-4309
|discussion = [http://moodle.org/mod/forum/discuss.php?d=201355 Quiz forum thread about testing] [http://moodle.org/mod/forum/discuss.php?d=188534 Old Quiz forum thread about the proposal]
|assignee = [[User:Tim Hunt|Tim Hunt]]
}}
{{Moodle 2.3}}

There is a tricky issue to do with what happens exactly when time runs on on a quiz. On the one hand, we want to let students use every second of time. On the other hand, the end of a quiz is often a time of high server load, and so Moodle is likely to responding slowly. Therefore, we have to prevent students from cheating on the time-limit while still processing their last-minute submission even if the server is heavily loaded.

There is also the problem of what happens if the student just logs out and does not submit at all. At the moment the attempt goes into a sort of limbo where Moodle can't really do anything with it.

==What happens at the moment==

Currently there are only really two states a quiz attempt can be in, and they are distinguished by whether quiz_attempts.timefinish is 0 or contains a time-stamp.

[[Image:Quiz_attempt_states_now.png]]

At most one attempt is allowed to be in the '''In progress''' state at any time.

After time expires, (either because the time limit runs out, or the close date passes) the attempt is in a weird state. Well, not really, the attempt is still considered to be '''In progress''', but the student is no longer allowed to access it, so there is no way to get at the '''Submit all and finish''' button to submit it. Also, if the quiz allows more than one attempt, the student cannot start a new attempt, because they already have an '''In progress''' attempt (which they are not allowed to access!)

The known work-around is, as teacher, to:
# edit quiz settings to allow more time;
# login-as the student and submit the quiz;
# set the time-limit or close data back to what it should be.
This is a real pain.

Before reading on, you may wish to remind yourself of the [[Quiz user interface overview]], so you know what the key scripts view/startattempt/attempt/processattempt/summar/review.php each do.

To document the two existing transitions in some detail (note, all transitions are logged, I have not bothered to say that every time):

===Transition: Start attempt===

Goes to: In progress

Allowed when: If the student does not currently have any '''In progress''' attempt, and if they meet all the conditions imposed by the [[Quiz access rules|access rules]], they may start one.

How it is done: The student clicks the '''Start attempt''' button on view.php. Technically, this takes the form of a POST request to startattempt.php.

What happens:
# The attempt, and corresponding $quba, are created.
# They are initialised by adding all the questions, which may depend on randomisation, and 'each attempt builds on last'.
# The attempt and all associated data is written to the database.
# A quiz_attempt_started event is raised. (This even it not used in standard Moodle.)

===Transition: Submit all and finish===

Goes from: In progress

Goes to: Finished

Allowed when: The student has an '''In progress''' attempt, which they are currently allowed to access according to the access rules. In particular, where the time limit has not run out, and the close date has not passed.

How it is done: Either
* The student clicks the '''Submit all and finish''' button on summary.php; or
* Time runs out while the student is working on the quiz, and so the quiz is submitted automatically (if JavaScript is enabled).
Technically, this takes the form of a POST request to processattempt.php, althought the code that does the work is the quiz_attempt::process_attempt method in attemptlib.php.

What happens:
# All questions that are not already finishes are finished.
# The updated question states are written to the database.
# The quiz_attempt record is updated with the timefinish and the total mark.
# The overall quiz grade (combining all the student's attempt scores) is updated, and stored in the gradebook.
# A quiz_attempt_submitted event is raised. (This is used by the quiz itself to send out any tutor or student notification messages that are enabled.)

==Rough outline of the solution==

We will introduce a new quiz settings '''When time expires''' and '''Grace period'''. When time expires is the strategy we will use for overdue attempts. For some strategies, they will need an amount of extra time that is the grace period. The possible strategies are:

# Submit attempt automatically,
# Allow a grace period to submit, but not change any responses, or
# That's it. Tough luck! - ''we need a better name for this!''

1. Corresponds to doing an automatic submit all and finish. 3. Corresponds to automatically moving the attempt to the '''Abandoned state'''. See below. 2. is more interesting (and is what the OU wants for assessed tests).

If the student has not submitted their attempt when time runs out, then the attempt moves into the '''Overdue''' state. In this state, when the student tries to get to the quiz attempt, then can only go to the Summary page, where all they can do is to click the '''Submit all and finish''' button.

If they finish submitted before the grace period runs out, then their attempt is counted.

If the student still does not submit, then the attempt moves into the '''Abandoned''' state. This means that the student is not prevented from starting a new attempt, if the quiz allows it.

''Question: should we allow the student to abandon the current attempt at any time? For example, if an interactive quiz allows multiple attempts, and the student has got off to a bad start, should we let them abandon and start again, or should we force them to '''Submit all and finish''' if they want a new attempt? - for now we will not allow students to abandon any attempt.''

In addition, we will start storing the quiz_attempt.state explicitly in the database, rather than relying on deducing it from timefinish or other columns. In a sense this is redundant information, but since significant things happen when the state changes (e.g. a message might be sent) I think making the state, and hence the state transition, explicit, will make the code clearer.

We will need code that detects when an attempt is in the 'wrong' state. For example, if a state is stored in the database as '''In progress''', but time has now expired, then we will need to detect that and correct it by triggering the correct state transition. I think we need to do this in two ways:
# Whenever we load an attempt from the database. This ensure that if the user is actively working on the quiz when a state transition is supposed to happen, they will immediately see the attempt change state.
# We will need to add a cron script that detects attempts becoming overdue when no-one is looking at them.
(Note there is a subtlety, the JavaScript timer that runs in the user's browser will try to automatically trigger a submit, they may be happening at the same time as a teacher is reviewing the attempt (which might trigger 1) and cron may also be running at the same time (which might trigger 2). Therefore, we need a clear protocol to avoid nasty race-conditions.

Actually, a possible third way (instead of, or in addition to cron). Perhaps we should detect this when the quiz settings (or overrides) are edited, and check all attempts then and trigger state transitions. This might be a performance problem on quizzes with thousands of attempts.

==New state diagram==

[[Image:Quiz_attempt_states.png]]

At most one attempt can be in either the '''In progress''' or '''Overdue''' states at any time.

The existing transitions need to be updated:
* They all need to set the new quiz_attempt.state column as part of What happens.
* The transition Submit all and finish can now also go from '''Overdue''' to '''Finished'''.
* When time runs out as a student is working on their quiz attempt, this should no longer trigger an automatic Submit all and finish. Instead it should trigger an automatic Time expires.

The new transitions are:

===Transition: Time expires===

Goes from: In progress

Goes to: Overdue

Allowed when: Time expires, either due to the time-limit, the close date, or some other custom access rule; or because the teacher has edited the time limit and/or close date and shortened them; and when the overdue strategy is "Allow a grace period to submit, but not change any responses".

How it is done: Detected automatically by the Moodle code, either because
* time has passed;
* the teacher has edited the quiz settings or overrides to shorten the time limit and/or close date; or
* triggered by the countdown timer JavaScript, in which case this will trigger a POST to processattempt.php.

What happens:
# quiz_attempt.state is updated
# quiz_attempt_overdue event is raised. (The quiz will use this itself to send a warning message to the student, if that is enabled.)
# If the student is currently working on the quiz, they are redirected to the summary.php page.

===Transition: Give up===

''(not sure that is the best name)''

Goes from: Overdue / In progress

Goes to: Abandoned

Allowed when: Time expires, and the overdue strategy is "That's it. Tough luck!"; or the grace period expires when an attempt is in the '''Overdue''' state.

How it is done: Detected automatically by the Moodle code, either because
* time has passed;
* the teacher has edited the quiz settings or overrides to shorten the time limit, close date and/or grace period; or
* triggered by the countdown timer JavaScript, in which case this will trigger a POST to processattempt.php; or
* if we decide to allow it, the student clicks a 'Give up button', perhaps on the summary page.

What happens:
# quiz_attempt.state is updated
# quiz_attempt_abandoned event is raised. (For completeness. I don't foresee a use for this at the moment.)

===Transition: Time limit extended===

''This shows the kind of tricky thing that can happen. We have to consider what happens if the teacher edits the quiz settings to extend the time limit when an attempt has already been marked overdue.''

Goes from: Overdue

Goes to: In progress

Allowed when: The teacher edits the quiz settings or the overrides and extends the time limit.

How it is done: Detected automatically by the Moodle code.

What happens:
# quiz_attempt.state is updated
# quiz_attempt_restarted event is raised. (For completeness. I don't foresee a use for this at the moment.)

==What can be accessed when==

For an '''In progress'''' attempt: The student can access attempt.php and summary.php; the teacher can access review.php.

For an '''Overdue'''' attempt: The student can access review.php and summary.php; the teacher can access review.php.

For a '''Finished'''' attempt: The student and teacher can access review.php.

For an '''Abandoned'''' attempt: The student and teacher can access review.php.

==Summary of changes==

===Database changes===

* New column quiz.overduehandling (char) to store which strategy we will use for overdue attempts.
* New column quiz.graceperiod (int) to store the time an attempt is allowed to remain in the '''Overdue''' state.
* New column quiz_attempt.state (char) to explicitly store the attempt state.

===New capability===

* mod/quiz:emailwarnoverdue to control overdue warning messages.

===UI changes===

* New fields 'When time expires' and 'Grace period' on the quiz settings form, with corresponding admin settings.
* Do we need even more columns of 'review options' on the quiz settings form? (For example for '''Overdue''' and '''Abandoned''' attempts.) Perhaps it is time to move these settings to a separate page?
* Information about the grace period may need to be displayed on the quiz settings page, or on the summary page for overdue attempts.
* List of attempts on the view.php page needs to indicate the state of attempts.
* review.php page needs to indicate the attempt state.
* Display attempt state in the quiz reports where appropriate.

==Rough work break-down==

# Done! New quiz.overduehandling, quiz.graceperiod and quiz_attempt.state DB columns definition, upgrade code, backup & restore.
# Done! Overdue handling and Grace period setting on quiz form, with any validation. Verify create / edit works.
# Done! Implement back end of the three new transitions.
# Done! Code where attempts are loaded to identify attempts in the wrong state and trigger a transition if necessary.
# Done! Catch the quiz_attempt_overdue event and send an email.
# Done! Make attempt_state clear on the view page list of past attempts.
# Done! Update logic for the 'Start attempt button', and in startattempt.php so that for overdue attempts users are redirected to the summary page.
# Done! Update summary page to display appropriate information about overdue attempts.
# Done! Update processattempts.php so that it correctly handles one single submission after an attempt becomes overdue, and, for overdue attempts, will only redirect to the summary page.
# Done! Display the attempt state on the review page.
# Done! Add the attempt state to the overview and responses quiz reports (this will actually be a change in the base class).
# Done! Add new options to the attempt and overview reports to filter the report by attempt state. (We can probably usefully refactor the settings forms and preferences handling to extract a base class.)
# Out of scope While we are working here, we should really update these two reports to use the Moodle 2.x enrolment SQL, instead of get_users_by_capability.
# Done! Change the statistics report to analyse attempts with state = finished, rather than timefinish <> 0.
# Done! Cron to detect attempts in the wrong state and trigger state transitions.
# Done! Review all remaining occurrences of ->timefinish in the quiz code.
# Done! Check the quiz results block - no changes required.
# Out of scope - the official work-around is: "Don't do that", at least for now - Deal with what happens when the teacher edits the quiz settings - which might change the times or the policies. Work out what to update.

== Test script==

The 3 examples at http://moodle.org/mod/forum/discuss.php?d=188534 are a good starting point. They just need to be elaborated.

==Hypothetical other transitions==

The following state-transitions can also be conceived, and could be implemented in the future, but they are out-of-scope for this proposal.

===Transition: Reopen attempt===

Goes from: Finished / Abandoned

Goes to: In progress

Allowed when: Time has not expired, and the current user has the appropriate capability.

(For example, the student accidentally clicked Submit all and finish, and the teacher wants to be nice and undo that for them. Alternatively an attempt has become Abandoned because time ran out, but then the teacher extended the grace period or time limit, and so wants to re-open some attempts. In this case, the transition may go to '''Overdue''', or perhaps that is a different transition, or perhaps the right way to handle that is to first transition to '''In progress''' and then transition to '''Overdue'''. I think it is clear why this is being considered out-of-scope.)

How it is done: Probably clicking a button on the review page or in the quiz reports. This would probably be a POST to a new reopenattempt.php

What happens: This is a bit tricky because lots of complex stuff happens on Submit all and finish that now needs to be undone, but I think a possible approach is to delete any question_attempts_steps added by the finish action (and any that follow them) and then use a regrade of the attempt to reset everything else.

Actually, it is much easier to re-open an '''Abandoned''' attempt than a '''Finished''' one. Perhaps we should consider them two different transitions, or perhaps reopening an '''Abandoned''' attempt can be treated the same as Time limit extended.

===Transition: Count this anyway===

Goes from: Abandoned

Goes to: Submitted

Allowed when: The current user has the appropriate capability.

(For example a teacher decides that even though the student abandoned their attempt, it should be counted anyway.)

How it is done: Probably clicking a button on the review page or in the quiz reports. This would probably be a POST either to processattempt.php with extra arguments, or to a new script.

What happens: Probably very similar to Submit all and finish.

==See also==

* MDL-3030 Late quiz attempts should be closed automatically
* MDL-4309 Ability for late quizzes (with penalty)
* MDL-35322 Student didn't submit quiz, status is Never Submitted, version 2.3.1
* [[Quiz]] developer documentation
* Draft user documentation: [[Quiz time controls on attempts]]

Better Office Integrations 3.3

2025-02-10T07:47:54Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Better Office Integrations
|state = Complete
|tracker = https://tracker.moodle.org/browse/MDL-57794
|discussion = https://moodle.org/mod/forum/discuss.php?d=346085
|assignee = HQ Projects Team
}}

= Project - Better Office Integrations - Moodle 3.3 =

== Overview ==

This document lists the minimum set of standard features that should be common to a premium standard office integration with Moodle. This document is not focussed on any particular office system. It’s likely that G-Suite and Office365 are the initial targets, but other systems could also be implemented in the same way in future.

== Requirements ==

=== Site config ===

==== REQ 1 ====
Users affected: Admins

The problem: The integration involves many plugins and there needs to be a single place to disable/enable it.

The proposed solution: Single admin setting to completely enable / disable all plugins for this integration.

Criteria for success:
# Admin can enable / disable the integration with a single setting.

Status: Completed for Moodle 3.3

=== Authentication ===

==== REQ 2 ====
Users affected: All

The problem: If my Moodle site allows authentication with oauth - I should have all the possible OAuth providers displayed in priority order on the login page.

The proposed solution: Extend auth plugins API to support “oauth” authentication. Display the list of enabled OAuth plugins on the login page (in priority order).

Criteria for success:
# I see a list of “Login with XXX” options on the Moodle login page in priority order with icons and colors from the OAuth provider.
# Choosing an OAuth provider from the login page should open the external OAuth page in an popup window. When the OAuth is completed the popup window should close and the login page should reload and now be authenticated.
# If there is no matching Moodle account for the OAuth account - a new Moodle account should be created automatically and the OAuth account should be added to the list of connected OAuth accounts for this Moodle account.
# If manual authentication is disabled I should not see a username and password field on the login page. (Update - manual authentication cannot be disabled).

Status: Completed for Moodle 3.3

==== REQ 3 ====
Users affected: Administrators

The problem: I want to allow users to login with their office accounts - but only if they come from the correct institution.

The proposed solution: Admin configuration settings to control the list of accounts allowed to login via OAuth (e.g. regex on username)

Criteria for success:
# Users can login to Moodle using an office suite account - only if it belongs to the correct institution.

Status: Completed for Moodle 3.3

==== REQ 4 ====
Users affected: All

The problem: I do not want multiple different accounts to connect to different applications provided by my institution.

The proposed solution: Moodle authentication plugin supporting single sign on (OAuth).

Criteria for success:
# I can login to Moodle using my office account.
# If my account does not exist in Moodle it is automatically created.
# I have only one place to manage my account password.
# If I am logged into Moodle I can access my office applications without re-authenticating.
# If I am logged into my office applications I can access Moodle without re-authenticating.

Status: Completed for Moodle 3.3

==== REQ 5 ====
Users affected: All

The problem: I want to access documents in my personal office account, while logged into Moodle with my university login

The proposed solution: Core api in Moodle for managing a list of oauth connected accounts and current sessions.

Criteria for success:
# I can login to Moodle using my university account (any existing auth method)
# When I access a resource from the office suite, I am prompted to login with a choice of my linked OAuth accounts (unless I already have a valid session).
# After logging in I can browse and search from the files connected to the chosen OAuth account.
# I can choose at any time to switch to a different connected OAuth account without ending my Moodle session.
# From the front page, I can login directly using an office account

Status: Completed for Moodle 3.3

==== REQ 6 ====
Users affected: All

The problem: I want manage the list of OAuth accounts connected to my Moodle account

The proposed solution: Preferences page for managing the list of connected OAuth accounts

Criteria for success:
# I can see on my preferences page a list of connected OAuth accounts and can add and remove them.
# I can add a new connected OAuth account for any of the enabled OAuth Authentication plugins.
# I can login to Moodle using any of my connected accounts from the login page.
# I can prevent Moodle from creating accounts when someone logs with an oauth account and no matching user is found

Status: Completed for Moodle 3.3

=== Calendar ===

==== REQ 7 ====
Users affected: Students, teachers

The problem: Calendar information is difficult to access if it is not aggregated in a single place.

The proposed solution: Automatically export the information from the Moodle calendar to the external calendar.

The criteria for success:
# My external calendar application automatically reflects the information on my Moodle calendar.
# I should be able to quickly hide / show all the Moodle events in my external calendar.
# If I cannot easily hide the events in my external calendar, I should be able to easily prevent Moodle from publishing events to it.

Update - This requirement is not possible to fulfill with the existing apis from Google and Microsoft.

=== Files ===

==== REQ 8 ====
Users affected: Students, teachers

The problem: Users should be able to create files in the office applications and then use the files in Moodle.

The proposed solution: Add a repository plugin to Moodle that supports browsing of files in the office application.

The criteria for success:
# Any user can upload any office document they have access to wherever Moodle allows a file to be uploaded.
# They should be able to search or browse the documents in the office system.
# Once a document has been linked to Moodle. The access restrictions should rely on Moodles systems for capabilities roles etc (If I can see the link in Moodle I should be able to access the document).

Status: Completed for Moodle 3.3

==== REQ 9 ====
Users affected: Students, teachers

The problem: I should be able to upload and create documents in the office suite without leaving Moodle.

The proposed solution: Add a direct link to the management interface for Google drive / Microsoft OneDrive.

The criteria for success:
# When browsing an office suite repository, I can easily open the native browsing interface in a new window.

Status: Completed for Moodle 3.3

==== REQ 10 ====
Users affected: Students, teachers

The problem: Any file linked or added to Moodle should be available for checking via a plagiarism plugin

The proposed solution: Verify that files linked to an office suite are supported by the plagiarism API

The criteria for success:
# Verify any user file linked or copied from an office suite is available to the plagiarism API.

Status: The File API allows downloading of files, but no plagiarism plugins exist in core - so no changes were made.

==== REQ 11 ====
Users affected: Developers

The problem: It is difficult to test and maintain the plagiarism API because we have no core implementations and third party implementations require accounts / setup.

The proposed solution: Create a dummy plagiarism plugin (google search?) with no installation requirements.

The criteria for success:
# Developers can install a plagiarism plugin to easily verify the correct functioning of the plagiarism API.

Status: Not complete.

==== REQ 12 ====
Users affected: Administrators

The problem: Institutions can have policies about where to upload and store files used in Moodle

The proposed solution: Create admin settings for each repository plugin to control the default (link or copy) and optionally disable either option.

The criteria for success:
# The administrator configured default (link or copy) is automatically chosen when users are browsing files from a repository.
# If link or copy are disabled by the administrator, they are not available as options for users when browsing files from a repository.

Status: Completed for Moodle 3.3

==== REQ 13 ====
Users affected: Students, teachers

The problem: Users should be able to easily update a file that has been linked to Moodle

The proposed solution: Allow repository plugins to generate an “edit link” for a document that is displayed in the UI in addition to the link to view the file.

The criteria for success:
# Any user who can update a file in Moodle that was linked from an office system has a direct link in Moodle to edit the file in the office suite.
# After saving changes to the file in the office suite - anyone who views the file in Moodle should see the latest version of the file.

Status: Completed for Moodle 3.3 (although there is a single link to the file).

==== REQ 14 ====
Users affected: Students, teachers

The problem: Files available in Moodle should be available offline, and on the Mobile app.

The proposed solution: Verify any read or edit links to files work correctly in the Mobile app. Add download for offline access links to any document where it is available.

The criteria for success:
# There is a way to download linked files from Moodle for viewing offline.
# Edit or view links work correctly when used in the Mobile app.

Status: Completed for Moodle 3.3

==== REQ 15 ====
Users affected: Students, teachers

The problem: Backing up a Moodle course should backup all the externally linked documents.

The proposed solution: Verify the behaviour of backup / restore.

The criteria for success:
# Backing up a course with external files should include only references to the files.
# Restoring a course with linked files to the same site, should restore any files that were previously external links as external links to the same original files.
# Restoring a course with linked files to a different site not restore the files, but should show warnings instead.

Status: Completed for Moodle 3.3

=== Assignments ===

==== REQ 16 ====
Users affected: Students, teachers

The problem: It should be possible for activities to control access to a file that has been linked.

The proposed solution: Extend the repository API to allow creating folders, copies of files to a new owner, and changing the permissions on a file/folder. Extend the assignment activity to implement a workflow for files used as assignment submissions.

The criteria for success:
# A student can upload any file they have access to as an assignment submission.
# A student can override their assignment submission with a later version
# All members of a group should be able to collaborate on a group submission before adding it as their assignment submission.
# Teachers should have read / write access to the submitted files.
# After the files have added to Moodle students should only be able to “read” the file (but they can link a new version of the file as long as they have access to do so).
# It should be possible for any Moodle plugin to replicate this same workflow via the repository API.

Status: Completed for Moodle 3.3

=== Archiving ===

==== REQ 17 ====
Users affected: Students, teachers

The problem: If a teacher links to a file in their personal office suite file area, and then the teacher account is deactivated, deleted or disconnected from the office suite - users in the course must still be able to read and write to the file.

The proposed solution: Verify that access to a file is not lost if the office account no longer exists. Store a copy of the file in Moodle to be used if the original file cannot be accessed.

The criteria for success:
# If a linked file in Moodle is deleted from the office suite - it should still be available to download in Moodle.
# If the account that linked to a file in an office suite is removed - it should still be possible to download the file in Moodle and ideally it should still be possible to edit the file.

Status: Completed for Moodle 3.3

==== REQ 18 ====
Users affected: Administrators

The problem: If files owned by an “Institution” account in the office suite are not organised - it will be impossible to archive no-longer used files at the end of a teaching period.

The proposed solution: All files transferred to an institution account as part of a custom workflow should be organised by course / activity so they can be manually archived as required.

The criteria for success:
# Files used in a custom workflow (e.g. by assignment) should stored in an institutional account, and organised by category / course / activity (reflect the context structure in Moodle).

Status: Completed for Moodle 3.3

=== User Experience ===

==== REQ 19 ====
Users affected: Students, teachers

The problem: When connected to an office suite - it should be possible to upload or create a file in the office suite with a minimum number of steps.

The proposed solution: When using the file picker, there should be a direct link to the native browsing interface which provides the best experience for uploading and creating new files.

The criteria for success:
# Each repository should have a direct link to the native browsing interface.

Status: This requirement was not addressed for Moodle 3.3. It should really be done as a bigger project reviewing the UX of the file picker entirely.

== Technical Specifications ==

This section of the document describes the changes that need to be made in Moodle in order to meet the success criteria of each of the requirements for this project. These specifications describe the design of each of the Office 365 and Google Apps integrations and so each section needs to be implemented twice - once for each integration.

=== Core API for managing Authorized OAuth Applications ===
There should be a new preference page and API to manage the list of a users authorized oauth applications.

This requires a new DB tables to store the system wide OAuth clients and the current users active oauth sessions should be stored in the current PHP session.

mdl_oauth2_clients

# clientid - varchar(100) - NOT NULL
# secret - varchar(100) - NOT NULL
# refreshtoken - varchar(255) - NULL
# systemuser - varchar(255) - NULL
# apirooturl - varchar(255) - NOT NULL
# apirequesttokenurl - varchar(255) - NOT NULL
# apiaccesstokenurl - varchar(255) - NOT NULL

The apirooturl + apirequesttokenurl + apiaccesstokenurl form a unique key. It is possible to retrieve the stored clientid and secret using the 3 api url parameters.

The refresh token here is used to get an access token for the system account.

The systemuser is the unique identifier required to access resources using a system account rather than the current users account.

==== Notes (after prototyping). ====

Open ID Connect is the SSO standard built on top of OAuth 2.0. Google supports it well and Microsoft claim to - but their implementation is not functional/usable.

Problems with Microsoft Open ID Connect implementation (their side not ours):

# It's userinfo endpoint is missing email and picture claims.
# The discovery document points to the wrong api version (1.0 instead of 2.0)
# The tokens from the Open ID Connect token endpoint are not usable with the graph API (because of b)
# The tokens from the alternative OAuth 2.0 endpoints are not compatible with the OpenID Connect endpoints (userinfo).
# Not necessarily a problem but the sup claim from Microsoft is a massive unreadable string which is not nice for a username (but is guaranteed unique).

=== Extend Auth Plugin API ===
The existing Auth Plugin API should allow plugins to register themselves as "OAuth 2 " compatible. This will allow them to be listed on the login page in priority order with icons and coloured buttons. The order of the buttons should be determined by the order of the auth plugin.

=== Auth plugin ===
Implement a new authentication plugin that is "OAuth 2" compatible and is preconfigured to talk to the office suite.

Provide admin settings to limit the valid domains / institutions that can authenticate with this plugin.

Add a setting to allow self registration with this plugin so that accounts can be automatically created if the authentication is successful and no matching account exists.

When an account is connected with this auth plugin - the Moodle calendar rss url should be published to the Office calendar automatically.

There should be a setting to disable the automatic publishing of calendars.

=== Admin tool to manage integration settings ===

An admin tool needs to be created which contains the required information in order to access the office suite API using OAuth as well as a valid access token for a institutional administrator account.

This plugin needs a global on/off switch which enabled or disables the entire office suite integration (config value stored in mdl_config_plugins).

This plugin should have settings to create an entry in the mdl_oauth2_clients table.

The workflow for setting up the plugin would be to enter the client id and secret, then follow a link in the admin tool to authenticate the institutional account via OAuth 2. The refresh token for the institution account will be stored in the database - and used whenever we need to access the API as the "institution" rather than the current user.

=== Repository API ===

The repository api needs to be extended so that repositories can support advanced workflows for files.

Repository plugins should be able to register that they are OAuth compatible. This will enable an additional configuration page for the plugin which allows setting up the system account and authorizing a refresh token for this system user. The refresh token will then be used by the repository plugin to generate an access token when it needs to perform an operation as the system user.

The additional functionality required is:

get_edit_link() - retrieve a link to edit this file in an external application. If supported will show an additional link or menu entry when the file is listed to "edit this file". Moodle will only generate and display this link to users who have access to edit the file in Moodle. The external repository should allow editing from any user who follows this link regardless of the permissions in the external repository.

get_offline_link() - for external files (links), retrieve a link to download this file in a format that is suitable for viewing offline - e.g. PDF. Moodle will only generate and display this link to users who have access to read the file in Moodle. The external repository should allow viewing from any user who follows this link regardless of the permissions in the external repository.

copy_to_system_account() - copy a file from the users file area in the external repository - to new file in a system owned file area in the external repository organised by category, course and activity. This is used as part of an activity workflow when the file switches from being editable by the original author - to being editable by a different group of users (teachers most likely).

=== Repository Plugin ===
Implement a new plugin for this office suite that allows browsing and searching the users currently authorized (OAuth) file area. If there is no valid OAuth session for this OAuth client API the OAuth login screen should be presented to create a new session.

This plugin should also support all of the new functionality for repository plugins listed in Repository API above.

This plugin should also support uploading and creating new files in the repository while browsing / searching.

This plugin should contain a setting to "download for archive" which should download an offline copy of each file - even if was created as a link and store it in Moodle. If enabled the "offline" version of this file will be served from Moodle always and included in backup/restore. Offline versions of files should be refreshed by a cron task and an adhoc task should be created to check for a newer version when a file is accessed.

This plugin should have a setting to say if the default for files added to Moodle is "link" or "copy". It should be possible to disable "link" or "copy" (but not both).

=== Assignment Improvements ===
The assignment should check if the repository plugin supports the advanced workflow for submissions files. If it does - it should copy the submission file to a system account at the point that it is "submitted".

=== Improvements to the File Picker ===
If there are any enabled repositories that report they support uploading of files - a new button should be added to the file manager "Upload file" which will open the file picker with the first "upload" repository already selected.

=== Plagiarism API ===
Extend the plagiarism API to check if a repository supports "offline" links. If it does - the offline version of files should be downloaded and used by the plagiarism API as normal.

=== Plagiarism Plugin ===
Implement a dummy plagiarism plugin to make testing easier. It should support all features of the plagiarism API but does not have to return real data.

Backup 2.0 course report data

2025-02-10T07:46:12Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Template:Backup 2.0}}{{Moodle_2.0}}{{Update}}

'''Notice: Since Moodle 2.2, the admin reports and course report have been merged into a single reports subsystem. This page does not reflect this change yet. It is valid for 2.0 and 2.1 versions.'''

== Introduction ==

In Moodle 2, course reports can have data tables and files which can be backed up with a course. (To create data tables in a course report, use the standard <tt>db</tt> folder.)

None of the standard course reports have any course-related data so it is not obvious how to code the backup and restore for them. This page gives an example theme as a case study which you can use to implement your own backup code for a course report which contains per-course data.

'''Note: Course report data backup requires Moodle 2.0.4 or later.'''

== Example: the 'lazystudents' report ==

As an example I am using a theoretical report which checks the time that each user visits Moodle on each day over the past week. The report produces a list of students who did not access Moodle before a certain time on any day last week. For example, this might include all students who never accessed Moodle before 10:00 on any day last week.

The report has two configuration options which can both be set per-course:

* The hour after which students are considered 'lazy' (e.g. 10).

* A custom image to display with the report (e.g. some courses might prefer a tortoise picture while others prefer a sloth).

The hour is stored in the table <tt>coursereport_lazystudents</tt> which has 3 fields <tt>id</tt>, <tt>courseid</tt>, and <tt>lazyhour</tt>.

The image file is stored using the Moodle file API at the course context, in the <tt>coursereport_lazystudents</tt> component and the <tt>image</tt> file area.

=== Backup ===

The backup code is in the file <tt>course/report/lazystudents/backup/moodle2/backup_coursereport_lazystudents_plugin.class.php</tt>. Leaving out the headers, this file looks like:

class backup_coursereport_lazystudents_plugin extends backup_coursereport_plugin {

/**
* Returns the course report information to attach to course element
*/
protected function define_course_plugin_structure() {
// Define virtual plugin element
$plugin = $this->get_plugin_element(null, $this->get_include_condition(), 'include');

// Create plugin container element with standard name
$pluginwrapper = new backup_nested_element($this->get_recommended_name());

// Add wrapper to plugin
$plugin->add_child($pluginwrapper);

// Set up course report's own structure and add to wrapper
$lazystudents = new backup_nested_element('lazystudents', array('id'), array(
'lazyhour'));
$pluginwrapper->add_child($lazystudents);

// Use database to get source
$lazystudents->set_source_table('coursereport_lazystudents',
array('courseid' => backup::VAR_COURSEID));

// Include files which have coursereport_lazystudents and area image and no itemid
$lazystudents->annotate_files('coursereport_lazystudents', 'image', null);

return $plugin;
}

/**
* Returns a condition for whether we include this report in the backup
* or not. We do that based on if it has any settings in the table.
* @return array Condition array
*/
protected function get_include_condition() {
global $DB;
if ($DB->record_exists('coursereport_lazystudents',
array('courseid' => $this->task->get_courseid()))) {
$result = 'include';
} else {
$result = '';
}
return array('sqlparam' => $result);
}
}

As you can see this works in a similar way to backup for modules and other plugins. The first line:

$plugin = $this->get_plugin_element(null, $this->get_include_condition(), 'include');

means that the format data will only be backed up if the get_include_condition function returns true (i.e. it won't bother backing up data for a course report that does not have settings on the particular course).

You can see how you would change the code to use a different course report name, database table, fields, or file area. It's also possible to add a more complicated data structured in the same way as for other plugins. You could even store user data if required.

==== Testing ====

To test the backup, carry it out and then look inside the resulting zip file. In the <tt>course</tt> folder there should be a file called <tt>course.xml</tt>. If course report data is backed up, it will include a section like the following:

<plugin_coursereport_lazystudents_course>
<lazystudents id="2">
<lazyhour>10</lazyhour>
</lazystudents>
</plugin_coursereport_lazystudents_course>

Additionally, if the file backup worked, you should be able to find any files from within the specified file area inside the 'files' section of the backup (it will help if you know the hash code of the file; otherwise, note the size and make sure the test course doesn't have many other files to look through).

If there is no data in the table, the course report will not be backed up at all and this section will not be included in course.xml.

=== Restore ===

Unsurprisingly, restore code goes in the file <tt>course/report/lazystudents/backup/moodle2/restore_coursereport_lazystudents_plugin.class.php</tt>. Leaving out the headers, this file is:

class restore_coursereport_lazystudents_plugin extends restore_coursereport_plugin {

/**
* Returns the paths to be handled by the plugin at course level
*/
protected function define_course_plugin_structure() {
$paths = array();

// Because of using get_recommended_name() it is able to find the
// correct path just by using the part inside the element name (which
// only has a /lazystudents element).
$elepath = $this->get_pathfor('/lazystudents');

// The 'lazystudents' here defines that it will use the
// process_lazystudents function to restore its element.
$paths[] = new restore_path_element('lazystudents', $elepath);

return $paths;
}

/**
* Called after this runs for a course.
*/
function after_execute_course() {
// Need to restore file
$this->add_related_files('coursereport_lazystudents', 'image', null);
}

/**
* Process the 'lazystudents' element
*/
public function process_lazystudents($data) {
global $DB;

// Get data record ready to insert in database
$data = (object)$data;
$data->courseid = $this->task->get_courseid();

// See if there is an existing record for this course
$existingid = $DB->get_field('coursereport_lazystudents', 'id',
array('courseid'=>$data->courseid));
if ($existingid) {
$data->id = $existingid;
$DB->update_record('coursereport_lazystudents', data);
} else {
$DB->insert_record('coursereport_lazystudents', $data);
}

// No need to record the old/new id as nothing ever refers to
// the id of this table.
}
}

Again this is just the same as restoring a module. To change this to support your own course report, you would change the word 'lazystudents' to your own course report's name, change references to the <tt>coursereport_lazystudents</tt> table to your own data table (or otherwise change what exactly it does when restoring), and change the file area details in the <tt>add_related_files</tt> call.

The restore code always runs if the data was included in the backup.

==== Testing ====

It is probably obvious how to test restore :) Once you've verified that backup is producing the correct XML data, just check that restore recreates the necessary data for you.

In our case, we know restore works if the lazy hour value for the new course is correctly set, and the sloth picture is correctly displayed.

Backup 2.0 XML format

2025-02-10T07:45:42Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

We need some content here! :)

Backup 1.9 conversion for developers

2025-02-10T07:45:27Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Tutorial for developers on backup 1.9 conversion
|state = Ready to use
|tracker = MDL-22414
|discussion = N/A
|assignee = [[User:David Mudrak|David Mudrak]]
}}

== Introduction ==
[[Image:zip2mbz.png|right]]

This page follows up the tutorial at [[Backup 2.0 for developers]] and describes how to implement support of Moodle 1.9 backup conversion into the new Moodle 2.x format.

In short, since Moodle 2.1 there is a new type of core component available called ''backup converters''. Converter is a tool that takes a directory containing some Moodle course data and converts it into another format. At the moment we are working on converter called '''moodle1''' that supports 1.9 => 2.x conversion path. In the future, more converters can be written (eg supporting custom formats, Blackboard, IMS CC etc). Converters can be chained so if there is a converter that supports IMS => 1.9 conversion and another one converting 1.9 => 2.x, Moodle can automatically restore IMS backups. The core of the moodle1 converter is implemented in backup/converter/moodle1/.

The moodle1 converter is under a heavy development at the moment still. The first milestone is to be able to convert all activity modules without user data.

== Getting familiar with the required changes of the structure ==

For the purpose of this tutorial, the [[Choice module]] is used as an example as it allows to demonstrate the basic workflow of the conversion. Let us start with performing a backup in both 1.9 and 2.1. Create an empty course with a single simple Choice module instance inside in both 1.9 and 2.1. Choose backup mode without any user data, without roles, files etc and include just the instance of the module you created.

In case of Moodle 1.9, you will end up having once monolithic file moodle.xml. In Moodle 2.1, the module data will be stored in a file like activities/choice_x/choice.xml. The task of the converter you are going to write is to convert data contained in moodle.xml into choice.xml.

=== Getting the list of XML paths ===

Looking at moodle.xml in 1.9 backup, you can see that the module data are stored in XML nodes at /MOODLE_BACKUP/COURSE/MODULES/MOD and that you are interested only to those MODs having <MODTYPE>choice</MODTYPE>. To make your life easier, the core of the moodle1 converter injects one virtual node into the path so that to our module, it appears as if its data were in /MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE. That is as if all Choice data were wrapped by yet another tag in moodle.xml.

Now look into 1.9 Moodle code and locate the file mod/choice/backuplib.php. Reading its code you can see that the MOD element in moodle.xml (that will be presented as MOD/CHOICE element to our code) contains the following tags holding the corresponding fields from mdl_choice table:

ID $choice->id
NAME $choice->name
TEXT $choice->text
FORMAT $choice->format
PUBLISH $choice->publish
SHOWRESULTS $choice->showresults
DISPLAY $choice->display
ALLOWUPDATE $choice->allowupdate
SHOWUNANSWERED $choice->showunanswered
LIMITANSWERS $choice->limitanswers
TIMEOPEN $choice->timeopen
TIMECLOSE $choice->timeclose
TIMEMODIFIED $choice->timemodified

Below these, the choice options data are dumped into the OPTIONS section, with each option details being wrapped by the OPTION tag:

ID $cho_opt->id
TEXT $cho_opt->text
MAXANSWERS $cho_opt->maxanswers
TIMEMODIFIED $cho_opt->timemodified

The file moodle.xml will be parsed by a progressive parser. That basically means it will be read in a sequential order and each time some interesting path is reached, the data contained by that element are dispatched to a handler (on contrary to DOM like parsers where the whole file would be converted into a huge in-memory tree structure). To catch the choice data in moodle.xml we will have to handle /MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE and /MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE/OPTIONS/OPTION paths

=== Getting know how data change during 1.9 => 2.x upgrade ===

Now let us open mod/choice/db/upgrade.php in your Moodle 2.1 code. It contains all the upgrade logic that is happening during the upgrade of 1.9 site to 2.x. Reading the code, we realize that:

* the database field ''text'' in the {choice} table is renamed to ''intro''
* the database field ''format'' in the {choice} table is renamed to ''introformat''
* a new field ''completionsubmit'' is added to the {choice} table with the default value 0

=== Getting know the structure of choice.xml ===

Finally look at mod/choice/backup/moodle2/ in your Moodle 2.1, particularly the file backup_choice_stepslib.php. Here you can see how the structure of the choice.xml is defined and what data it contains:

$choice = new backup_nested_element('choice', array('id'), array(
'name', 'intro', 'introformat', 'publish',
'showresults', 'display', 'allowupdate', 'allowunanswered',
'limitanswers', 'timeopen', 'timeclose', 'timemodified',
'completionsubmit'));

The <choice> element has a child element <options> that in turn contains set of <option> elements:

$option = new backup_nested_element('option', array('id'), array(
'text', 'maxanswers', 'timemodified'));

Great! Now we have all the information needed to start with coding.

=== Summary ===

Do not continue your task unless

* you have read the backuplib.php in 1.9 source of the module and you know how the <MOD> node in moodle.xml is constructed (do not rely on just looking at some example file)
* you have read the db/upgrade.php and you known all steps needed to perform
* you have read backup/moodle2/backup_xxx_stepslib.php and you know how the activity file in 2.0 is constructed (again, do not rely on examples)

== Writing the conversion handler ==

Before we start, please make your own local branch that will track David's https://github.com/mudrd8mz/moodle/tree/backup-convert tree. That is the pre-integration branch where the development of backup conversion is happening and your work will have to be merged there before it gets into the moodle.git master (use Github's pull request feature once you want your work being included there).

To add this branch into your current moodle.git clone, you may want to use something like this:

$ cd ~/public_html/moodle21
$ git remote add mudrd8mz git://github.com/mudrd8mz/moodle.git
$ git fetch mudrd8mz
$ git checkout --track -b backup-convert mudrd8mz/backup-convert

Alternatively, if you want to create a pristine installation just for this project, you can simply run

$ cd ~/public_html
$ git clone git://github.com/mudrd8mz/moodle.git moodle21convert
$ cd moodle21convert
$ git checkout --track -b backup-convert origin/backup-convert

=== The backup conversion workflow ===

To be able to write the module conversion handler, you should understand what's going on in the background. This is a simplified description of the workflow:

[[image:backup-convert-overview.png|thumb|UML sequence diagram of the backup conversion machinery]]

* In its constructor, the restore_controller instance detects the format of the data to be restored and if it realizes it is not the standard moodle2 format, it knows the conversion will be needed (grep for backup::STATUS_REQUIRE_CONV)
* The restore_controller::convert() method is called (@todo is it? where? by who?) and it in turn calls convert_helper::to_moodle2_format(). This helper method tries to find the most effective conversion path between the current format and the target moodle2 format as it constructs the chain of converters, though this is not much interesting yet as we have just one converter now ... well not yet even :-p
* For each converter in the chain, convert_factory::get_converter() creates new instance of it and its public convert() method is called.
* The core functionality of moodle1 converter is defined in backup/converter/moodle1/lib.php in the class moodle1_converter and its subclasses. When the class is instantiated, it prepares a progressive parser and a parser processor and it registers all available handlers of the parsed data. The incoming convert() call sets up the directory to write to and runs the instance's execute() method.
* The execute() starts up the parser of the 1.9 moodle.xml. That file is parsed sequentially and whenever it reaches a node to which some handler is attached, it dispatches the parsed data via dispatch_chunk(). The parser also triggers notify_path_start() and notify_path_end() when it is entering some registered path element and when it is leaving it.
* The parser processor re-dispatches the parsed data and events via path_start_reached(), process_chunk() and path_end_reached() methods defined by the moodle1_convert.
* Finally, the parsed data and events are re-dispatched once more and they are handled by moodle1_handler subclasses via their on_xxx_start(), process_xxx() and on_xxx_end() methods. These are the places where the actual conversion of data must happen and the new data are written into the new XML files.
* The moodle1_handler subclasses can use either xml_writer's begin_tag(), full_tag() and end_tag() method to construct the XML file contents. A helper method that dumps a complete tree-ish structure is available: write_xml().

After the end of the parsed moodle.xml file is reached, the working directory with the new XML files is renamed so that it replaces the previous format. If there was a chain of converters, it would be the next one's round now. For us at the moment, the job is done. Once the directory contains valid moodle2 format, normal restore process is executed as if the course backup come from a 2.0 server.

==== Highlights and places to look at ====

While working on the converter, always keep in mind:

* The file moodle.xml is parsed sequentially by a progressive parser. If the current node's data are available, the handler must either write them immediately into a new XML file or stash them for processing them later - either by the on_element_end() event handler method or by other instance of the handler that is being executed later.
* Minimise the memory footprint of the conversion job. Do not accumulate the incoming data in memory if it is not necessary. Especially those that may be huge (like all forum posts). Write the data to the new XML file as soon as possible (on-the-fly ideally but that is not always possible).
* Look at various examples of moodle1 handler classes in backup/converter/moodle1/handlerlib.php

=== The handler library template ===

The moodle1_converter itself converts just part of the moodle.xml file via handlers defined in handlerlib.php (for example the course sections, course modules etc). To convert module-specific data, moodle1_handlers_factory searches for the handlers in modules' (and generally plugins') directories. The Choice module conversion logic is stored in a library mod/choice/backup/moodle1/lib.php. The basic template for such a file is:

<syntaxhighlight lang="php">
<?php

// This file is part of Moodle - http://moodle.org/
//
// Moodle is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// Moodle is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with Moodle. If not, see <http://www.gnu.org/licenses/>.

/**
* Provides support for the conversion of moodle1 backup to the moodle2 format
*
* @package mod
* @subpackage choice
* @copyright 2011 Your Name <your@email>
* @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
*/

defined('MOODLE_INTERNAL') || die();

/**
* Choice conversion handler
*/
class moodle1_mod_choice_handler extends moodle1_mod_handler {

/**
* Declare the paths in moodle.xml we are able to convert
*
* The method returns list of {@link convert_path} instances. For each path returned,
* at least one of on_xxx_start(), process_xxx() and on_xxx_end() methods must be
* defined. The method process_xxx() is not executed if the associated path element is
* empty (i.e. it contains none elements or sub-paths only).
*
* Note that the path /MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE does not
* actually exist in the file. The last element with the module name was
* appended by the moodle1_converter class.
*
* @return array of {@link convert_path} instances
*/
public function get_paths() {
return array(
new convert_path('choice', '/MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE'),
new convert_path('choice_option', '/MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE/OPTIONS/OPTION'),
);
}

/**
* This is executed every time we have one /MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE
* data available
*/
public function process_choice($data) {
}

/**
* This is executed every time we have one /MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE/OPTIONS/OPTION
* data available
*/
public function process_choice_option($data) {
}
}
</syntaxhighlight>

Let us look at this code template closer so that you understand the bits and will be able to use it as a template for your own work.

As you can see, the file defines a single class that extends moodle1_mod_handler. All moodle1 handler classes must define get_paths() public method that returns a list of convert_path instances. In our example, we declare that the handler is interested in those two paths we have identified above. We register them with "aliases" ''choice'' and ''choice_option''. The developer can choose any reasonable alias here and provide it as the first parameter of the convert_path constructor.

For each convert_path instance, a corresponding processing method must exist in the class. This method must be named process_xxx() where xxx is the alias declared in the get_paths().

=== Setting-up the development environment ===

Use a real 1.9 backup file and unzip it into a folder within your $CFG->dataroot.'/temp/backup/' directory. Let us assume you have unzipped the backup into a folder called ''refcourse''.

Put the following script into the root of your Moodle (as 'convert.php' for example):
<syntaxhighlight lang="php">
<?php
define('CLI_SCRIPT', 1);
require(dirname(__FILE__).'/config.php');
require_once($CFG->dirroot.'/backup/util/helper/convert_helper.class.php');

convert_helper::to_moodle2_format('refcourse', 'moodle1');
</syntaxhighlight>

(if you do not want to execute the script via CLI but from your browser, just remove the CLI_SCRIPT declaration).

Put the following into your config.php:
<syntaxhighlight lang="php">
$CFG->keeptempdirectoriesonbackup = true;
</syntaxhighlight>

The convert.php script in the Moodle root converts the 'refcourse' directory into the Moodle 2.0 MBZ format. To test it now, modify the process_choice() method so that it just dumps the $data:

<syntaxhighlight lang="php">
public function process_choice($data) {
print_object($data); // DONOTCOMMIT
}
</syntaxhighlight>

and run the convert.php. If you are lucky enough, you should see an array dumped for each choice instance defined in moodle.xml file. Also look at $CFG->dataroot/temp/backup/ - you should see that the 'refcourse' now contains the converted version of the backup and the original 1.9 should be left there for the reference, too. Do not continue unless this works for you.

=== Data structure transformations ===

As you can from the print_object() output, the process_choice() method is passed the data contained in the corresponding <MOD>...</MOD> part of the moodle.xml file. We know that we need to rename fields ''text'' and ''format'', add a new field ''completionsubmit'' and drop the field ''modtype'' (that one was already used to expand the XML path so that it looks as if the moodle.xml defined the data inside <MOD><CHOICE>...</CHOICE></MOD>). These transformations are pretty common and the converter can do them on behalf of us.

You can provide so called ''recipes'' that will be applied to the element data before they are dispatched to the proces_xxx() methods. These recipes are used to "pre-cook" the raw data from moodle.xml. In fact, one such recipe has been already applied by default - converting the tag names to lower case. Three other types of recipes are supported at the moment: to add new fields, to rename fields and to drop fields. All you need to do is to declare what recipes and in what order should be applied on the parsed data. You can do so by adding the third parameter to the constructor of convert_path instances in get_paths() method:

<syntaxhighlight lang="php">
public function get_paths() {
return array(
new convert_path(
'choice', '/MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE',
array(
'renamefields' => array(
'text' => 'intro',
'format' => 'introformat',
),
'newfields' => array(
'completionsubmit' => 0,
),
'dropfields' => array(
'modtype'
),
)
),
new convert_path('choice_option', '/MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE/OPTIONS/OPTION'),
);
}
</syntaxhighlight>

As you can see, the third parameter is an associative array. The keys of the array are the names of the recipes. The ''renamefields'' recipe will be applied first and will rename ''text'' to ''intro'' and ''format'' to ''introformat''. The ''newfields'' recipe will add a new field ''completionsubmit'' with the value set to 0. And finally, the ''dropfields'' recipe will delete the field ''modtype'' from the data.

In case you would need to know how the data looked like before applying the recipes, your process_xxx() method can get them via its second parameter:

<syntaxhighlight lang="php">
public function process_choice($data, $raw) {
print_object($data); // DONOTCOMMIT
print_object($raw); // DONOTCOMMIT
}
</syntaxhighlight>

This may be required if, for example, you need to calculate a value of a new field from the value of some field that was dropped by the recipe.

=== Writing the transformed data into the new XML file ===

Now we have the choice data transformed and passed to process_choice() method and we can write them into the new XML file in the MBZ format directory. As you know, the module instance data are saved in a file like activities/choice_x/choice.xml where x is the course moduleid of our current instance (note that we do not know this cmid yet). Following the principle "write data as soon as possible", let us go and write them into the file:

<syntaxhighlight lang="php">
/**
* This is executed every time we have one /MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE
* data available
*/
public function process_choice($data) {

// get the course module id and context id
$instanceid = $data['id'];
$cminfo = $this->get_cminfo($instanceid);
$moduleid = $cminfo['id'];
$contextid = $this->converter->get_contextid(CONTEXT_MODULE, $moduleid);

// we now have all information needed to start writing into the file
$this->open_xml_writer("activities/choice_{$moduleid}/choice.xml");
$this->xmlwriter->begin_tag('activity', array('id' => $instanceid, 'moduleid' => $moduleid,
'modulename' => 'choice', 'contextid' => $contextid));
$this->xmlwriter->begin_tag('choice', array('id' => $instanceid));

unset($data['id']); // we already write it as attribute, do not repeat it as child element
foreach ($data as $field => $value) {
$this->xmlwriter->full_tag($field, $value);
}
}
</syntaxhighlight>

Let us look closely on what's going on here. At the top, we prepare the values needed for attributes of the <activity> tag that is the root element of the file. Our parent class defines a method get_cminfo() that returns a structure containing the needed cmid for our instance. The get_contextid() method is a bit more tricky. In Moodle 1.9 backup files, there is no context information stored at all. But Moodle 2.0 format contains it. So the converter must actually generate fictive context ids for various levels (course, modules, blocks, ...) as if they were stored in moodle.xml.

In the next step, we open a new XML file for writing. Then we use xml_writer's method begin_tag() to dump the first lines of the file. Then, in the foreach loop, we write all cooked data into the opened file. Note that we leave the file open so that other methods in our class can continue adding their own data to it.

The process_xxx() method should return the $data if it modifies them (so they could be used later by on_choice_end() method, if it was needed). But as long as we do not do any other transformation, we do not return anything. In that case, our $this->converter stores just the cooked data for eventual later processing.

=== On-path-start and on-path-end events ===

So far we've worked with the method process_choice() that is executed every time we have the attached element's data available. For each registered path, two more methods are supported in our handler. Assuming that 'xxx' is the alias for the path we declared in get_paths(), the methods on_xxx_start() and on_xxx_end() will be executed every time we reach the opening tag and closing tag of that path, respectively.

The on_xxx_start() does not accept any parameters and it is executed when the opening element for the given path is reached by the parser. The on_xxx_end() may accept one array $data that contains the element's data processed previously by the process_xxx() method. Typical usage for these two handlers is to write wrapping tags into the target XML file. Let us demonstrate this case.

Let us register yet another path in the get_paths() method (note the plural - choice_options)
<syntaxhighlight lang="php">
...
new convert_path('choice_options', '/MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE/OPTIONS'),
...
</syntaxhighlight>

Note that the <OPTIONS> itself does not contain any data (leaves in the XML tree), it is just a wrapper for the nested <OPTION> elements. So there is no point of having process_choice_options() method because it would be never executed. However we register this path so that we can declare two event listeners for it:

<syntaxhighlight lang="php">
/**
* This is executed when the parser reaches the <OPTIONS> opening element
*/
public function on_choice_options_start() {
$this->xmlwriter->begin_tag('options');
}

/**
* This is executed when the parser reaches the closing </OPTIONS> element
*/
public function on_choice_options_end() {
$this->xmlwriter->end_tag('options');
}
</syntaxhighlight>

As you can see, we use the on-start and on-end event listeners here to generate the wrapping <options></options> tag pair. And the next step is just to make sure that the inner <option>...</option> data are written into the file, too.

=== Writing a complete tree-ish structure into the XML file in one step ===

As the parser continues parsing the moodle.xml file, our handler's method process_choice_option() is called once there are data for a single <OPTION>...</OPTION> element available (because we registered it as a path we are interested in). In this case, the situation is much much simpler. There are no transformations needed (but converting tags to lower case and it is done automatically). Therefore we we can write the whole array including the closing </option> tag. In such case there is a nice helper method available:

<syntaxhighlight lang="php">
/**
* This is executed every time we have one /MOODLE_BACKUP/COURSE/MODULES/MOD/CHOICE/OPTIONS/OPTION
* data available
*/
public function process_choice_option($data) {
$this->write_xml('option', $data, array('/option/id'));
}
</syntaxhighlight>

This write_xml() method writes the given $data tree into the <option>...</option> element and $data->id will be written as the option's attribute instead of a child element.

=== Finishing the job ===

When all options are written, we need to generate the closing tags, close the file and release our xml writer. For this we can use the on-path-end event listening method again. This one is executed as the parsers reaches the closing </MOD> tag in moodle.xml (or rather think of it as if it reached the closing </CHOICE> tag in that virtual </CHOICE></MOD> path.

<syntaxhighlight lang="php">
/**
* This is executed when we reach the closing </MOD> tag of our 'choice' path
*/
public function on_choice_end() {
// close choice.xml
$this->xmlwriter->end_tag('choice');
$this->xmlwriter->end_tag('activity');
$this->close_xml_writer();
}
</syntaxhighlight>

Note that this on_xxx_end() function can take a parameter $data that would contain the data returned previously by process_xxx(). If the processing method does not return anything, just the cooked raw data are available to the on_xxx_end() method.

And we are done! Execute the convert.php again and you shall find the choice.xml file converted correctly there. Was easy, heh? :-)

=== Important notes ===

* Note that you can't use on_choice_start() event listening method for the root <MOD> element itself. There is a reason for that described in the phpdoc of the dispatching moodle1 methods, if you are interested. Just live with that that the process_choice() in our example is the first executed entry point in your class.
* Note that in our case, there is actually no need to use on_choice_options_start() and on_choice_options_end() methods. We could simply write the opening <options> at the end of process_choice() and then the closing </options> at the top of on_choice_end(). We describe the start/end listeners here to demonstrate the feature mainly. And also, some may find the resulting code cleaner.

== Files migration ==

While studying the upgrade steps in db/upgrade.php, you might notice that your module needs to migrate its files into the new [[File API|file API]] framework. Typical cases are for example forum posts attachments, submitted files in the assignment etc. You module converter has to apply the similar logic, pretending that the final XML files were created in a virtual 2.0 site with the files already migrated.

=== Where files can be stored in the 1.9 backup ZIP file ===

* All the course files are copied into the ''course_files'' folder within the ZIP, see backup_copy_course_files().
* All the site files are copies into the ''site_files'' folder, if the user used this feature, see backup_copy_site_files().
* Needed user files and group files are copied into ''user_files'' and ''group_files'' folders, respectively. See backup_copy_user_files() and backup_copy_group_files().
* Module specific files (forum posts attachments, ...) as copied by the modules themselves in their backuplib, See for example backup_workshop_files().

=== How files are stored in the 2.0 backup MBZ file ===

The files related information is stored at several places in the MBZ file:

* The /files folder is a pool for all the needed files. It is a [http://en.wikipedia.org/wiki/Content-addressable_storage content-addressable storage] as the file name is SHA1 hash of the file contents and files are grouped into directories according the first two characters of their name.
* The /files.xml file contains records from the mdl_files table where each file usage is described. This is similar to hard-linking mechanism in file systems. Note that the number of files listed in files.xml is greater than the number of physical files in the /files folder for two reasons: (1) the directories themselves are listed in files.xml (see the filename '.') and (2) one physical file in the pool can be referenced from two different places in files.xml
* Every module has to declare the files it needs in its inforef.xml files (among other references).

So to convert your module files, you must make sure that the files are copied into the pool, are listed in the common files.xml and are correctly referenced in your inforef.xml file. The files.xml file is generated automatically by one of the moodle1_converter core handlers but your module must write your inforef.xml yourself. To do so, you should always use the moodle1_file_manager instance.

=== Files migration manager ===

The easiest way to migrate your files and get their ids for dumping them into inforef.xml is to use one instance of moodle1_file_manager per each module instance you convert. Every instance of the file manager keeps track of file ids it creates. The file manager can be seen as an object with several public properties that represent the values of the records in files.xml file. These properties can be set either implicitly via the factory method (that passes them to the manager constructor) or explicitly. The file manager has two public methods: migrate_file() used to migrate one particular file and migrate_directory() to migrate whole directory of files (including subdirectories).

Let us look at a particular example of how the Workshop module uses the file manager.

=== Use case 1: Migrating workshop submission attachments ===

Workshop module stores submission attachments in files like /moddata/workshop/xxx/filename.ext where 'xxx' is the submission id. Multiple files are allowed there. During the migration, these files must be transformed into records with the:

* contextid set to the workshop course module context
* component set to 'mod_workshop'
* filearea set to 'submission_attachment'
* itemid set to the submission id
* userid set to the id of the user who submitted the file
* filename set to the original file name
* filepath set to '/' (all files are in the root directory in the given filearea/itemid

It is obvious that all the submission file records in the given workshop instance share the same context, component and filearea. For each submission, the itemid and userid must be set based on the data in <SUBMISSION> element.

Let us create a new instance of the file manager at the bottom of the process_workshop() method that is attached to the root <MOD> element of one workshop instance (the following code shows just the important parts of the whole class):

<syntaxhighlight lang="php">
class moodle1_mod_workshop_handler extends moodle1_mod_handler {

/** @var array in-memory cache for the course module information for the current workshop */
protected $currentcminfo = null;

/** @var moodle1_file_manager instance for the current workshop */
protected $fileman = null;

public function get_paths() {
return array(
new convert_path('workshop', '/MOODLE_BACKUP/COURSE/MODULES/MOD/WORKSHOP'),
new convert_path('workshop_submissions', '/MOODLE_BACKUP/COURSE/MODULES/MOD/WORKSHOP/SUBMISSIONS'),
new convert_path('workshop_submission', '/MOODLE_BACKUP/COURSE/MODULES/MOD/WORKSHOP/SUBMISSIONS/SUBMISSION')
);
}

public function process_workshop($data, $raw) {
$instanceid = $data['id'];
$this->currentcminfo = $this->get_cminfo($instanceid);
$moduleid = $this->currentcminfo['id'];
$contextid = $this->converter->get_contextid(CONTEXT_MODULE, $moduleid);

// prepare the file manager for this instance
$this->fileman = $this->converter->get_file_manager($contextid, 'mod_workshop');
}

public function on_workshop_submissions_start() {
$this->fileman->filearea = 'submission_attachment';
}

public function process_workshop_submission($data) {
// migrate submission attachments
$this->fileman->itemid = $data['id'];
$this->fileman->userid = $data['userid'];
$this->fileman->migrate_directory('moddata/workshop/'.$data['id']);
}
}
</syntaxhighlight>

The main job happens in process_workshop_submission() method. When it is executed, $this->fileman is correctly configured to migrate files into the correct context, component and filearea. If the directory moddata/workshop/xxx/ exists within the backup for the current submission, we set the relevant properties of the fileman and ask it to migrate all files in that directory.

Note that because we migrate files to the 'submission_attachment' filearea only, we could actually set it via get_file_manager() and get rid of the listener of <SUBMISSIONS> completely. The code above should illustrate how you can change the manager's properties to desired values as the parser goes down the moodle.xml file. Usually you will set at least contextid and the component name in the factory method get_file_manager() because those will not change. Other properties are set to correct values as soon as they are available.

The last step is to generate inforef.xml where we annotate all migrated files as being referenced by this workshop instance.

<syntaxhighlight lang="php">
public function on_workshop_end() {
// close workshop.xml
$this->xmlwriter->end_tag('workshop');
$this->xmlwriter->end_tag('activity');
$this->close_xml_writer();

// write inforef.xml
$moduleid = $this->currentcminfo['id'];
$this->open_xml_writer("activities/workshop_{$moduleid}/inforef.xml");
$this->xmlwriter->begin_tag('inforef');

$this->xmlwriter->begin_tag('fileref');
foreach ($this->fileman->get_fileids() as $fileid) {
$this->write_xml('file', array('id' => $fileid));
}
$this->xmlwriter->end_tag('fileref');

$this->xmlwriter->end_tag('inforef');
$this->close_xml_writer();

// get ready for the next instance
$this->currentworkshop = null;
$this->currentcminfo = null;
$this->newelementids = array();
}
</syntaxhighlight>

Here we use the file manager's method get_fileids() that returns the list of all files it has ever converted. And because we create new file manager instance for every single workshop instance, the list is exactly what must be put into inforef.xml.

Note that inforef.xml will contain more data later - the list of annotated users, roles, scales and other items used by the given instance is used there.

Available update notifications

2025-02-10T07:44:41Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Available update notifications
|state = Completed - code integrated into Moodle 2.3
|tracker = MDL-20438
|discussion = [[Talk:Available update notifications|Talk page]]
|assignee = [[User:David Mudrak|David Mudrak]], Eloy Lafuente
}}
{{Moodle 2.3}}

== Goals and milestones ==

Keeping a Moodle site up-to-date is the primary way of keeping it secure. We should encourage admins to update their sites to the most recent stable version on a regular basis. As a first step, for Moodle 2.3, we will implement a notification infrastructure to:

* notify admins about Moodle core updates available for their site; and
* notify admins about available updates for the contributed plugins installed on their site.

Notifications will be displayed at the Admin notifications page and Plugins overview page. In their messaging preferences, admins will be able to set up notifications to be sent by email, Jabber, etc. (using standard [[Message_API|messaging]] features).

== Scrolls of Wisdom ==

Prior to displaying these notifications (and eventually sending them in email/message via the inbuilt messaging system) we need to fetch the relevant information from some authoritative source. There are two places with the required "knowledge".

; download.moodle.org : The [http://download.moodle.org/ Download site] is the place where standard Moodle packages are announced and published. This is the place where Moodle HQ officially declare what is the most recent version of Moodle core available (for each supported branch).
; moodle.org/plugins : The [http://moodle.org/plugins Plugins directory] is the place where contributed plugins are registered. Although contributed extensions can be published and announced anywhere, Moodle HQ provide notification support for plugins registered at the Plugins directory only. : This is definitely the new Plugins repository at .

Even though there are these two authoritative sources, Moodle sites access a single URL when fetching the information about available updates. See the communication protocol described below for details.

From now on, "the client" in the text represents the local Moodle site where the information about available update should be displayed. "The remote site" represents a site maintained by Moodle HQ where the information about available update is defined. Clients read from the remote site and display eventual notifications to their admins.

== One Click to Rule Then All ==

From the user's perspective, obtaining the information about available updates (and actually obtaining those updates themselves in the future) should be as simple as clicking a button, or simpler (that is the check is done automatically by cron every now and then). But it should be clearly documented what's going on behind the scene and what information about the client is sent to the remote site during the request.

The privacy aspect of this project was discussed. There was a proposal to gather overview stats about the client during the request. But there was also an objection that this feature should be specific for hub subscription exclusively with an easy and single place to opt-out. At the end it was decided that:

* The client must provide just basic information about itself - the installed Moodle version and the branch.
* If the client wants to receive the information about available updates for additional (non-standard, contributed) plugins, it must provide their list together with their current versions.
* The remote site uses submitted data to return just the relevant update information. If the client declares it is a Moodle 2.3 site with the mod_foo and mod_bar extensions installed, the remote site returns the information about the most recent version at MOODLE_23_STABLE, MOODLE_24_STABLE and any other higher branch, including master. The information about the most recent versions of mod_foo and mod_bar for the current MOODLE_23_STABLE branch (if there are such versions) is returned, too.
* As a part of each response, the remote site returns a special hash-like value called "ticket". The client should use the ticket during the next request. This mechanism helps Moodle HQ to match all requests coming from a single client even without using any sensitive information that would identify the site. This way, Moodle HQ can monitor the distribution of Moodle versions and deployed plugins while fully respecting the anonymous access to the update notification service.

== Communication protocol, or There and Back Again ==

This section describes how a Moodle site as a client can fetch the information from the remote site.

=== Available Moodle update ===

[[image:uml-updates-core.png|400px|thumb|left|UML sequence diagram - Checking for the available updates of Moodle core]]
 

* A: The admin visits the Notifications page
* B: During the page rendering, the available_update_checker class is called, requesting the information for the "core" component.
* C: The checker looks into the local storage/cache (currently implemented using the config_plugins table) for the available update info.
* D: The available update info is returned to the caller script. It is basically a data object that holds some useful properties like version, release (build) and maturity of Moodle code available at the remote site.
* E: If the version available at the remote site is newer than the one currently installed, inform the admin. Admins can configure what maturity level the updates must have to be informed about (eg "Inform me about stable releases only") and whether they want to be informed about weekly builds, too.
* F: The admin presses the button "Check for update now" (eventually a cronjob to do so is executed, the procedure is the same).
* G: The checker's method fetch() is called
* H: Internally, the checker class prepares the request URL to contain the currently installed Moodle version, branch and the list of installed plugins. It makes the HTTP POST request to the remote site script '''http://download.moodle.org/api/1.0/updates.php'''
* J: The remote site returns requested data in a form of JSON encoded structure.
* K: The checker class stores the response in the local storage for later usage
* L: The browser is redirected back to the screen with the button. GOTO A.

=== Available plugin updates ===

[[image:uml-updates-plugins.png|700px|thumb|left|UML sequence diagram - Checking for the available updates of Moodle plugins]]
 

The mechanism is the same from the client's point of view. The remote site runs its own cron jobs to fetch and populate required data from both sources and make them ready to be served.

=== Example response format ===

$data = array(
'status' => 'OK', // the constant 'OK' is checked by the client
'provider' => 'http://download.moodle.org/api/1.0/updates.php', // our URL that prepared these data
'apiver' => '1.0', // API version determines the format of the response
'timegenerated' => time(), // our timestamp of when the data were populated and sent back
'forbranch' => '2.3', // the caller's major version they provided in the request
'forversion' => '2012031500.00', // the caller's version they provided in the request
'ticket' => $newticket, // a value that the client should pass via the 'ticket' param during the next request
'updates' => array( // list of available updates for the caller (based on their version provided in the request)
'core' => array( // Moodle core updates. eg for a 2.3 client it would return all stable 2.3.x, 2.4.y, 2.5.z etc
array(
'version' => 2012031500.04,
'release' => '2.3dev (Build: 20121201)',
'maturity' => 200, // one of the MATURITY_xxx constants
'url' => 'http://download.moodle.org/', // general URL to visit and know more about the component
'download' => 'http://download.moodle.org/download.php/MOODLE_23_STABLE/moodle-2.3.3-latest.zip', // URL to get the ZIP
),
array(
'version' => 2012120100.06,
'release' => '2.3dev (Build: 20121201)',
'maturity' => 150, // one of the MATURITY_RC constants
'url' => 'http://download.moodle.org/',
'download' => 'http://download.moodle.org/download.php/MOODLE_24_STABLE/moodle-2.4.0-latest.zip',
),
array(
'version' => 2012120804,
'release' => '2.3dev (Build: 20121208)',
'maturity' => 50, // one of the MATURITY_xxx constants
'url' => 'http://download.moodle.org/',
'download' => 'http://download.moodle.org/download.php/master/moodle-2.5-dev.zip',
),
),
'local_moodlecheck' => array(
array(
// info from the plugin's version.php, just 'version' is mandatory
'version' => 2012011000,
'requires' => 2010112400,
'maturity' => 200, // {@link MATURITY_STABLE}
'release' => '1.0',
'url' => 'http://moodle.org/plugins/',
'download' => 'http://moodle.org/plugins/download.php',
),
array(
'version' => 2012091501,
'requires' => 2010112400,
'maturity' => 150, // {@link MATURITY_STABLE}
'release' => '1.1 RC1',
'url' => 'http://moodle.org/plugins/',
'download' => 'http://moodle.org/plugins/download.php',
),
array(
'version' => 2012120100,
'requires' => 2010112400,
'maturity' => 50, // {@link MATURITY_STABLE}
'release' => '1.2 dev',
'url' => 'http://moodle.org/plugins/',
'download' => 'http://moodle.org/plugins/download.php',
),
),
'qtype_oumultiresponse' => array(
array(
'version' => 2011051200,
'requires' => 2011070100,
'maturity' => 200, // {@link MATURITY_STABLE}
'release' => '1.0',
'dependencies' => array(
'qtype_multichoice' => 'any', // {@link ANY_VERSION}
),
),
),
),
);

== Discussion ==

This section contains some leftover notes from the previous versions of this spec to illustrate the background and considered aspects of the design.

Originally there have been several suggestions of how the information about the available updates would be transferred from primary sources to target sites.

; Generated XML files : This was proposed by Petr in October 2009 and is described at the [[Upgrade notification]] page. The format itself (XML) does not matter much and can be replaced by JSON or another format. The pros of this approach is that these files can be generated by a cronjob and cached to improve performance by reducing queries.
; Using the current component_installer : This overlaps the previous approach. As Eloy pointed out, correctly, we already have a system like this in Moodle core. We use it for timezones and language packs at the moment. The pros of this is that we already use it and it seems to work pretty well.
; Using heavy-weight web service : This project seems to be a good opportunity for the new [[Web services|WS]] framework we have. The source of information would expose the functionality via the WS API. REST/JSON format seems to be the way to go. See [[Specification - create a public web service server]].
; Using light-weight web service : As we do not need to cope with the access control here (and need something really cheap in terms of resources and performance), there is actually no need to use the underlying WS subsystem. The service can be produced by a simple script. There is already this approach used at http://lang.moodle.org/local/amos/rest/greylist?format=csv (see [https://github.com/moodlehq/moodle-local_amos/commit/a746fc07edce3d8def644cfab948575b10225448 this commit] to see how it is implemented).
; Combining with current [[:en:Site_registration|site registration]] system : The registration system is used to gather information about sites for statistical purposes. It could be enhanced to return information about current versions.

It is also wise to consider extending the system in the future. We should come up with a solution that is capable of not only providing a list of available updates, but also delivers the source code packages themselves.

=== Gathering statistical information during an update check ===

There is potential to gather information about the Moodle version and plugin versions related to a site.

At the moment, plugin downloads and page views is the only measure of plugin popularity we are capturing. If we can gather real information about plugins installed on sites and the number of instances in use, we can build up a realistic picture of the popularity of plugins, which can be returned as feedback to plugin developers and potential users.

Moodle version information is shared via [[:en:Site_registration|site registration]], however, not all sites register. Perhaps offering this service with a prerequisite of registering will encourage more admins to register, leading to a clearer picture of Moodle use.

The information gathered by this system could be seen as confidential, so it would be necessary to include an opt in/out mechanism similar to, or combined with, the current site registration. If this update notification system is to be constructed separately to the registration system, it may still be possible to gather information about Moodle and plugin versions during a passive update check. If the site transmits a list of plugins and versions, this could be paired to the sender's IP address and retained semi-anonymously.

== See also ==

* [[Automatic updates deployment]] project (since Moodle 2.4).
* [[On-click add-on installation]] project (since Moodle 2.5).

Automatic updates deployment

2025-02-10T07:43:39Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Automatic updates deployment
|state = Completed
|tracker = MDL-35238 and MDL-35239
|discussion = [http://moodle.org/mod/forum/discuss.php?d=211936 Automatic updates deployment]
|assignee = [[User:David Mudrak|David Mudrak]], Eloy Lafuente
}}
{{Moodle 2.4}}

== Use cases ==

[[Image:sue.png|left|Sue the admin]] Meet Sue, a Moodle administrator. She runs her Moodle at a cheap web hosting company where she gets an FTP access only (and some basic web tool to administer one SQL database). No shell access, no way to use Git etc. She never modifies source codes manually. And she likes how Wordpress deals with updates.
 

=== Use case 1 ===

* Sue uploads a new minor Moodle version and executes the upgrade (say from 2.4.0 to 2.4.1)
* At the "Plugins check" screen, there is an info about some available updates. Prior to continuing with the Moodle upgrade, Sue is recommended to deploy new versions for these plugins.
* So she keeps all available plugin updates selected and clicks "Update all selected plugins"
* New versions of selected plugins are downloaded and deployed into wwwroot, replacing the current content (some progress bars and info would be nice to have).
* The "Plugins check" screen is reload again. Now no available updates are reported - those plugins that were reported before are now marked as "To be upgraded"
* Sue presses the "Upgrade Moodle database now" button. Both Moodle core and all plugins are updated.

=== Use case 2 ===

* Sue wants to install a contributed extension into her Moodle.
* Using a new admin tool, she can browse the list of available plugins. She gets the basic information about plugins and can read more about them using a direct link to http://moodle.org/plugins registry.
* When she finds the plugin she is looking for, she presses the button "Download".
* At the next screen, confirms the source URL and the target location. She presses the "Download" button again.
* The ZIP file with the plugin is downloaded. Its MD5 content hash is compared with the expected value. The ZIP is unpacked into the correct location inside wwwroot.
* The browser is redirected to the /admin so the normal upgrade continues as if Sue uploaded the plugin herself.

=== Use case 3 ===

* On Friday morning, Sue gets a regular email generated by her site that a new weekly build is available for her Moodle.
* She likes her site being up-to-date because she knows that up-to-date code is essential for the site security.
* There is a simple way to update whole Moodle via the web. Sue does not need to download the whole pack, unpack it locally and upload it via FTP to her server (in older versions this was very boring job that discouraged Sue from doing it). She is also happy that she does not need to compare the remote side with the ZIP contents to look for files that should be now removed (in older versions this was pretty challenging for her so she often found herself having some old files left at the server).

=== Use case 4 ===

* Bob, a friend of Sue, asks her for an assistance with a fresh Moodle installation. They are having a nice weekend in a beautiful village with very poor internet connectivity. Uploading the whole Moodle pack would take ages.
* Even in this case, there is no need to deal with the download, unzip and upload procedure - Sue just uploads a single small PHP file to the empty wwwroot of Bob's future server.
* Then she visits the script's URL and after providing some details into the form, the script fetches the whole Moodle package, unpacks it and redirects the browser to the /admin so that standard installation can continue.

== Technical issues to deal with ==

* In Use case 1 above, there is a new version of Moodle already uploaded to the server. We are in the middle of the upgrade process. It is generally very tricky to depend on any Moodle functionality in this moment. The code that actually fetches the packages from download.moodle.org must be independent of the Moodle itself. Otherwise, the complex chain of includes would lead to problems. In other words, we can't include config.php to fetch and deploy the ZIPs.
* For the same reasons, the part of the machinery that actually fetches the files from the download.moodle.org server in Use case 3, must be independent of the rest of Moodle. In other words, Moodle can't overwrite its own codes. Don't try it. Bad thing would happen with Gaia.
* In Use case 3, downloading full ~40MB ZIP is not ecological. There might be a way of having "incremental/patch packages" generated for each weekly build that would contain just a subset of files that were modified in that release.
* In Use case 3, we need to put the Moodle site into a hard maintenance mode prior to deploying the code so that there is no chance that a random user visits the site meantime.
* In Use case 4, we need some sort of authentication so that the actual deployment can't be executed by a random visitor (or a bot) that accesses the site before Sue does it. The script might generate a solid strong passphrase (token) into a text file in wwwroot. So that only people having access to the server via FTP can read the passphrase and copy it into the web form.
* Note that we always expect that Sue has its own way of doing full database and moodledata backups prior to any changes. Having an in-built tool to make such backup is out of scope of this project.

== Implementation schedule ==

* Episode IV: Use case 1 is implemented - installed plugins can be updated via the web only (MUST-HAVE for Moodle 2.4) - see [[:en:Automatic updates deployment]]
* Episode III: Use case 2 is implemented - new plugins can be installed (NICE-TO-HAVE for Moodle 2.4, MUST-HAVE for 2.5) - see [[On-click add-on installation]]
* Episode II: Use case 3 is implemented - Moodle core can be updated (NICE-TO-HAVE for 2.5, MUST-HAVE for 2.6)
* Episode I: Use case 4 is implemented - Moodle can be installed from scratch via a bootstrap file (NICE-TO-HAVE for 2.5 or 2.6)

== Implementation plan ==

=== Required components of the machinery ===

* A standalone tool (script) that is able to fetch a ZIP package from a given URL, compare its MD5 content hash with a given value, unpack it, and deploy the content to a given location inside wwwroot.
* Modification of the "Plugins check" and "Plugins overview" admin pages so they provide a way to select available updates and pass required info to the standalone script mentioned above.
* Extending the REST API at the download.moodle.org so that it provides all required info (URL to download the ZIP from and the ZIP's MD5 hash).
* New admin tool that allows the administrator to browse the list of available plugins (compare to the community finder tool that lets you browse the list of available courses

=== Overall logic flow ===

[[image:automatic-update-deploy-1.png]]

There are two places where a plugin update can be ignited from: 1) Plugins check page (in the middle of the upgrade process) and 2) Plugins overview page. We need to be able to ignite the deployment from both places while still re-use as much functionality as possible.

1. Admin looks at say Plugins overview pgae
2. The page script (/admin/index.php) reads a singleton instance of available_update_deployer. It sets its own URL as the caller's URL (this one that actually accepts some params via HTTP) and the return URL.
3. When displaying the available update info, the singleton is used to generate a widget (single buttom currently) "Install this update". Clicking the button lets the admin to review the request (what plugin, where from etc) and confrm the request.
4. When confirmed, the page redirects to a standalone script /mdeploy.php which actually makes the job.
5. The browser is then redirected back to the caller's return URL.

== See also ==

* [[Available update notifications]] project (since Moodle 2.3).
* [[On-click add-on installation]] project (since Moodle 2.5).

Automatic Class Loading Proposal

2025-02-10T07:43:06Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = [[Automatic class loading]]
|state = Integrated
|tracker = MDL-39854
|discussion = https://moodle.org/mod/forum/discuss.php?d=229474
|assignee = [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]]
}}

Automatic class loading is a feature that eliminates manual including of PHP files. It can be implemented only if you can derive the location of class from its name. Usually one class needs to be stored in one file.

This is a proposal for standardisation of class naming and class file storage in Moodle using existing Frankenstyle rules.

==Pros==
* improved coding style
* lower memory footprint
* enforcing of standardised class names and location of source files
* possibility to replace standard classes in local customisations via custom classloader without core modification

==Cons==
* potentially lower performance because current Moodle class names are ambiguous and plugin locations are dynamic, workaround is to start using namespaces and rework plugin listing API

==Namespaces==

PHP 5.3.0 introduced a new concept called namespaces, this feature would significantly simplify the directory structure of classes directory.

Examples:
* new \core\xxx_yyy() ---> in lib/classes/xxx_yyy.php
* new \core\xxx\yyy.php() ---> lib/classes/xxx/yyy.php
* new \core\event\base.php() ---> lib/classes/event/base.php
* new \core\event\something_happened() ---> lib/classes/event/something_happened.php
* new \mod_forum\event\post_rated() ---> mod/forum/classes/event/post_rated.php

Pros:
* very fast
* easy to understand
* fewer backwards compatibility problems

Cons:
* few core developers know it

==Legacy plugin class naming==

The general plugin class name should be:
plugintype_pluginname_typeofclass_someclass

Unfortunately the pluginname part might contain multiple underscores which may lead to various problems.

The algorithm for finding of the class file location from given class name is:
# we have a class ''aaa_bbb_ccc_ddd_eee_fff''
# aaa is always the plugin type, it can not be word core or moodle, ex.: mod, tool, block
# bbb is a candidate for plugin name, if this plugin exists look for file ''bbbdir/classes/ccc_ddd_eee_fff.php''
# if plugin or class does not exist bbb_ccc is another candidate for plugin name, look for ''bbb_cccdir/classes/ddd_eee_fff.php''
# repeat until reaching the limit of underscores in plugin name (5?)

==Legacy core class naming==
The general core class name should be:
core_optionalsubsystem_typeofclass_someclass

The algorithm for finding of the class file location from given class name is:
# we have a class ''core_aaa_bbb_ccc''
# look for file ''/lib/classes/aaa_bbb_ccc.php''

We could also hardcode exception for non-frankenstyle class names and custom file locations.

==Potential candidates==
* new events classes
* admin settings in plugins
* any new core feature implemented using OOP
* internal implementation of add-ons
* some existing core subsytems
* some existing plugins that already use these rules (ex.: tinymce plugins)

==Backwards compatibility==
There should not be any significant problems because the classes subdirectory is searched only if class not already included - classloader is used only for missing classes. Please note this proposal does not change Frankenstyle class naming rules for plugins in any way.

We should probably require the use of automatic class loading only in new APIs and let add-on developers decide the rest for themselves. It is also technically possible to migrate some existing classes from lib.php files to /classes/ while keeping 100% backwards compatibility.

==Implementation steps==
# Finalise rules for class names, class file names and locations.
# Implement basic loader using current (slow) plugin API.
# Improve performance and stability by rewriting get_plugin_types(), get_plugin_list() and friends.
# Frankenstyle plugin info API should be self contained without any dependencies.

==Frequently asked questions==

; Why not use existing class loading standard? : The proposal builds on top of PSR-0, but it must take into account our ambiguous plugin naming rules and dynamic plugin locations.
; Is it compatible with 3rd party libraries? : Most probably yes, Frankenstyle was supposed to resolve this. This biggest current problem are short names without the "core_" prefix, this proposal would finally require all new core things to start with "core_". It is unlikely that other projects use frankenstyle in top most namespace.
; Is this compatible with other classloaders? : Yes. spl_autoload_register() supports multiple class loaders, Frankenstyle loader should be the last one because it will be most expensive.
; Is this compatible with code obfuscators? : No! Moodle already breaks with them and we will never support it. This is GPL, there is no reason to hide anything.
; Why only one class per file? : Because it makes things easier for everybody.

==See also==
* http://php.net/manual/en/language.oop5.autoload.php
* http://www.php.net/manual/en/function.spl-autoload-register.php
* https://tracker.moodle.org/browse/MDLSITE-2261
* [[Events API]]
* [[Frankenstyle]]
* [[Automatic class loading]]

Audio/Video Capture repository plugin

2025-02-10T07:40:51Z

Sarjona: This page will not be migrated to new devdocs

{{Template:WillNotMigrate}}

{{Infobox Project
|name = Audio/Video Capture repository plugin
|state = Coding Period
|tracker = CONTRIB-3631
|discussion = [http://moodle.org/mod/forum/discuss.php?d=202632#p883953 Forum - Post]
|assignee = Ankit Gupta
}}
{{Moodle 2.3}}

GSOC
 '12


== Introduction ==
Audio/Video Capture repository plugin is of great utility to both teachers and students. Teachers can directly submit assignments or record audio/video lectures for the students. This project is for the implementation of the Audio/Video Capture repository plug-in which enables users to directly capture and upload their audio/video files to the server.

== Requirements ==
Moodle 2.3 required

== Project Details ==
=== Description ===
The ’A/V recorder’ module will use the Repository API and its own small API for integration of sound and video recording components and web services with Moodle. The module would have a UI which would receive requests for recording media. The A/V Module calls the ‘record’ module. The recorded media is then converted to a proper format (using ImaACPCM or Speex codecs) to be saved to the Moodle servers. The file is then uploaded to the servers by either using the existing plugins or a new module is created to accomplish the task. The module then saves the file name/location in the database. During the above operations the module would inherently interact with the Moodle Interface for various data operations/inter-module interactions.

=== Implementation ===
I would be extending the NanoGong Java Applet to record, playback and save the content to web-pages for Moodle 2.0. The NanoGong applet is quite well-suited for the project and currently supports audio recording. NanoGong provides an extended HTML editor which would be integrated with the current editor provided by the default Moodle installation everywhere. Below are some of the prospects of using the applet (as mentioned in the NanoGong documentation)

The editor would be customizable from the back-end with varying permissions for students, teachers and administrators over the record, playback and speed controls. The functionality will be as follows :

For students using Moodle :
Students can submit their voice/video messages using the extended html editor. These messages can be deleted and changed provided it is not locked by the corresponding teacher giving the assignment.

For teachers using Moodle :
Teacher can view all the messages submitted and choose to lock/change or assign score to a given assignment based on the message. Alternatively the applet can be used by teachers to record video/audio lectures.

As for the Video part, no known open source alternatives exists currently for a video recording Java Applet. I have taken a good look at Vimas, the enterprise Applet for Video capturing and would look to build something on those lines. The video recording applet would allow recording videos in mp4 format (H.264 video and AAC audio) on the web page and upload it on the web server via HTTP. I would be using the Java Media Framework (JMF) to capture the audio and video stream.

=== Schedule of Deliverables ===

'''Pre-phase''' (10th May - 21st May) :
Pre-phase would involve assembling all the pre-requisites for the coding period. Talking to the mentors and reading the documentation to be in good stead before the coding period begins.
Also maintaining a blog to track day to day progress and track reviews by mentors, would be done during this period.

'''First-phase''' (21st May - 9th July)
Deliverables :

21st May - 28th May
Code the entire framework for the plugin. Build a basic back bone wherein addition of these media capture modules can be easily done.

29th May - 4th June
Port the NanoGong applet to Moodle 2.0 and integrate the functionality within the module.

5th June - 19th June
Complete the Audio Plugin Front-end and back-end which manages permissions for audio recording for students, teachers, various options for playback, save and speed control.

20th June - 9th July
Look for open-source alternatives for Vimas and start the development/integration of the Video plugin in to the Module.

'''Second-phase''' (11th July - 1st August)
Deliverables :

11th July - 18th July
Entire back-end + front-end for the module should be complete.

19th July - 25th July
Customize the Video plug-in and test the support for different frames and audio/video quality on various browsers.

26th July - 1st August
Extra time for full implementation of the Video plug-in . This would involve intensive testing and bug-fixing.

'''Post-phase''' (12th August - 20th August) :
This period is exclusively reserved for final testing, minor bug fixes or enhancements to the front-end, documentation of the entire code, review from the mentors and minor changes to the code.

== Relevant Links ==
=== Ideas List ===
* [https://docs.moodle.org/dev/Projects_for_new_developers Moodle - Google Summer of Code 2012 Idea List]
=== Tracker ===
* [http://tracker.moodle.org/browse/CONTRIB-3631 An Audio/Video Capture repository plug-in]
=== GSoC Proposal ===
* [http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/ankitgupta_/1 Original Proposal - GSoC 2012]
=== Developer Blog ===
* [http://ankitgupta90.tumblr.com/ # Ankit Gupta]