cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Custom report data discrepancies

Hi everyone,

I have a query around a custom report and some of the data not populating depending on who runs the report.  It is a multi-tenant platform running 2021 R1, however it is only a single tenant that has highlighted this issue.  Some background info:

The tenant created a custom report using the following database components: “Installation” and “Inventory Device”, with the report intended to show what devices have what applications deployed and any related user. The Inventory device columns are ‘Calculated User’, ‘Last logged On User’ and ‘Inventory Date’ with all else coming from the Installations section. The report is filtered only by “Classification” .

When User 1 ('Administrator' role) runs the report, they can see the ‘Calculated User’ and ‘Last Logged on User’ columns populated against a specific device, but when User 2 (modified 'Read-Only' role) runs the same report,  these two columns are left blank against that device in their view of the report. However, User 2 can see some usernames populated within the report against other devices. If you view the device in the Management section it has a user assigned and everyone can see this too.

The only thing User 1 can see that would impact this would be the users Role & or permissions, but they cannot see anything that would prevent this directly under their account permissions.

User 2's modified Read Only role has full permissions on “Management Views and Reports” and the only items they have no set permissions to are ‘Administration’, ‘Data inputs’, ‘Purchase orders’ and ‘Roles’. All other permissions are set to Read Only.

Query: Why and under what conditions would the report show the usernames when User 1 runs the report, but not for User 2 when the data exists?

 

Any insight would be great. Thanks in advance!

(1) Solution

Hi,

Short answer:

The role(s) that you assigned to 'User 2' are lacking the 'List users' privilege in the 'Users' section of the role in FNMS.

Untitled.png

 

Long answer:

As you can see in the attached PDF document (page #2), I built a simple report using the rather clunky FNMS Report Builder. The report uses the 'Inventory device' and 'Installations' main object, and the 'Account' property of the 'Assigned user', 'Calculated user' and 'Last logged on user' sub-objects.

You can view the SQL code generated using the FNMS Report Builder by locating your report in the into the [ComplianceSavedSearch] table. After locating the report, you can view the SQL code in the [SearchSQL] text column and copy it into a new query window.

When reviewing the SQL, you can see that a T-SQL procedure named 'TableComplianceUserCurrentUser' is used for restricting visibility of user related data based on access privileges (Roles). The SQL code of the underlying procedure is shown on page #3 in the PDF document. The function expects that the user logged into FNMS has the ActionClass (activity) value 'list' on the 'EntUsers' object.

By creating a simple role named 'ListUsers' in FNMS and assigning only the privilege 'Users > List users' to this role, you can esily see (page #4) that assigning this 'Users > List users' privilege to a role in FNMS adds the ActionClass (activity) value 'list' on the 'EntUsers' object.

View solution in original post

(2) Replies

Hi,

Short answer:

The role(s) that you assigned to 'User 2' are lacking the 'List users' privilege in the 'Users' section of the role in FNMS.

Untitled.png

 

Long answer:

As you can see in the attached PDF document (page #2), I built a simple report using the rather clunky FNMS Report Builder. The report uses the 'Inventory device' and 'Installations' main object, and the 'Account' property of the 'Assigned user', 'Calculated user' and 'Last logged on user' sub-objects.

You can view the SQL code generated using the FNMS Report Builder by locating your report in the into the [ComplianceSavedSearch] table. After locating the report, you can view the SQL code in the [SearchSQL] text column and copy it into a new query window.

When reviewing the SQL, you can see that a T-SQL procedure named 'TableComplianceUserCurrentUser' is used for restricting visibility of user related data based on access privileges (Roles). The SQL code of the underlying procedure is shown on page #3 in the PDF document. The function expects that the user logged into FNMS has the ActionClass (activity) value 'list' on the 'EntUsers' object.

By creating a simple role named 'ListUsers' in FNMS and assigning only the privilege 'Users > List users' to this role, you can esily see (page #4) that assigning this 'Users > List users' privilege to a role in FNMS adds the ActionClass (activity) value 'list' on the 'EntUsers' object.

Thanks for the detailed response @erwinlindemann , that is very helpful!

 

Cheers 👍