This is a Moodle plugin that has hooks into activity modules to facilitate a dialog between a user and configured roles for requesting a submission extension to the module.
Install the plugin the same as any standard moodle plugin either via the Moodle plugin directory, or you can use git to clone it into your source:
git clone git@github.com:central-queensland-uni/moodle-local_extension.git local/extension
Or install via the Moodle plugin directory: https://moodle.org/plugins/local_extension
Then run the Moodle upgrade.
If you have issues please log them in github here: https://github.com/central-queensland-uni/moodle-local_extension/issues
Initially please review the two main configurable pages.
Dashboard ► Site administration ► Plugins ► Local Plugins ► Activity extensions ►
General settings
Manage Adapter Triggers
The plugin will not appear to be active until there is one rule configured
in the settings page Manage Adapter Triggers
.
When a user requests an extension it searches the calendar for suitable activities.
Sometimes you want to make a request in the future. A dropdown select is available on the request page to extend the search length.
During debugging this option will prevent email notifications from the plugin.
When a user makes a request, the email will be said to be sent from this name.
When making a request you may wish to provide a banner / policy message to the user.
Allow the user to make a request in the following contexts.
Limit the length of an initial request.
Enforce the requirement for providing supporting documentation when creating a request.
When loading the the rules available to a request, ignore the datatype restriction and obtain all rules in the system.
This task is scheduled to run every hour. It will process the rules for each request in an open state.
For a request to be in an open state, there must be at least one course module item in the state 'New' or 'Reopened'.
This allows the user to view all requests in the system and act upon them.
This allows the user to modify the request length regardless of their access level.
This is used to identify the rule.
When rules are at the root level or on child branches in the tree, this is the order of execution for the rules.
This allows rules to be nested in a parent/child relationship. A rule will not be considered for execution unless its parent has been triggered.
This is the length of the request in days.
This is how long the request has existed in the system. Useful for providing update notifications after an amount of days.
Approve: Grants the roles specified the ability to approve the status of the request or modify the length.
Subscribe: Grants the roles specified to read and comment on the request only.
Force Approve: This option is used when nested rules have been setup. Each time a child rule is triggered, it will downgrade the previous roles from Approval to Subscribe. When this setting is enabled those roles will not have their access level downgraded.
Send the roles that have been subscribed to this request with the specified template. A notification will not be sent if this is empty.
Send the user that has made the request with the specified template. A notification will not be sent if this is empty.
Rule 1
Rule 2
Rule 3
An overview of these rules.
Rule 1. When a request is made that is less than 15 days in length, Teachers will be subscribed with approval access and notified. If the request was less than 15 days in length but one of the approval roles modified the length to be greater than 15 days, then Rule 2 will trigger.
Rule 2. Due to the request now being 15 days or greater in length and the parent Rule 1 has been triggered then the Teacher roles will have their access downgraded to Subscribe only.
Rule 3. When a request is made that is greater or equal to 15 days in length, Managers will be subscribed with approval access and notified.