Skip to main content
Announcements
Defect acknowledgement with Nprinting Engine May 2022 SR2, please READ HERE
cancel
Showing results for 
Search instead for 
Did you mean: 
podge2019
Contributor III
Contributor III

Security Role in NPrinting - Edit Task Issue

Hello,

I've add a new app to NPrinting and created a new Security role so that users can specifically Edit the Publish Task for this one App.

Users would need to be able to add in a filter ad-hoc hence adding in the Edit feature under Publish Tasks.

For a standard user they would not have access to this edit field under their current Security Role.

My issue is that now when I add users into this new Security Role (in addition to their current security role) they have Edit on ALL tasks where they did not have this option before.

Is there someway to mitigate against users having this Edit option on all tasks?

More Details:

Current Security Role = Invoicing User -> No access to Edit Publish Tasks. 3 Existing apps under role.

New Security Role = Invoicing User 1 -> Same as above under Actions except for Edit under Publish Tasks. Only one new app added under this role.

So I have users now with these 2 Security Roles assigned and the permissions from the newly created role is overwriting the permissions applied under the first security role.

Thanks

podge2019_0-1615558933137.png

 

Labels (2)
2 Solutions

Accepted Solutions
Frank_S
Support
Support

@podge2019 

To achieve that you will likely need to only use custom roles or update the existing and removing the default selected "All apps" check box which forces visibility to all NP Apps for each custom role.

By default, the built in 'User' role will have access to all Apps. But 'all apps' can be unchecked for this role. However, if NP accounts are assigned to developer, newsstand or administrator, this checkbox cannot be unchecked. So again you would have to create custom roles to enable the level of granularity you are looking for.

As an option/suggestions, you may wish to create a separate role for each set of users that you wish to have access to a specific set of NP Apps (each NP app contains your connections, reports etc).

Frank_S_0-1615571021689.png

Then once you've defined your custom roles with the assigned/selected NP apps, then add the custom roles to each NP user and remove default roles from each user since those will have access to 'All apps'

Then finally, set your publish task permissions for each custom role.

I would suggest doing this in a test environment so as to not impact your current production users.

This would be a highly customized solution and there is no export tool to show information about group membership.

I haven't tested this myself, but theoretically is should work.  A simple test might be to set up 2 test NP users and 2 custom roles. Give user 1 access to customer role 1 (app1) and user 2 access to custom role 2 (app2). No other roles should be applied to these test users.

Give Publish task permissions to custom role 1 but none to custom role 2. Does this keep the views to publish tasks limited only to user 1?

However, you may wish to install the NP governance dashboard found here to view roles and role membership.

https://community.qlik.com/t5/Qlik-NPrinting-Documents/NPrinting-Governance-Dashboard/ta-p/1744538

Kind regards...

 

Please remember hit the 'Like' button and for helpful answers and resolutions, click on the 'Accept As Solution' button. Cheers!

View solution in original post

Frank_S
Support
Support

@podge2019 

I did the test and it works:

customer role 1.PNG

 

custom role2.PNG

Please remember hit the 'Like' button and for helpful answers and resolutions, click on the 'Accept As Solution' button. Cheers!

View solution in original post

6 Replies
Frank_S
Support
Support

@podge2019 

To achieve that you will likely need to only use custom roles or update the existing and removing the default selected "All apps" check box which forces visibility to all NP Apps for each custom role.

By default, the built in 'User' role will have access to all Apps. But 'all apps' can be unchecked for this role. However, if NP accounts are assigned to developer, newsstand or administrator, this checkbox cannot be unchecked. So again you would have to create custom roles to enable the level of granularity you are looking for.

As an option/suggestions, you may wish to create a separate role for each set of users that you wish to have access to a specific set of NP Apps (each NP app contains your connections, reports etc).

Frank_S_0-1615571021689.png

Then once you've defined your custom roles with the assigned/selected NP apps, then add the custom roles to each NP user and remove default roles from each user since those will have access to 'All apps'

Then finally, set your publish task permissions for each custom role.

I would suggest doing this in a test environment so as to not impact your current production users.

This would be a highly customized solution and there is no export tool to show information about group membership.

I haven't tested this myself, but theoretically is should work.  A simple test might be to set up 2 test NP users and 2 custom roles. Give user 1 access to customer role 1 (app1) and user 2 access to custom role 2 (app2). No other roles should be applied to these test users.

