MoodleDocs - User contributions [en]

Moodle Mobile Push Notifications

2016-06-04T06:38:29Z

Msoni: /* brainstorming use case */

==Goal==
Moodle Mobile should receive Moodle messages as push notifications on iOS and Android.

== Use case and web services ==
[[Image:Screenshot_2_05_13_5_16_PM.png|thumb]]
[[Image:Screenshot_2_05_13_5_14_PM.png|thumb]]
=== currently implemented use case ===
# The user opens the app and accepts to receive push notifications. The app contacts Apple push notification server and gets a device token. The mobile app PushPlugin plugin does it.
# The user enters its Moodle credentials. The app gets an [http://airnotifier.github.io AirNotifier] access key from the site. (note that this access key is currently the same for each site => meaningless). The key is retrieved by calling the webservice message_airnotifier_get_access_key(permissions). create_token is the only possible permission at the moment.
# The app sends its token to [http://airnotifier.github.io AirNotifier] server - it's done by a HTTP POST request.
# The app registers its device to the site - it's done by a ws call message_airnotifier_add_user_device(appname, devicetoken, devicename)
# Someone/Something triggers a Moodle message. [http://airnotifier.github.io AirNotifier] provider (Moodle site) sends a payload for a specific device token to airnotifier server - it's done by a HTTP POST
# The user receive the notification.

=== brainstorming use case ===
# During [http://airnotifier.github.io AirNotifier] provider installation, the site contacts Airnotifer server to request an access key for itself + an access key for the devices (to send their device token to [http://airnotifier.github.io AirNotifier] server).
# The user opens the app and accepts to receive push notifications. The app contacts Apple push notification server and gets a device token.
# The user enters its Moodle credentials. The app gets an [http://airnotifier.github.io AirNotifier] access key from the site. It's done calling the webservice message_airnotifier_get_access_key(type). An admin could request the site access key, the others only get the device access key.
# The app sends its device token to [http://airnotifier.github.io AirNotifier] server + the site url (so airnotifier knows the device/site couple, and so [http://airnotifier.github.io AirNotifier] can allow site broadcast) - it's done by a HTTP POST request.
# The app registers its device to the site - it's done by a ws call message_airnotifier_add_user_device(appname, devicetoken, devicename)
# During this web service, the site confirms the device token to [http://airnotifier.github.io AirNotifier]. It's done by a HTTP POST request. [http://airnotifier.github.io AirNotifier] server deletes unconfirmed device tokens older than one minute every hours.
# Someone/Something triggers a Moodle message. [http://airnotifier.github.io AirNotifier] provider (Moodle site) sends a payload for a specific device token to airnotifier server - it's done by a HTTP POST
# Time to time, the [http://airnotifier.github.io AirNotifier] server checks Apple feedback and delete the unactive device tokens.
# When the [http://airnotifier.github.io AirNotifier] provider tries to send a message to a deleted device, it receive an error from [http://airnotifier.github.io AirNotifier] server and stores it. Then it sends a unique alert to the device user. The device is disabled on the user messaging settings. After a month, the cron processes delete the device.

