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 addmodule.sh script did for us:

awesome
└──locales
    └── en.json
└── migrations
    └── 2018_12_04_234243_awesome_init.php
└── scripts
    ├── awesome.sh
    ├── install.sh
    └── uninstall.sh
└── views
    ├── awesome_listing.php
    ├── awesome_report.php
    └── awesome_widget.php
├── awesome_controller.php
├── awesome_model.php
├── composer.json
└── provides.php

This is an awesome looking module.

Let’s get an overview of what everything is.

Locales

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.

Migrations

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

Scripts

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 /usr/local/munki/preflight.d/cache directory.

Views

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 provides.php file.)

  • listing - will show up under the Listings heading

    listings

  • report - will show up under the Reports heading

    reports

  • 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

    tab

  • widget - creates a widget that can be used on the dashboard or report page

awesome_controller.php

The controller file defines how the data is parsed out of the database into a format that the views can then display.

awesome_model.php

The model file does the work of pulling the data out of the database.

composer.json

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


Previous

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.