Give Publish task permissions to custom role 1 but none to custom role 2. Does this keep the views to publish tasks limited only to user 1?

However, you may wish to install the NP governance dashboard found here to view roles and role membership.

https://community.qlik.com/t5/Qlik-NPrinting-Documents/NPrinting-Governance-Dashboard/ta-p/1744538

Kind regards...

 

Please remember hit the 'Like' button and for helpful answers and resolutions, click on the 'Accept As Solution' button. Cheers!
Frank_S
Support
Support

@podge2019 

I did the test and it works:

customer role 1.PNG

 

custom role2.PNG

Please remember hit the 'Like' button and for helpful answers and resolutions, click on the 'Accept As Solution' button. Cheers!
podge2019
Contributor III
Contributor III
Author

Hi @Frank_S ,

I've gone ahead and tested this following the guidance above on our Test Environment, however, this is still replicating the same issue.

As soon as my test user is added a new Security Role with Edit permission, along with the current role, the existing access they have is changed.

They are now able to edit the Publish Tasks they did not / should not be able to Edit.

In my NP Console set up we had actually never used the default "User" role.

We already had custom roles set up for an "Invoicing User" which only has access to 3 Apps - These 3 Apps they could not Edit the Publish Task.

The new Security Role was also for "Invoicing User - New App" which just has the Edit Publish Task on this one new App.

The Users who are affected are members of a Group -  "Invoicing Group" . This Group is also assigned the Security Role for both "Invoicing User" & "Invoicing User - New App".

Could this be where the issue lies? A user being a member of a Group with a Security Role and also being directly assigned a Security Role?

podge2019_0-1615806820960.pngpodge2019_1-1615806879174.png

 

 

podge2019
Contributor III
Contributor III
Author

Hi @Frank_S ,

Just to clarify on the above as its totally irrelevant regards the Security Role being applied to a Group. 🙄

I done a test whereby I removed a Users membership of the "Roles" above.

Logged in and all Apps, Tasks etc. were gone from the Console for the user. (which is expected)

Added back in the two "Roles" and removed the two "Groups" and this had no affect to the permissions,

The Groups are used under the Publish Task on the for the Apps already which I guess is the relevant part of this.

Thanks,

Padraig

podge2019
Contributor III
Contributor III
Author

And last one @Frank_S ,

There appears to be one part that is working which is very strange.

So on the permissions for Existing "Invoicing User" there is nothing ticked for "Filters".

On the new Security Role "Invoicing User - New App" when I tick the Edit Publish Task permission the "Filters" View tickbox gets automatically ticked.

Now this is where it is strange....on the "Existing" "Invoicing User" role this works so I cannot see the filters on the Publish Task, which Yes is correct, but why does this appear to work, however, the Edit Task does not.

There does seem to be some distinction between them and is working to a certain degree, however, I can't see why the Edit does not work on the two Custom Roles.

Existing "Invoicing User" permissions - Existing Three Apps.

podge2019_0-1615811165077.png

New  "Invoicing User - New App" - Permissions - Just new app under selected Items:

podge2019_1-1615811242456.png

 

Frank_S
Support
Support

@podge2019 

I found similar behavior in June 2020 SR 1 but when I tested with Feb. 2021 version of NPrinting, I found the most flexibility. For example I was able to add the specific view only scenario's you described in your images above without triggering 'filter' permissions.

I tested each of your scenarios and they all worked!

In any case, I suggest:

  • Ensuring to create one custom role per NP app only
  • Given that you are using Nov. 2019, Upgrade or TEST your scenarios on an NPrinting Feb. 2021 'test' server if you have access to one. (make sure you are logging out of NPrinting web console and logging in again to accurately test.)
  • If your requirements are not working as needed and you want to see additional flexibility, please share your idea for this here: https://community.qlik.com/t5/Suggest-an-Idea/idb-p/qlik-ideas

Note:

  • only 'Users' can be assigned roles. Entities such as NPrinting 'groups' cannot be assigned roles.

Conclusion: this all appears to be working as designed where NPrinting Feb. 2021 is used. (I did not test Sept. or Nov. 2020). If your specific requirements are still not working in Feb. 2021, I suggest writing up an 'idea' in the link above...but again, my tests indicate its working as expected.

Please remember hit the 'Like' button and for helpful answers and resolutions, click on the 'Accept As Solution' button. Cheers!