=== another brainstorming use case ===
# All the sites (public or privately) already registered in Moodle.net will have automatically keys for using [http://airnotifier.github.io AirNotifier]
# When registering a new site in Moodle.net there will be a new option for enabling PUSH Notificiations (true by default)
# If your site is not registered and your Mobile Services were enabled you will see a message in the Moodle Notifications page indicating that "You must register your site in order to be able to send PUSH Notifications"
# If your site is not registered and you enable Mobile Services you will see a message near to the "Enable Mobile Services" indicating that "You must register your site in order to be able to send PUSH Notifications"
# If your installation has a very big number of users, during the registration process and in the Notifications page you will see a message indicating "The public PUSH Notification server is limited to Moodle sites with less than N (5k, 20k...) users"
# The user opens the app and accepts to receive push notifications. The app contacts Apple push notification server and gets a device token. A user can disable at any time notifications for his device
# Every time the user open the app, the app gets an [http://airnotifier.github.io AirNotifier] access key from the site. It's done calling the webservice message_airnotifier_get_access_key(type). An admin could request the site access key, the others only get the device access key.
# The app sends its device token to [http://airnotifier.github.io AirNotifier] server + the site url (so airnotifier knows the device/site couple, and so [http://airnotifier.github.io AirNotifier] can allow site broadcast) - it's done by a HTTP POST request. This is done only if your device token has changed.
# The app registers its device to the site - it's done by a ws call message_airnotifier_add_user_device(appname, devicetoken, devicename, siteURL) This is done every time a user opens the app
# Since the app is sending its device token every time a user opens the app, a cron job in the Moodle Site can delete old device tokens (so we can avoid the [http://airnotifier.github.io AirNotifier] feedback service in the first stage)
# Someone/Something triggers a Moodle message. [http://airnotifier.github.io AirNotifier] provider (Moodle site) sends a payload for a specific device token + specific site to airnotifier server - it's done by a HTTP POST
# If the user disable the PUSH Notification feature, a WS message_airnotifier_remove_user_device is called, also the [http://airnotifier.github.io AirNotifier] is requested to delete the user device

