Exclude Entity Members in Database Security
Hello all,
how can we exclude a memeber from an Entity in a Database Security?
The "Exclude" button is "grey".
Kind Regards
Stefan Batalia
Answers
-
Dear Stefan Batalia,
for Database Security Profiles only "positive" Selections are allowed.
To get your case working you have to select the Members the user should be able to see.
Exclude is not supported for that reasons.
Hope it helps
regards
Alexander Kappes
0 -
Hello Alexander,
"To get your case working you have to select the Members the user should be able to see".
That is not really practicable.
We have many user and in the Entität where we will exclude 1 member, we have also many members.The next problem is, that everytime when we add a member to that Entity, than we must also change the Database Security.
Regards
Stefan Batalia0 -
Dear Stefan Batalia,
well many customers have the same situation.
To get it work you have the following opportunities.
For the reason only 1 member should be excluded create an aggregation to this dimension , where you just have to define which Elements should be authorized and which not (2 members inside).
When you insert new members to the dimension you want to authorize just use ETL or something similar to mark them as active.
Hope it helps
regards
Alexander Kappes
0 -
Hi Stefan Batalia,
Forgive me if I've misunderstood but I am making the following assumptions based on what you've written:
- You have a data category [entity], currently with four members [-,0,8,9].
- You want to load and display ALL records, regardless of category, at dataload.
- You want to exclude from view all records which are categorised [8 - Closed by finance] for specific users/profiles.
- You want to be able to see all records for specific users/profile holders.
With the above assumptions, you can achieve all that you need by creating a parent group to include everything but the excluded member/members as required.
I do not know your level of BOARD understanding. Also, I like to provide more complete answers which may help future community members. for these reasons, I will illustrate the steps required to achieve what I think you're asking. I do appreciate that you will probably know a number of these steps so please don't be offended
Using a database security filter and applying a parent entity - One of many methods.
Overview and principle solution
In principle, to apply a security filter on a dataset that does not have the required parent category, we must modify the existing hierarchy. This is also what Alexander Kappes has outlined in his response; In fact, my response illustrates the steps required to achieve what Alexander summerised - I clearly had way more time to play with, on a Sunday!...I really, really need a life. Anyway...
Image 1 illustrates a hierarchy where [Record] is the primary dimension and [Record Status] is the categorisation you currently have. [Record Status Group] is the parent entity and used to hide/show the relevant entities in database security.
Image 1 - Hierarchy to group shown and hidden members:
Application
STEP 1 - Firstly, create the [Record Status] entity - you will have already done this but I've included the step for continuity. Image 2 shows the 3 principle entities and the members of the [Record Status] entity. Note, by hiding the [Record Status Group], users would never see this 'helper' entity.
Image 2 - Entities used within Hierarchy shown in Image 1 plus an extended number of members in the [Record Status] Entity to represent changes over successive dataloads.
STEP 2 - Create a parent entity [Record Status Group] - Image 3 shows the members SHOW and HIDE
Image 3 - Record Status Group parent entity members
STEP 3 - Create the Hierarchy as seen in Image 1 using the 'relationship editor'.
STEP 4 - Amend dataload, adjusted to upload the [Record Status Group]. The process could be applying a CASE statement in your SQL routine, using BOARD ETL processes or a data table as seen in Image 4.
Image 4 - Data table including the parent entity members mapped to easch record and record status.
STEP 5a - Application of [Record Status Group] for filtering out hidden members.
Select a User or profile to apply the filtered selection to - Image 5 shows the steps to apply the selection to a profile.
Image 5 - Applying the filtered selection in database security agailst a profile. Note the filter symbol next to the Profile name. This is the only indicator a developer has that a filter is being used. The developer must investigate to establish what the entity and settings are. There is an alternative approach outlined in STEP 5b.
STEP 6 - Construct a screen to use the filter.
Image 6 shows the same screen but for two different users; LiteP and Developer. Note that for the litep user, the parent entity and the main category entity only show what is permitted - entity member 8 is missing (filtered) but no filtering is applied to the Developer's view.
Image 6 - The same screen but for two users; LiteP (filtered) and Developer (Not filtered).
STEP 5b - Custom Selection Script: Aternative Application of [Record Status Group] for filtering out hidden members.
Step 5a is effective in applying a security filter but is hard to see what has been filtered without first opening the filter selection and scanning down it. An alternative approach is to type in the security filter in the custom selection script area. The syntax is: [INSTRUCTION] [ENTITY] [OPERATOR] [VALUES] or [Select] [Record Status Group] [=] [SHOW]. Image 7 shows where this script is entered and here is the BOARD manual entry relating to the 'Database security profile concepts'.
Image 7 - Custom Selection Script
Stefan Batalia, I hope that this was what you were looking to achieve? If it was not, please feel free to contact me and we can discuss the matter further.
Regards,
Paul Wyatt
1
