Section Access - Very Odd Behavior

[#1]

Hi,

I got section access to work however I noticed some very strange activity with the filters.

The filters available on the tab are REGION, TIER, and PRODUCT as well as some date filters

I am doing data reduction on a REGION field; the following scenarios ONLY happen when viewing the file on the access point. These things do not happen if it's opened in the QV client (with the same access)

1. If you select a REGION, and then select tier 1 or 2, the visualizations filter to the appropriate tier but then the list box deselects the tier automatically and shows them all in grey as if they were unavailable (the charts stay filtered).

2. if you click on tier 3, the data and visualizations do filter to tier 3 data, but the list box shows Tier 1 selected.

3. if you select a REGION and then a specific PRODUCT (let's call it SHOES for fun), the bottom table looks perfectly fine. However If you select a REGION and then HATS, the bottom table loses three columns (REGION, TIER, and 1 other) and collapses to a single row of aggregated data.

The oddest part is that none of this happens when I open the file locally; it only happens on access point. I tested these scenarios on access point and locally with every possible combination of data reduction.

Any advice would be appreciated.

My section access script is very simple:

SECTION Access;

LOAD upper(ACCESS) as ACCESS,

     upper(NTNAME) as NTNAME,

     upper(SALES_SEC)as SALES_SEC,

     upper(DISCOUNTS_SEC) as DISCOUNTS_SEC

FROM

$(vSharedIncomingFlatFiles)blahblahblah.xlsx

(ooxml, embedded labels, table is Sheet1);

SECTION Application;

The data reduction on the SALES_SEC works absolutely perfectly. Zero issues with filters, zero odd behavior in charts. It's only the DISCOUNTS_SEC that is giving me a hard time. They are setup the same way.

What the heck is going on?

[Bill_Britt]

Hi Stephan,

I think the answer to your question is here " the following scenarios ONLY happen when viewing the file on the access point". This would mean to me that there is an issue with the service account having access to all the data when it is doing a reload.

Bill

[#3]

What do you mean the service account? The name which executes the file? I have that user added with full permissions as well.

If you mean the name of the person accessing the file, that should not be the case either. Users with full access still have the same issues (even with admin rights). Opening the file locally with the same exact permissions does produce the odd behavior.

There is also no security on publisher beyond simply adding users to a group which are allowed to view the files. There is no data level security.

[Bill_Britt]

I am talking about the Service Account that runs the Distribution service. If you are seeing things correct when you manually run the reload and not when the Distribution service does, then something is not setup correctly for the service account.

Bill

[#5]

Okay so I just tested something and found a solution (kind of)

Before, I had the 'service account' in the section access with 5 rows (to include all 5 values in the reduction field) since I was using strict exclusion (following users I simply used a * for full access).

When I turned off strict exclusion and just used 1 row for the service account and left the fields blank, everything works fine.

Would there be any downside to this? Is it less secure if I don't use strict exclusion?

[#6]

Nevermind; this method only makes it work for ZERO access or ALL access. Partial access still acts very oddly.

And at no point am I doing the reload locally. If I use publisher to reload the file but then open the qvw in my client it works 100% fine; this is what I meant by opening it locally. I never reload the file in the client itself.

[Bill_Britt]

Try this and it will show if it is an issue with the service account. For the Distribution service change the account running it to your User ID and password and then see what happens with the reload.

Bill