Benefits are:
-We can reuse the current registration process that is secure (as far as I know)
-The [http://airnotifier.github.io AirNotifier] API for register new sites will be exposed only to Moodle.net (not to all sites)
-It will be easier notify registered sites that are abusing (Moodle.net can communicate with sites (sending an automatic email to the user admin))
-Moodle will have statistics of sites using PUSH directly in Moodle.net (no need to ask [http://airnotifier.github.io AirNotifier])
-The registration process can be improved to retrieve the number of registered devices that are receiving notifications
-I think that it will "enforce" users to register their sites (for receive security notifications, etc..)
-Big companies with big Moodle installations usually doesn't register their Moodle sites, this will force these companies to use their own [http://airnotifier.github.io AirNotifier] server instance
-Since we have the number of users in a Moodle site, we can automatically disable [http://airnotifier.github.io AirNotifier] for big installations (more thant Nk users)
-I think that having all the information that the registration provides will help us to "monitor and prevent abuse" of the [http://airnotifier.github.io AirNotifier] server

== Payload content ==
The current payload content would need a bit of brainstorming. We need to identify what to send as it is extremely short. The app will behave following the content it receives.
=== Apple ===
The Apple payload is limited to 256bytes and it includes everything sent. Our current implementation is still quite of a wip:
<code php>
{type:'moodle_instantmessage',id:'8',urlparams:'{"user":"2","id":"8"}',userfrom:'Manager Moodle',date:'1367477362',alert:'This is a message text.',}
</code>
=== GCM ===
The Apple payload is about 4Kb. As it's more more permissive than Apple, it is not an issue. The content will be the same than Apple ones, just the format changes.

==Deliverables==
* push notification support on the mobile app - the app receives the push notification and behaves correctly.
* The [http://airnotifier.github.io AirNotifier] server - it sends notification to APNS / GCM.
* The [http://airnotifier.github.io AirNotifier] provider - it sends Moodle messages to [http://airnotifier.github.io AirNotifier] - MDL-36445

=== [http://airnotifier.github.io AirNotifier] messaging provider ===
In your messaging setting page you can select which of your devices can receive push notifications. MDL-36445
The provider has usual messaging provider settings.

=== [http://airnotifier.github.io AirNotifier] server ===
To install the server follow: https://github.com/airnotifier/airnotifier/wiki/Installation

Need to be done:
* feedback - MOBILE-191
* load stress
* IP banning - need to be tested MOBILE-192
* Site broadcast (site keys) MOBILE-395
* DDOS attacks
* iOS support - it works
* Android support MOBILE-396

=== App push notification support in the mobile app ===
MOBILE-168

==== The app is closed or is running in the background ====
It's a normal OS notification. The user can open the app from it. We need to define what happens when we open the app. See payload content section.

==== The app is opened ====
The app displays a notification popup. Or better, it's a small temporary notification message at the top that retarct by itself - less intrusive.

== Risks ==
These risks have been raised by Dan in MDL-36445:
* Have we load tested it with large numbers of users/notifications?
* What is stopping someone downloading Moodle getting the keys to DOS our push notification service (surely blacklisting us with apple)
* If someone gains access to device ids, could they then use our service to spam users?
* Are we checking the 'feedback service' and removing devices which no longer exist, apple ominously writes "Note: APNs monitors providers for their diligence in checking the feedback service and refraining from sending push notifications to nonexistent applications on devices."

== Improvements ==
See Apu's comment in https://tracker.moodle.org/browse/MDL-36445?focusedCommentId=200343&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-200343.
Specially the mention about language.

Moodle Mobile Push Notifications

2016-06-04T06:36:17Z

Msoni: /* brainstorming use case */

==Goal==
Moodle Mobile should receive Moodle messages as push notifications on iOS and Android.

== Use case and web services ==
[[Image:Screenshot_2_05_13_5_16_PM.png|thumb]]
[[Image:Screenshot_2_05_13_5_14_PM.png|thumb]]
=== currently implemented use case ===
# The user opens the app and accepts to receive push notifications. The app contacts Apple push notification server and gets a device token. The mobile app PushPlugin plugin does it.
# The user enters its Moodle credentials. The app gets an [http://airnotifier.github.io AirNotifier] access key from the site. (note that this access key is currently the same for each site => meaningless). The key is retrieved by calling the webservice message_airnotifier_get_access_key(permissions). create_token is the only possible permission at the moment.
# The app sends its token to [http://airnotifier.github.io AirNotifier] server - it's done by a HTTP POST request.
# The app registers its device to the site - it's done by a ws call message_airnotifier_add_user_device(appname, devicetoken, devicename)
# Someone/Something triggers a Moodle message. [http://airnotifier.github.io AirNotifier] provider (Moodle site) sends a payload for a specific device token to airnotifier server - it's done by a HTTP POST
# The user receive the notification.

=== brainstorming use case ===
# During [http://airnotifier.github.io AirNotifier] provider installation, the site contacts Airnotifer server to request an access key for itself + an access key for the devices (to send their device token to [http://airnotifier.github.io AirNotifier] server).
# The user opens the app and accepts to receive push notifications. The app contacts Apple push notification server and gets a device token.
# The user enters its Moodle credentials. The app gets an [http://airnotifier.github.io AirNotifier] access key from the site. It's done calling the webservice message_airnotifier_get_access_key(type). An admin could request the site access key, the others only get the device access key.
# The app sends its device token to [http://airnotifier.github.io AirNotifier] server + the site url (so airnotifier knows the device/site couple, and so [http://airnotifier.github.io AirNotifier] can allow site broadcast) - it's done by a HTTP POST request.
# The app registers its device to the site - it's done by a ws call core_user_add_user_device(appname, devicetoken, devicename)
# During this web service, the site confirms the device token to [http://airnotifier.github.io AirNotifier]. It's done by a HTTP POST request. [http://airnotifier.github.io AirNotifier] server deletes unconfirmed device tokens older than one minute every hours.
# Someone/Something triggers a Moodle message. [http://airnotifier.github.io AirNotifier] provider (Moodle site) sends a payload for a specific device token to airnotifier server - it's done by a HTTP POST
# Time to time, the [http://airnotifier.github.io AirNotifier] server checks Apple feedback and delete the unactive device tokens.
# When the [http://airnotifier.github.io AirNotifier] provider tries to send a message to a deleted device, it receive an error from [http://airnotifier.github.io AirNotifier] server and stores it. Then it sends a unique alert to the device user. The device is disabled on the user messaging settings. After a month, the cron processes delete the device.

=== another brainstorming use case ===
# All the sites (public or privately) already registered in Moodle.net will have automatically keys for using [http://airnotifier.github.io AirNotifier]
# When registering a new site in Moodle.net there will be a new option for enabling PUSH Notificiations (true by default)
# If your site is not registered and your Mobile Services were enabled you will see a message in the Moodle Notifications page indicating that "You must register your site in order to be able to send PUSH Notifications"
# If your site is not registered and you enable Mobile Services you will see a message near to the "Enable Mobile Services" indicating that "You must register your site in order to be able to send PUSH Notifications"
# If your installation has a very big number of users, during the registration process and in the Notifications page you will see a message indicating "The public PUSH Notification server is limited to Moodle sites with less than N (5k, 20k...) users"
# The user opens the app and accepts to receive push notifications. The app contacts Apple push notification server and gets a device token. A user can disable at any time notifications for his device
# Every time the user open the app, the app gets an [http://airnotifier.github.io AirNotifier] access key from the site. It's done calling the webservice message_airnotifier_get_access_key(type). An admin could request the site access key, the others only get the device access key.
# The app sends its device token to [http://airnotifier.github.io AirNotifier] server + the site url (so airnotifier knows the device/site couple, and so [http://airnotifier.github.io AirNotifier] can allow site broadcast) - it's done by a HTTP POST request. This is done only if your device token has changed.
# The app registers its device to the site - it's done by a ws call message_airnotifier_add_user_device(appname, devicetoken, devicename, siteURL) This is done every time a user opens the app
# Since the app is sending its device token every time a user opens the app, a cron job in the Moodle Site can delete old device tokens (so we can avoid the [http://airnotifier.github.io AirNotifier] feedback service in the first stage)
# Someone/Something triggers a Moodle message. [http://airnotifier.github.io AirNotifier] provider (Moodle site) sends a payload for a specific device token + specific site to airnotifier server - it's done by a HTTP POST
# If the user disable the PUSH Notification feature, a WS message_airnotifier_remove_user_device is called, also the [http://airnotifier.github.io AirNotifier] is requested to delete the user device

Benefits are:
-We can reuse the current registration process that is secure (as far as I know)
-The [http://airnotifier.github.io AirNotifier] API for register new sites will be exposed only to Moodle.net (not to all sites)
-It will be easier notify registered sites that are abusing (Moodle.net can communicate with sites (sending an automatic email to the user admin))
-Moodle will have statistics of sites using PUSH directly in Moodle.net (no need to ask [http://airnotifier.github.io AirNotifier])
-The registration process can be improved to retrieve the number of registered devices that are receiving notifications
-I think that it will "enforce" users to register their sites (for receive security notifications, etc..)
-Big companies with big Moodle installations usually doesn't register their Moodle sites, this will force these companies to use their own [http://airnotifier.github.io AirNotifier] server instance
-Since we have the number of users in a Moodle site, we can automatically disable [http://airnotifier.github.io AirNotifier] for big installations (more thant Nk users)
-I think that having all the information that the registration provides will help us to "monitor and prevent abuse" of the [http://airnotifier.github.io AirNotifier] server

== Payload content ==
The current payload content would need a bit of brainstorming. We need to identify what to send as it is extremely short. The app will behave following the content it receives.
=== Apple ===
The Apple payload is limited to 256bytes and it includes everything sent. Our current implementation is still quite of a wip:
<code php>
{type:'moodle_instantmessage',id:'8',urlparams:'{"user":"2","id":"8"}',userfrom:'Manager Moodle',date:'1367477362',alert:'This is a message text.',}
</code>
=== GCM ===
The Apple payload is about 4Kb. As it's more more permissive than Apple, it is not an issue. The content will be the same than Apple ones, just the format changes.

==Deliverables==
* push notification support on the mobile app - the app receives the push notification and behaves correctly.
* The [http://airnotifier.github.io AirNotifier] server - it sends notification to APNS / GCM.
* The [http://airnotifier.github.io AirNotifier] provider - it sends Moodle messages to [http://airnotifier.github.io AirNotifier] - MDL-36445

=== [http://airnotifier.github.io AirNotifier] messaging provider ===
In your messaging setting page you can select which of your devices can receive push notifications. MDL-36445
The provider has usual messaging provider settings.

=== [http://airnotifier.github.io AirNotifier] server ===
To install the server follow: https://github.com/airnotifier/airnotifier/wiki/Installation

Need to be done:
* feedback - MOBILE-191
* load stress
* IP banning - need to be tested MOBILE-192
* Site broadcast (site keys) MOBILE-395
* DDOS attacks
* iOS support - it works
* Android support MOBILE-396

=== App push notification support in the mobile app ===
MOBILE-168

==== The app is closed or is running in the background ====
It's a normal OS notification. The user can open the app from it. We need to define what happens when we open the app. See payload content section.

==== The app is opened ====
The app displays a notification popup. Or better, it's a small temporary notification message at the top that retarct by itself - less intrusive.

== Risks ==
These risks have been raised by Dan in MDL-36445:
* Have we load tested it with large numbers of users/notifications?
* What is stopping someone downloading Moodle getting the keys to DOS our push notification service (surely blacklisting us with apple)
* If someone gains access to device ids, could they then use our service to spam users?
* Are we checking the 'feedback service' and removing devices which no longer exist, apple ominously writes "Note: APNs monitors providers for their diligence in checking the feedback service and refraining from sending push notifications to nonexistent applications on devices."

== Improvements ==
See Apu's comment in https://tracker.moodle.org/browse/MDL-36445?focusedCommentId=200343&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-200343.
Specially the mention about language.

Local plugins

2012-06-15T04:02:18Z

Msoni:

{{Infobox Project
|name = Local customisations
|state = Implemented
|tracker = MDL-17376, MDL-16438
|discussion = http://moodle.org/mod/forum/discuss.php?d=126017 http://moodle.org/mod/forum/discuss.php?d=86903
|assignee = [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]], some parts were originally proposed and implemented in 1.9 by Penny Leach
}}
{{Moodle 2.0}}

The recommended way to add new functionality to Moodle is to create a new standard plugin (module, block, auth, enrol, etc.).The /local/ plugins are mostly suitable for things that do not fit standard plugins.

== Custom /local/ plugins ==

Local plugins are used in cases when no standard plugin fits, examples are:
* event consumers communicating with external systems
* custom definitions of web services and external functions
* applications that extend moodle at the system level (hub server, amos server, etc.)
* new database tables used in core hacks (discouraged)
* new capability definitions used in core hacks
* custom admin settings
* extending the navigation block with custom menus [http://moodle.org/mod/forum/discuss.php?d=170325&parent=753095]

=== Standard plugin features: ===
* /local/xxx/[[version.php]] - version of script (must be incremented after changes)
* /local/xxx/db/install.xml - executed during install (new version.php found)
* /local/xxx/db/install.php - executed right after install.xml
* /local/xxx/db/uninstall.php - executed during uninstallation
* /local/xxx/db/upgrade.php - executed after version.php change
* /local/xxx/db/access.php - definition of capabilities
* /local/xxx/db/events.php - event handlers and subscripts
* /local/xxx/db/messages.php - messaging registration
* /local/xxx/db/external.php - web services and external functions descriptions
* /local/xxx/cron.php - cron job, run at the interval defined in version.php. Alternatively, you can define <tt>local_xxx_cron()</tt> in lib.php. (The lib.php method is now preferred.)
* /local/xxx/lang/en/local_pluginname.php - language file
* /local/xxx/lib.php - function library, automatically included with by config.php
* /local/xxx/settings.php - configuration options. These get added to the admin menu.

The ''xxx'' is used instead of your local plugin name, plugins of the same type are installed/upgraded in alphabetical order.

=== List of differences from normal plugins: ===
* always executed last during install/upgrade - guaranteed by order of plugins in <code>get_plugin_types()</code>
* are expected to use event handlers - events are intended for communication core-->plugins only, local plugins are the best candidates for event handlers
* can add admin settings to any settings page - loaded last when constructing admin tree
* do not need to have any UI - other plugins are usually visible somewhere
* some extra hooks (not implemented yet)

== /local/xxx/db/messages.php ==
Example File Structure:
<code php>
<?php

/**
* Defines message providers (types of messages being sent)
*
* @package mod-forum
* @copyright 1999 onwards Martin Dougiamas http://moodle.com
* @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
*/

$messageproviders = array (

/// Ordinary single forum posts
'posts' => array (
)

);
</code>

== Other /local/ customisation files==

===Customised site defaults===

Different default site settings can be stored in file /local/defaults.php.
These new defaults are used during installation, upgrade and later are
displayed as default values in admin settings. This means that the content
of the defaults files is usually updated BEFORE installation or upgrade.

These customised defaults are useful especially when using CLI tools
for installation and upgrade.

Sample /local/defaults.php file content:
<code php>
<?php
$defaults['moodle']['forcelogin'] = 1; // new default for $CFG->forcelogin
$defaults['scorm']['maxgrade'] = 20; // default for get_config('scorm', 'maxgrade')
$defaults['moodlecourse']['numsections'] = 11;
$defaults['moodle']['hiddenuserfields'] = array('city', 'country');
</code>
First bracket contains string from column plugin of config_plugins table.
Second bracket is the name of setting. In the admin settings UI the plugin and
name of setting is separated by "|".

The values usually correspond to the raw string in config table, with the exception
of comma separated lists that are usually entered as real arrays.

Please note that not all settings are converted to admin_tree,
they are mostly intended to be set directly in config.php.

=== 2.0 pre-upgrade script===

You can use /local/upgrade_pre20.php script for any code that needs to
be executed before the main upgrade to 2.0. Most probably this will
be used for undoing of old hacks that would otherwise break normal
2.0 upgrade.

This file is just included directly, there does not need to be any
function inside. If the execution stops the script is executed again
during the next upgrade. The first execution of lib/db/upgrade.php
increments the version number and the pre upgrade script is not
executed any more.

== Customisations outside of /local/ directory==

=== Forced settings===

Sometimes it is useful to force some settings and prevent any changes of these settings via the standard admin UI. It is possible to hardcode these settings in config.php.

In case of course settings it is very simply, the values are assigned directly to $CFG properties. In case of plugins the values are specified in a multidimensional array in $CFG->force_plugin_settings.

Sample code in config.php
<code php>
$CFG->allowobjectembed = 0;
$CFG->forced_plugin_settings = array('page'=>array('displayoptions'=>5, 'requiremodintro'=>1), 'folder'=>array('requiremodintro'=>1));
</code>

=== Local language customisations===

Moodle supports other type of local customisation of standard language
packs. If you want to create your own language pack based on another
language create new dataroot directory with "_local" suffix, for example
following file with content changes string "Login" to "Sign in":
moodledata/lang/en_local
<code php>
<?php
$string['login'] = 'Sign in';
</code>
See also https://docs.moodle.org/en/Language_editing

=== Custom script injection===

Very old customisation option that allows you to modify scripts by injecting
code right after the require 'config.php' call.

This setting is enabled by manually setting $CFG->customscripts variable
in config.php script. The value is expected to be full path to directory
with the same structure as dirroot. Please note this hack only affects
files that actually include the config.php!

; Examples:
* disable one specific moodle page without code modification
* alter page parameters on the fly

=== Direct code modifications===
This is usually the last resort, if possible do not do it. And if you still do it use some version control system (preferably git).

=== Direct database modifications===
Very strongly discouraged! Sometimes field lengths may be modified without side effects. Adding or removing of db fields will most probably cause major problems during future upgrades. New database tables should be added only from plugins.

== Local customisations in previous versions ==
Previous versions include only partial support for customisations in /local/ directory.

=== List of local customisations in 1.9.x: ===
* /local/cron.php - custom cron jobs
* /local/settings.php - custom admin settings
* /local/db/upgrade.php - general modifications
* /local/lang/* - custom strings
* /local/lib.php - local_delete_course()

=== Migration from old 1.9.x /local/: ===
* <code>local/*</code> needs to be copied to new directory
* <code>local/xxxx/db/install.php</code> is intended for first installation, originally everything was in upgrade.php
* events are used instead of hooks
* upgrade code needs to migrate old settings, events, etc. directly in core db tables - such as change component strings and capability names from db/install.php or manually before/after upgrade

==See also==

* [http://moodle.org/mod/forum/discuss.php?d=170325&parent=753095 Extending navigation block]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=86903 Local Customisations] forum discussion
* http://cvs.moodle.org/moodle/local/readme.txt?view=markup
* [[Local customisation (Moodle 1.9)]]

[[Category:Plugins]]