I’ve marked solved for now. I haven’t gotten to access control yet for GUI stuff. That said is it just permissions of the user?

For more information on some of the methods and class based variables please see:

fogdoc.mastacontrola.com

All fog installations, now, should have the folder: /var/www/fog/fogdoc available. It is possible to build local documentation of all classes using doxygen.

The command to build it would be:

cd /var/www/fog
doxygen fogdoc/fogdoc

The fogdoc currently is designed to place the fogdoc in /var/www/fogdoc, so a link to your properly html root directory, or fog directory will probably yield in slightly better results for generating this documentation.

@jim-graczyk I wouldn’t consider your layout “atypical” just necessarily what I see most people using FOG for. I certainly want to make fog the best product possible and will do my best to keep fog in such a light - I hope I’m doing okay in that regard (not needing reassurance just a general rhetorical thought/question).

I fully appreciate the awareness and information given and just hope to give any insight as to where things may not be what would be expected, particularly how to fix the things as when the items seem appropriate.

I don’t really have a document on how to create reports to be imported as all reports that currently exist have been either ported from older versions of fog, or user requested reports that I just created for them. I know it’s not the best way to go about things, but it seems to have worked for now.

The best source of what is current with reports would be to look at other reports, and make adjustments as required.

The quick and dirty basics:
The location of reports, now, is in /var/www/fog/lib/reports/

The reports are class files now. With an identifier of <classname_of_report>.report.php

For the report that’s imported to show up on the list of “usable” reports, If you wanted report name to show up as: Classname Of Report, your literal classname would be:
class Classname_Of_report (in the php file). and the FIlename would be: classname_of_report.report.php

The method inside the report that kind of “does” the work is currently:
public function file() {}

Everything else is pretty much up to you.

So let’s say you wanted a literal report to be : "Classname Of Report"
and that report simply printed “Hello World” Your filename would be:
/var/www/fog/lib/reports/classname_of_report.report.php

The class would look something like:

<?php
/**
 * Prints hello world into a report.
 *
 * PHP Version 5
 *
 * @category Classname_Of_Report
 * @package  FOGProject
 * @author   Jim Graczyk <some@email.here>
 * @license  http://opensource.org/licenses/gpl-3.0 GPLv3
 * @link     https://fogproject.org
 */
/**
 * Prints hello world into a report.
 *
 * @category Classname_Of_Report
 * @package  FOGProject
 * @author   Jim Graczyk <some@email.here>
 * @license  http://opensource.org/licenses/gpl-3.0 GPLv3
 * @link     https://fogproject.org
 */
class Classname_Of_Report extends ReportManagementPage
{
    /**
     * Display Page
     *
     * @return void
     */
    public function file()
    {
        echo "Hello World!";
    }
}

A far more “useful” example I think would be:

<?php
/**
 * Prints hello world into a report.
 *
 * PHP Version 5
 *
 * @category Classname_Of_Report
 * @package  FOGProject
 * @author   Jim Graczyk <some@email.here>
 * @license  http://opensource.org/licenses/gpl-3.0 GPLv3
 * @link     https://fogproject.org
 */
/**
 * Prints hello world into a report.
 *
 * @category Classname_Of_Report
 * @package  FOGProject
 * @author   Jim Graczyk <some@email.here>
 * @license  http://opensource.org/licenses/gpl-3.0 GPLv3
 * @link     https://fogproject.org
 */
