I know this has been discussed before but I am not happy with the recommended solution.
The issue is that in NPrinting 16 you could set up the same person as a recipient more than once on the same app (nsq) with different filters or on different apps with different filters. Everything worked fine.
In NPrinting 17 you can only set up the user once and have one set of filters. The issue arises for me because I want to send a person a detailed report on Cost Centres A and B but then a summary report on the whole company's performance based on the same connection to the same QlikView app.
The solution suggested, Nprinting 17 - Multiple filters on user level for different reports , is to create new connections to the same source document but that is too messy for me. I don't want lots of connections to the same document. I would rather set up copies of the same user called "Ben Smith - Selected Cost Centres" and "Ben Smith - Whole Company". It would be a much tidier method but it is blocked because you cannot have more than one user having different email addresses. Why can't that block be removed and just be changed to a warning? My current workaround is going to have to be using email aliases to set up multiple copies of users.
Alternatively, what would work better would be to add filters against the users on the "publish task" stage, so you picked the users to attach to the task and then added bespoke user filters at that stage, which would only be applied to that task. Surely that would be a much more flexible solution.
Can that or removing the block on multiple users on the same email be looked at in the next version?
I believe the reason they block duplicate email addresses is because this is how users can log in to NPrinting 17 - this is essentially the User ID, so it has to be kept unique. I know you may not be using that functionality, but that's the reason.
I think your suggestion about having publish task user-specific filters is potentially a good one, although it would be a 5th place where filters could be set (after users, reports, tasks, objects), so that could get confusing.
Depending on what you're looking to achieve, we often end up doing something in the data model to support NPrinting. e.g. if you need a user to have Company A, Company B and CompanyA+B consolidated of the same report, we add a new table to associate to the data like:
Company A, Company A
Company B, Company B
Company A, Company A+B
Company B, Company A+B
And then we add a report cycle on the NPCompanyLoop field, so the user gets 3 reports.
You can achieve quite a lot with this approach and can make as many report-specific fields as you need.
Email aliases is of course another approach.
Having duplicate reports rather than users or connections can sometimes achieve what you want too - if you can specify filters on that one (e.g. have one for single-company users and one for multiple-company users).