What is the best way to implement section access only on details?

[datagrrl]

Hello-

I have a question about implementing Section Access only on detail data.

In the example below...I work at Store A. I can know the overall metrics for all stores, but I shouldn't know the other stores details.

I do not believe I am going to want to filter using the KPI/Charts at the top.

I have been thinking through a few possibilities. Most have me going back to a data model change, but I wanted to get feedback first. I a sure someone else has had this in the past. I included a sample application. Let me know if you have any questions.

Thanks,

[rajivmeher]

Hi datagrrl‌

Please check if the below helps:

Design the section access as follows:

Access,  UserID,  Password,  Store

USER,  USERA,  USERA,  *

ADMIN,  ADMIN,  ADMIN,  *

USER,  USERB,  USERB,  A

USER,  USERC,  USERC,  B

USER,  USERD,  USERD,  C

ADMIN,  USERE,  USERE,  A

This should restrict users to the store only allowed to them through section access. For user with multiple store access add another row for the same user with the second/third store.

Regards

Rajiv.

[datagrrl]

Thanks. I understand how to impement section access overall, I apologize for not being more clear.

The users at each store shouldn't see the details for the other stores, but they can see the aggregated details for all stores. Basically the individual attributes and measures should not be seen. I can know that Store B has Seven dogs ad the average cost is 6. I can also know the min and max, but I can't know that dog number 35 costs 8. I can only know the individual cost at my store(Store A).

The path I am going down is doing the aggregations in their own table, so the store column would have a different name in the aggregated values.

[datagrrl]

So....my plan is to NOT implement Section Access at all.

I am going to load a table that says

NTNAME,      STORE

USER1,          A

USER2,          B

USER3,          A

USER3,          B

Then write a formula like this:

SUM({$<Store=P(STORE)>} MeasureB)-SUM({$<Store=P(STORE)>} MeasureA)

Instead of MeasureB-MeasureA

This seems to be testing out okay, but is there a best practice version of this I should follow? This definitely feels a little sloppy.

Should I move this into Section Access and Create a StoreRole column  then have a Table that says

StoreRole,     Store

ALL,               A

ALL,               B

A,                   A

B,                   B

Any assistance is appreciated.

[marcus_sommer]

In general it could be handled with the help of section access and there are at least 3 different approaches.

One would be to mask the forbidden data like described here: Mask or de-identify data for certain users using Section Access. Another approach is to use an additionally and often aggregated dataset. Both methods are not easy to implement.

Therefore the easiest way would be just to use two applications - one with the aggregated data which allows to compare all your categories which are above your detail-level and one just with details. This way of simplifying must not be a disadvantage at all else it could provide a better usability by focussing on the important things in each application.

- Marcus

[datagrrl]

My original approach was the second aggregated data set. That was pretty painful. Interesting suggestion of using two applications. I am not sure that is the route they wanted to go, but I will suggest it.

The method I am using above requires us turning off the users access to build their own objects. I have a feeling there is a way to get around that one some how.

Thanks...I will look at this article and take what you suggested into consideration.