Notifying
Trigger adjustments are limited to administrator users but this can be changed. Standard users can be granted more control.
By default, only users with administrator privileges can affect pending triggers. Administrators can adjust or cancel any pending trigger.
Standard users, those without administrator privileges for the computer, can not adjust or cancel pending triggers.
When some non-administrator control is required, we recommend minimising the rights granted to non-administrator users. Do not grant rights to non-administrator without careful consideration of the consequences. Instead, edit event triggers to allow greater control to non-administrator users.
Adjustments by non-administrators
Sometimes it is desirable to give standard users the ability to make limited adjustments. This is possible by editing a trigger’s fields.
Time and date based triggers offer two optional fields:
notify postpone;notify cancel.
You can add and remove these optional fields from triggers using Power Manager’s event editor.
Enabling either or both of these fields allows non-administrator users to affect the trigger when it is notifying. Administrators will continue to be able to make any changes; administrators are not affected by these optional notify fields.
Time sensitive control
It is often desirable to allow the active user some ability to delay or cancel immediately due triggers.
Consider the situation where a shut down is scheduled to occur in ten minutes but the user needs a little more time to complete their work. Allowing the user to postpone the shut down is helpful; so long as the postponement is limited in duration and only possible close to the due time. This is possible with a per-trigger change.
Power Manager can allow standard users to postpone, and even cancel, pending triggers in specific situations. Power Manager can also enforce constraints on the length of any postponement.
If the user does not have administator rights to adjust, cancel, or reset pending triggers, then Power Manager checks the trigger.
If the trigger has either the notify postpone or notify cancel fields set to true, then any user can affect that trigger, but only while the trigger is notifying. When the trigger is not notifying, non-administrator users can not make any adjustments.
This behaviour offers the current user, who will be affected by the pending trigger, some control. The same behaviour limits the current user from affect triggers that are still pending but not yet close in time.
Note that these fields do not affect pending triggers that are not notifying or that do not notify.
Schedules can contain a combination of:
- quiet triggers that do not notify and can not be adjusted;
- notifying triggers than can not be adjusted;
- and notifying triggers that can be adjusted.
Postpone
In most cases, adding the notify postpone field to your triggers will provide the behaviour you need.
A notifying trigger with this field can be postponed by any user. This is similar to being adjusted but with constraints:
- The pending trigger must be within the notify period and thus notifying;
- Postpone can not advance the trigger closer in time beyond its original due date;
- Postpone can not delay the trigger further in time beyond the postpone period, relative to the trigger’s original due date.
Postpone Period
The maximum time a notifying trigger can be postponed is controlled by the postpone period.
The default postpone period is an hour. This can be changed using the request notifications.setpostponeperiod and providing the number of seconds to use.
The current postpone period, in seconds, can be read with the pmctl command:
./pmctl -format json notifications.postponeperiod
To set the postpone period to 15 minutes (900 seconds):
./pmctl notifications.setpostponeperiod seconds:integer=900
To reset the postpone period to the default duration, omit the seconds parameter:
./pmctl notifications.setpostponeperiod
Complete control to make adjustments
In rare situations non-administrators require complete control to adjust pending triggers. This is possible with Power Manager. Granting the rights below allows users to affect all pending triggers, regardless of their time in the future and notifying state.
The signatures of the Power Manager rights controlling who can make adjustments are:
scheduler.adjustscheduler.cancelscheduler.reset
These rights are associated with their API requests that enact the adjustments. By default, only administrators have these rights.
You can confirm this using the pmctl command below:
./pmctl -format json authorisation.rights
This command outputs a JSON formatted list which includes the items:
[{
"default rule": "administrator",
"rule": "administrator",
"signature": "scheduler.cancel"
},
{
"default rule": "administrator",
"rule": "administrator",
"signature": "scheduler.adjust"
},
{
"default rule": "administrator",
"rule": "administrator",
"signature": "scheduler.reset"
}]
Granting adjust, cancel, and reset rights
To grant non-administrator users the right to adjust, cancel, or reset pending triggers use the commands below.
These rights can be granted individually. There is no requirement to grant all three.
To grant adjust rights:
./pmctl authorisation.applyright signature=scheduler.adjust rule=universal
To grant cancel rights:
./pmctl authorisation.applyright signature=scheduler.cancel rule=universal
To grant reset rights:
./pmctl authorisation.applyright signature=scheduler.reset rule=universal
To grant adjust, cancel, and reset rights in a single command:
./pmctl authorisation.applyright signature=scheduler.adjust rule=universal authorisation.applyright signature=scheduler.cancel rule=universal authorisation.applyright signature=scheduler.reset rule=universal
Changes to rights take effect immediately. To confirm the rights have been applied as desired, list and check them using the command:
./pmctl -format json authorisation.rights
Resetting adjust, cancel, and reset rights
To reset a single right to its default rule, omit the rule parameter.
./pmctl authorisation.applyright signature=scheduler.adjust
To reset multiple rights in a single command:
./pmctl authorisation.applyright signature=scheduler.adjust authorisation.applyright signature=scheduler.cancel authorisation.applyright signature=scheduler.reset