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: 
ngulliver
Partner - Specialist III
Partner - Specialist III

Nprinting not applying imported user filters and groups if user already exists

Hi,

I am using NPrinting April 2019. 

When I import a new user, it successfully builds the user and adds them to a group and adds the filter to the user.

However, when I import  the same user for a different task, it does not build the relationship between User, Group and Filters. The new group and new filter are created but the user is not added to the group and the filter is not added to the user.

I do get a warning message:

Importing USER with name 'ngulliver' : skipped. The email 'ngulliver@xxxxxx.co.uk' is already in use.

Is this a know issue or is there a setting change required ?

Labels (1)
1 Solution

Accepted Solutions
Frank_S
Support
Support

Hi Neil,

I've done several tests this afternoon and the only test that failed somewhat (without an error) was when I attempted to modify users/groups/filters using the same recipient file information except for using a different NPrinting App/Connection combination.

I removed a filter from my 'testuser3' and it was not removed from its user filter.

So it seems that:

1. Created manual NPrinting user entries and was able to modify these using recipient import process subsequently

2. Created separate tasks using the same NP app and connection and was able to modify existing and newly imported NP user recipient information

3. Created a separate task with separate NP App and Separate Connection. This was the only import that fail to modify the NPrinting users/groups/filters.

All users were added as publish task recipients before attempting to modify them via the recipient import in an effort to attempt to generate the same error that you reported.

But at the end of the day I could not repro the issue you are seeing in any combination of my tests.

As such I suggest submitting as support case to have what you are seeing investigated further.

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

3 Replies
Frank_S
Support
Support

Hi @ngulliver 

Can you clarify the necessity to manage a user via a separate import task rather than using the same task and updating the import file used in that task before running the task?

If you use the same task, update the xlsx file with the required changes before running the task, do you get the issue? 

I have sent your comment to our R&D team for review. I am hoping to get the rules clarified and documented better so that we can tell you whether or not with certainty if trying to update a user with separate tasks is even possible or not. I suspect using the same import task, with an updated source file containing your necessary changes, will solve the issue in the mean time.

Can you also show a screenshot of the import options that you are using as well? Is LDAP part of your import/imports?

Thanks in advance...

Please remember hit the 'Like' button and for helpful answers and resolutions, click on the 'Accept As Solution' button. Cheers!
ngulliver
Partner - Specialist III
Partner - Specialist III
Author

Hi, Frank.

We have dozens of different reports generated in NPrinting and each report has a different spreadsheet of users which are updated regularly by different parts of the business. Sometimes the recipient of one report may also be the recipient of another report. Reports can be produced daily, weekly or monthly.

As a consequence many of our Publish tasks also have a matching import task.

For example, a General Manager might want a financial report controlled by the finance team and a stock report from stock control team. Both teams control a spreadsheet of users to import and both contain the same General Manager as a user.

(LDAP is not part of the import. Screenshot of import settings attached - although I have tested with other combinations)

I do have one avenue of investigation which you may be able to clarify - if a group or user is set up manually, does that impact how automatic updates to that user or group are applied ?

 

Frank_S
Support
Support

Hi Neil,

I've done several tests this afternoon and the only test that failed somewhat (without an error) was when I attempted to modify users/groups/filters using the same recipient file information except for using a different NPrinting App/Connection combination.

I removed a filter from my 'testuser3' and it was not removed from its user filter.

So it seems that:

1. Created manual NPrinting user entries and was able to modify these using recipient import process subsequently

2. Created separate tasks using the same NP app and connection and was able to modify existing and newly imported NP user recipient information

3. Created a separate task with separate NP App and Separate Connection. This was the only import that fail to modify the NPrinting users/groups/filters.

All users were added as publish task recipients before attempting to modify them via the recipient import in an effort to attempt to generate the same error that you reported.

But at the end of the day I could not repro the issue you are seeing in any combination of my tests.

As such I suggest submitting as support case to have what you are seeing investigated further.

Kind regards...

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