Creating MunkiReport Modules Part 2

03 December 2018 on macOS and MunkiReport. 3 minutes

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.

Module Structure

File Structure

First, let’s take a look at exactly what the MunkiReport script did for us:

    └── en.json
└── migrations
    └── 2020_04_04_234243_awesome_init.php
└── scripts
└── 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.


MunkiReport relies on the Laraval Migrations Framework to manage database table creation and updating. We will look a creating the migration in Part 5.


These define how the module is deployed to the client, and how exactly the client pulls the right information.

  • - how the script is deployed/installed
  • - how the script is uninstalled
  • - 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 /usr/local/munki/preflight.d/cache directory.


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 script. (The following list shows generally what they are used for, but the actual file that controls where they are defined is the provides.yml file.)

  • 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.

More in this Series


Creating MunkiReport Modules Part 1

Recent changes with MunkiReport have decoupled the modules from the core of the MunkiReport project. Many thanks to Arjen van Bochoven (@bochoven) for all the hard work in bringing this to reality. I’ve seemed to pick an interesting time to learn how to create modules and I wanted to share some things I’ve learned along the way. Also big thanks to John Eberle (@tuxudo) and Zack McCauley (@zack_mccauley) for their help and patience getting me this far.