Module Template

There is a script for building modules located in the build directory. To utilize the script you need to:

• configure a custom module directory
• add the custom module directory to your .env
• call the addmodule.sh script from that directory using the new module name or full path with the name as the argument.
• if the full path is not specified, the module will be created in the pwd

module_name='system_version'
build/addmodule.sh $module_name # creates "system_version" in ./

module_name='/usr/local/custom_modules/system_version'
build/addmodule.sh $module_name # creates "system_version" in /usr/local/custom_modules

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_ system_version_init.php
└── scripts
    ├── system_version.sh
    ├── install.sh
    └── uninstall.sh
└── views
    ├── system_version_listing.yml
    ├── system_version_report.yml
    ├── system_version_tab.php
    └── system_version_widget.yml
├── system_version_controller.php
├── system_version_model.php
├── system_version_processor.php
├── composer.json
└── provides.yml

Locales

Any user facing text strings should be localized 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.

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
• system_version.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/munkireport/scripts/cache directory. Alternatively, the install.sh can simply point to an external file (for things that do not change).

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

system_version_controller.php

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

system_version_model.php

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

system_version_processor.php

The processor file helps in ingesting the data that the client is sending into the database.

composer.json

File containing json data of the module name, description and license. (for use with Composer/Packagist)