class Classname_Of_Report extends ReportManagementPage
{
    /**
     * Display Page
     *
     * @return void
     */
    public function file()
    {
        $this->title = _('Hello World');
        $csvHead = array(
            _('Hello'),
            _('World')
        );
        foreach ((array)$csvHead as &$csvHeader) {
            $this->ReportMaker->addCSVCell($csvHeader);
            unset($csvHeader);
        }
        $this->ReportMaker->endCSVLine();
        $this->headerData = array(
            _('Hello'),
            _('World')
        );
        $this->templates = array(
            '${hello}',
            '${world}'
        );
        $this->data[] = array(
            'hello' => _('Hello'),
            'world' => _('World')
        );
        $this->ReportMaker->appendHTML($this->process(12));
        echo '<div class="col-xs-9">';
        echo '<div class="panel panel-info">';
        echo '<div class="panel-heading text-center">';
        echo '<h4 class="title">';
        echo $this->title;
        echo '</h4>';
        echo '</div>';
        echo '<div class="panel-body">';
        if (count($this->data) > 0) {
            echo '<div class="text-center">';
            printf(
                $this->reportString,
                'Hello_world',
                _('Export CSV'),
                _('Export CSV'),
                self::$csvfile,
                'Hello_world',
                _('Export PDF'),
                _('Export PDF'),
                self::$pdffile
            );
            echo '</div>';
        }
        $this->ReportMaker->outputReport(0);
        echo '</div>';
        echo '</div>';
        echo '</div>';
        $_SESSION['foglastreport'] = serialize($this->ReportMaker);
    }
}

I feel I must add the primary reason you won’t see a “central repository” for OS images lies down with the very simplistic case of licensing.

If there were a “central” repository, um, can you imagine the legal issues that would no doubt-ably ensue? Managing a repository itself would be extremely difficult, but licensing - especially in commercial OS’s - would be a nightmare.

Ultimately, while it would - from a purely technical standpoint - be possible to create a (very very very) generic set of OS’s that could be used by many, this would not come with your organizations set of software. (Admittedly vague in that you could automate some of the software layout with snapins.) This again is purely technical. Yes, it “could” be done. No, it most likely will not be done.

I could, however, understand central repo for OS’s that don’t require licensing (only one I can think of would be linux though) but even then you’re dealing with one person’s preferences for the layout of the OS vs. what might actually be required and/or more suitable to your environment.

@jim-graczyk The limits are set at 128MB, as this is the default for PHP as a whole. I have thought about making the limit’s higher, but as the use cases are different I feel it’s just as appropriate to leave it as “default” but adjustable. One of the upside’s to this being adjustable in the DB as it currently stands is it allows the admin’s to limit the memory usages as necessary and those settings stay regardless of system updates. Setting a higher limit isn’t hard (very easy to tell the truth) but it’s also just as easy to inform the user/admin where to make the setting and I think it’s more appropriate to let the user/admin decide what their top limit should be rather than let FOG make those determinations

While you’re correct that 10 snapins, in this case, on 20 devices would make a lot of snapins, Iam of the opinion that this is relatively an edge case. I totally understand the feasibility of what the snapins are doing, and I can actually look into the snapin history elements to gain more insight into what’s causing the memory issue, but it’s, in my experience, not a normal thing. (The not normal meaning most people I’ve helped typically only have 1 or 2 snapins. I have seen other cases where the user may have many more than 10 though these are FAR less than the number of user’s I’ve helped over time.)

Using time based model to get the snapin report makes perfect sense and I do plan on reintegrating it, but wanted to also make sure that what was in place worked and worked properly before worrying about extending how to obtain the reports. I work on the “whole” of FOG and my main focus is on making the GUI as usable as I can (as you can hopefully tell by the quick turnarounds to fix the issues almost at the time I see the new report). Yes, the reporting elements could use refinement. No, I’m probably not going to be as quick to get the refinements in as I am to get the gui layout, look, and feel mostly completed. Yes, I do plan to get these refinements in the 1.5.x series. No I doubt I will have these refinements for 1.5.0 stable. (Not saying it can’t get done, but I’m literally one guy).

The code for this report hasn’t changed at all, so if it worked for Rc7 or rc8, then I’m going guess you’re running into an “out of memory” type issue in PHP. In which case, you can update the memory needed for PHP in FOG Configuration Page->FOG Settings->General Settings->Memory Limit.

What’s the apache error log show?

Fixed in working.

Any word?

Fixed in working. Thanks for reporting.