Permission Effects in the WebUI

Permission-related behavior works the same way in the WebUI as it does in the BigFix console.
  • Master Operators have full access to all WebUI elements and controls.
  • Operators that are restricted to a specific type of content or set of devices in the console have the same restrictions in the WebUI. For example, an operator who cannot patch Linux computers in the console cannot patch them using the WebUI.
  • The ability to view information in the WebUI does not imply permission to act on it. For example, access to the WebUI's Software application does not permit an operator who cannot create actions to deploy software. Access to the WebUI's Custom application does not permit an operator to create custom content.

Deployment data is visible to all WebUI operators regardless of content type or source. For example, operators can see all the patches that have been deployed to an endpoint whether they have permission to patch, or not. Again, the ability to view this information does not imply permission to act on it, for example, to stop a deployment in progress.

Explicit and Effective Permissions

BigFix and WebUI permissions can be granted directly or indirectly. Permissions that are granted directly to an operator are explicit permissions; permissions that are granted indirectly, for example, through a role, to one or more operators are effective permissions. Both types are shown for each operator and role.

Image highlighting Explicit and Effective permission values.
Effective permissions can also be granted using the WebUI's Enable For All Operators check box. When granted using this method the descriptor Allowed, in the Effective Permissions column becomes Allowed (Global). Image showing Operator Permissions tab and the Enable for All Operators check box.

Conflicts can arise between an operator's explicit and effective permissions. For example, access to the Patch application can be disabled for Operator A, but enabled for a role to which Operator A is assigned. When this occurs BigFix applies the least restrictive of the two settings. And the result is shown in the Effective Permission column.

Explicit and Effective permission values convey information about how and where permission was granted. When there is a conflict, check the Effective Permission column for the true state of the permissions.

Table 1. Explicit and Effective Permissions
Explicit Permission Setting Effective Permission

Yes – Granted to operator.
Yes – Granted to operator through a role.
Yes – Enable for All Operators box checked.

 Yes

No – Disabled for operator.
No – Disabled for assigned role.
No – Enable for All Operators box clear.

 No

Yes – Granted to operator.
No – Disabled for assigned role.
No – Enable for All Operators box clear.

 Yes

No – Disabled for operator.
Yes – Granted to operator through a role.
No – Enable for All Operators box clear.

 Yes

No – Disabled for operator.
No – Disabled for assigned role.
Yes – Enable for All Operators box checked.

 Yes

Create Actions Privilege

An operator whose Can Create Actions permission is set to No is not allowed to deploy content, though they can still see deployments made by others. You can use this function to grant a form of read-only access to an operator or role.

To set Create Action permissions to No:

  1. Go to All Content > Operators > Details or All Content > Roles > Details.
  2. Scroll down to the Permissions pane and set Can Create Actions to No.
  3. Click Save Changes.
Image showing the Can Create Actions settings on the Details tab.

Send Notification Option

The Send Notification option allows WebUI operators to send an email alert to one or more recipients when a BigFix deployment completes or fails. To use this option several controls must be in place:
  • The operator's Custom Content permission must be set to Yes.
  • The operator's Can Create Actions permission must be set to Yes.
  • The BigFix Send Notifications service must be enabled.

For more information about the Send Notification option, see the WebUI Users Guide.