In part I we made an awesome module. Or we made the framework for an awesome module. Or really we got ourselves ready to make an awesome module with the awesome built in MunkiReport tools. In this article, we deep dive into the module itself.
First, let’s take a look at exactly what the MunkiReport
addmodule.sh script did for us:
awesome └──locales └── en.json └── migrations └── 2020_04_04_234243_awesome_init.php └── scripts ├── awesome.sh ├── install.sh └── uninstall.sh └── views ├── awesome_listing.yml ├── awesome_report.yml ├── awesome_tab.php └── awesome_widget.yml ├── awesome_controller.php ├── awesome_model.php ├── awesome_processor.php ├── composer.json └── provides.yml
This is an awesome looking module.
Let’s get an overview of what everything is.
I had a few years of Spanish in high school mixed with a semester of French in college, which leaves me relying on other people to fill up this directory for me! Basically any user facing text strings need to be provided via the i18n localization framework and stored in the proper language
json file in the directory.
These define how the module is deployed to the client, and how exactly the client pulls the right information.
install.sh- how the script is deployed/installed
uninstall.sh- how the script is uninstalled
awesome.sh- defaults to shell script, but this could be python or any other type of script that can gather data and store it in a file to ship to the server. The result should be a file in the
There are a number of different types of views, and a module can have as many or as little as you want! By default a listing, report, and widget are created by the
addmodule.sh script. (The following list shows generally what they are used for, but the actual file that controls where they are defined is the
listing - will show up under the Listings heading
report - will show up under the Reports heading
- admin - will show up under the Admin heading (not quite available at this time, but will be coming soon!)
tab - will show up as a new tab under the client view
- widget - creates a widget that can be used on the dashboard or report page
The controller file defines how the data is parsed out of the database into a format that the views can then display.
The model file does the work of pulling the data out of the database.
The processor file helps in ingesting the data that the client is sending into the database.
There is more magic behind this file, but for now we’ll say it’s just
json data of the module name, description and license.