Project types

A project is defined as a sequence of tasks that must be completed to attain a certain outcome.

The tasks depend on the project type and resolution is tracked automatically by default, although the user can choose to complete the project if applicable.

The five project types

Projects can now be of one of five types, denoted by the project type column in the projects table. The project type is specified by the user during project creation and cannot be changed after the project is created.

Issue resolution projects (project type: issues)

These are projects as they have existed within Nanitor between versions 1.9.7 and 3.0. After creating the project, we can assign issues to it, which we track in the project issues table, and any issues assigned to an issue resolution project in this way will show which project(s) they’re assigned to in the issue list.

It is also possible, optionally, to set an asset scope of particular assets or asset labels; in this case, issue violations on assets outside of the asset scope will not be counted as part of the project. Issues for which only some violations are within the scope of an assigned project will be shown as “partial” in the issue list.

If an issue is assigned to a project but does not exist on any asset within the asset scope of a project, the issue will be marked as “out of scope” in the issue list.

When we view an issue resolution project, we will see an overview of all of its issues that fall within the project’s scope. On this screen, we can see on how many assets we’ve resolved or excluded the issue (out of the assets that are in scope) in the “Asset progress” column. (Any issue violations that had already been resolved or excluded prior to the issue being added to the project will never be counted as part of the project, nor will any that are created after the project is marked as completed.) If the issue has been resolved or excluded on all assets within scope, we will show a checkmark and either Issue resolved (if it has been fully resolved), Issue resolved in scope (if it has not been fully resolved but has been on all assets within the project scope), or Issue excluded (if it has not been fully resolved within scope but has been excluded on all assets in scope where it has not been resolved).

If we click the “Asset progress” number for an individual issue, we can also see a list of individual assets within scope where this issue is open, with individual checkmarks where the issue has been resolved or excluded on the given asset:

The completion percentage of an issue resolution project is currently calculated as

(s.num_issues_assigned - n.num_issues * n.incomplete_fraction) / s.num_issues_assigned

where s.num_issues_assigned is the total number of issues assigned to this project, n.num_issues is the total number of issues that are not out of scope, and n.incomplete_fraction is the fraction of issue violations within the scope that are not resolved or excluded, out of the total number of issue violations within scope. Thus, for instance, if a project has three assigned issues, A (not in scope), B (three issue violations in scope, one resolved), and C (two issue violations in scope, both resolved), then the completion percentage will be calculated as

(3 - 2 * 0.4) / 3 = (3 - 0.8) / 3 = 2.2 / 3 = 0.7333 = 73.33%

What this formula actually means is that if the project has assigned issues that are not within scope, each such issue will be treated as already completed for the purposes of the completion percentage, assuming each issue has equal weight - that is, in the above example, the out-of-scope issue accounts for one third (33.33%) of the completion rate (because it’s one out of three issues), and of the remaining 66.67%, 60% of the issue violations have been resolved, adding 40% (0.6 * 0.666…) on top of the 33.33%.

Asset issue resolution projects (project type: devices)

The primary difference between these and issue resolution projects is that instead of assigning issues to the project, we are only required to give it an asset scope (individual assets and/or asset labels), and all issue violations on these assets are automatically part of the project. This is useful for projects that revolve around cleaning up issues on a particular set of assets.

Right now, asset issue resolution projects will never appear in the projects column in the issue list; they are not directly associated with the issues themselves.

When we view an asset issue resolution project, we will see a list of assets within the project’s scope with their IP addresses, asset priority, health score, and the number of issues.

If we resolve all issue violations on an asset, it will be shown with a checkmark, similar to issue resolution projects, with “Asset resolved” beside it. There is not currently a view similar to the issue asset view for an issue resolution project, as we can simply view the full list of issues on the asset.

Completion for an asset issue resolution project is defined simply as the fraction of issue violations on all of the assets within scope (that were not already resolved before the creation of the project or created after its completion) that have been resolved.

Asset onboarding projects (project type: onboarding)

Asset onboarding projects work a little differently. When creating an asset onboarding project, the user sets a goal of a certain number of assets they’d like to onboard into Nanitor. Optionally they can specify a label, indicating they want to end up with that many devices having that label - whether that means onboarding new devices or simply finding and labeling the devices that ought to have the label. (It is not possible to set an asset scope of individual assets, as this would not make sense.)

When we view an asset onboarding project, we see a list of either all devices created since the start date of the project (if there is no label scope) or all devices with the label (if there is a label scope). All the devices will be check-marked, since by the nature of things they can’t be on the list until we’ve already onboarded them or given them the label. They will show the same information as on the list for asset issue resolution projects.

Completion for an asset onboarding project is defined as the number of devices on that list divided by the goal number set by the user.

Asset health hardening projects (project type: hardening)

For these projects, the user sets a numerical health score target and an asset scope of labels/assets (required), and the goal is to resolve issues on those assets until their health score reaches the target number.

When we view an asset health hardening project, we will see a list of assets within the scope, and each will be check-marked with Asset resolved if its health score is greater than or equal to the target score.

Completion for an asset health hardening project is simply defined as the number of assets within the scope that have reached the target health score divided by the total number of assets within the scope.

Upgrade/decommission assets projects (project type: upgrade)

This project type is intended for eliminating EOL assets from the system - either by upgrading their operating system to a non-EOL one, or by decommissioning the asset.

This project type requires specifying an asset scope (labels and/or assets). Viewing the project will show all assets within scope; an asset will be considered resolved and check marked with Asset resolved if the asset is not end-of-life or has been decommissioned. Archived assets will be shown on this list if they were archived after the creation of the project, as otherwise, we would not see decommissioned assets, to begin with.

Completion for an upgrade/decommission assets project is defined the same way, as how many assets are not end-of-life or have been decommissioned divided by the total number of assets within scope.