This repository has been archived by the owner on Jan 3, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 100
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Fix some small PHP style - Update LICENSE - Add documentation on how to write providers - Fix hardcoded HTTP protocol in meeting page
- Loading branch information
Showing
6 changed files
with
124 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
# Writing an on call provider | ||
You may write an on call provider to cater for any service or data you want to appear as notifications in Opsweekly. | ||
Writing a provider is fairly simple; you must: | ||
|
||
1. Place your file either in `providers/oncall/` or in another path in the PHP include path | ||
2. Define it in the `$oncall_providers` providers array in `config.php` | ||
3. Allow users to pass in any variables (e.g. server name, authentication details required for service) from `config.php` | ||
4. Define function(s) that Opsweekly will call when it needs to retrieve data. | ||
|
||
There are two types of configuration passed to your on call provider; global config (which is defined in the `options` part of the array in `$oncall_providers`) and team specific configuration (which is defined in the `provider_options` part of the on call section of the `$teams` array). | ||
|
||
You can refer to example.php for a working example of an on-call provider. This provider just returns one example notification, regardless of the timeframe requested, user requested, or provider/team options passed to it. | ||
|
||
## Functions required | ||
|
||
### getOnCallNotifications() | ||
Returns the notifications for a given time period and parameters | ||
|
||
#### Parameters: | ||
* `$on_call_name` - The username of the user compiling this report | ||
* `$provider_global_config` - All options from `config.php` in `$oncall_providers` - That is, global options. | ||
* `$provider_team_config` - All options from `config.php` in `$teams` - That is, specific team configuration options | ||
* `$start` - The unix timestamp of when to start looking for notifications | ||
* `$end` - The unix timestamp of when to stop looking for notifications | ||
|
||
|
||
#### Returns: | ||
0 or more notifications as an array | ||
|
||
* Each notification should have the following keys: | ||
* `time`: Unix timestamp of when the alert was sent to the user | ||
* `hostname`: Ideally contains the hostname of the problem. Must be populated but feel free to make bogus if not applicable. | ||
* `service`: Contains the service name or a description of the problem. Must be populated. Perhaps use "Host Check" for host alerts. | ||
* `output`: The plugin output, e.g. from Nagios, describing the issue so the user can reference easily/remember issue | ||
* `state`: The level of the problem. One of: CRITICAL, WARNING, UNKNOWN, DOWN |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
# Writing a sleep provider | ||
Opsweekly has the ability to use providers to look up the sleep status of a person during their on call notifications. You can write a provider that interfaces with an external service or data to pull in this information for sleep devices that you use. | ||
|
||
Writing a provider is fairly simple; you must: | ||
|
||
1. Place your file either in `providers/sleep/` or in another path in the PHP include path | ||
2. Define it in the `$sleep_providers` providers array in `config.php` | ||
3. Allow users to pass in any variables (e.g. server name, authentication details required for service) from `config.php` | ||
4. Define function(s) that Opsweekly will call when it needs to retrieve data. | ||
|
||
Sleep providers have the abillity to be passed any number of amounts of data from the Opsweekly UI itself. The config in `$sleep_providers` has an entry "options" which is used to generate HTML fields on the "Edit Profile" page of Opsweekly, allowing each user to have their own friendly interface for configuring their sleep device. This data is saved from that form to the database, and then passed into your provider as an array when the functions are called. | ||
|
||
You can also pass global options in from `$sleep_providers`; the entire key => value array in the config for that provider is passed into it when called, so you can define other variables required (e.g. URLs, authentication information that is specific to your provider) | ||
|
||
You can refer to example.php for a working example of a sleep provider. This provider always returns that the user was awake, regardless of the timeframe requested, user requested, or provider/team options passed to it. | ||
|
||
## Functions required | ||
|
||
### getSleepDetailAtTimestamp() | ||
Returns the sleep state for a given unix timestamp and user | ||
|
||
#### Parameters: | ||
* `$timestamp` - The unix timestamp of the notification that Opsweekly wishes to know sleep data about | ||
* `$user_options` - The array of options specified in the Opsweekly UI by the user during sleep configuration (see above) | ||
* `$plugin_options` - All values from `config.php` in `$sleep_provider` for this providers key - That is, global options. | ||
|
||
|
||
#### Returns: | ||
Sleep detail for the timestamp as an array. | ||
|
||
The array must contain the following keys: | ||
|
||
* sleep_state | ||
* -1 for no data | ||
* 0 for awake | ||
* 1 for asleep | ||
* mtts: The time in seconds, up to 7200 seconds, that the next asleep period occured after `$timestamp` or -1 for unknown/no sleep. | ||
|
||
* sleep_level: As per the standard measure of 4 levels of sleep, if available: | ||
* 1: NREM Stage 1 | ||
* 2: NREM Stage 2 | ||
* 3: NREM Stage 3 | ||
* 4: REM | ||
* confidence: The confidence the plugin has that the data it has is accurate | ||
* 0: No confidence | ||
* 100: Very confident |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
# Writing a weekly hint provider | ||
A 'weekly' provider, or 'hints' is designed to prompt the user to remember what they did in the last week, so they can fill out their weekly report more accurately. | ||
If you have a service that has data like this, e.g. commits or closed tickets, you can write a provider to pull this information into the Opsweekly UI. The data is displayed next to the text area on the Add Weekly Update page. | ||
|
||
Writing a provider is fairly simple; you must: | ||
|
||
1. Place your file either in `providers/weekly/` or in another path in the PHP include path | ||
2. Define it in the `$weekly_providers` providers array in `config.php` | ||
3. Allow users to pass in any variables (e.g. server name, authentication details required for service) from `config.php` | ||
4. Define a class and function(s) that Opsweekly will call when it needs to retrieve data. | ||
|
||
Weekly providers only have a global configuration which is passed into your class on instantiation. | ||
The username, and the requested time period is also passed in. | ||
|
||
You can refer to example.php for a working example of a weekly hints provider. This provider just outputs some text to display the data that was passed in to it. | ||
|
||
## Class definition | ||
The class should have a unique name, e.g. `ExampleHints`. The name is not important; you (or you users) provide that as part of the definition of the provider in `config.php` | ||
|
||
The `__construct` function is passed the following variables: | ||
|
||
* `$username`: The simple text username of the person who is using Opsweekly and making this request | ||
* `$config`: The array of configuration items that you have defined in your 'options' array in `$weekly_providers` | ||
* `$events_from`: The unix timestamp of the beginning of the time period to show events for | ||
* `$events_to`: The unix timestamp of the end of the time period to show events for | ||
|
||
(Remember, users can go back to past weeks to fill in their Weekly reports, so respecting these from/to variables is important, if possible.) | ||
|
||
|
||
## Functions required | ||
|
||
### getOnCallNotifications() | ||
Returns HTML to be displayed on the "add weekly update" page. | ||
|
||
#### Returns: | ||
Returns HTML to be displayed on the "add weekly update" page. |