Given my tabular model, I'm attempting to write a measure that changes behavior, depending upon which role the effective user belongs to. This isn't traditional row-level security (RLS) since I'm not trying to filter by role; just do an if-else, instead.
I've come across the following solution at https://community.powerbi.com/t5/Desktop/DAX-Expression-For-Role-Level-Security-Using-DirectQuery/td-p/489699, which I believe will work, but I'd prefer querying active directory to see if the user belongs to said role, rather than another table on the model.
I've also seen some articles (i.e. https://community.powerbi.com/t5/Desktop/How-to-leverage-Active-Directory-to-filter-the-data-in-Power-BI/td-p/140479) about getting attributes from active directory for Power BI, but nothing that exposes the DAX being used.
Bottom line, if I could get a role name in DAX or call a function to check if the user is in a role, I'd be golden (assuming performance isn't compromised).
Edit: I should add that I'm currently leveraging one of three functions to get the user. USERNAME(), USEROBJECTID(), and USERPRINCIPALNAME().
I ended up giving up on leveraging active directory and did what it appears everyone else is doing (as seen in one of the links posted in my question).
For reference, here's a snippet that illustrates the solution:
EVALUATE
SUMMARIZECOLUMNS (
"Some Measure",
IF (
LOOKUPVALUE('My User'[UsePrivilegedValue], [Name], USERNAME()),
SUM('Some Fact'[PrivilegedValue]),
SUM('Some Fact'[OtherValue])
)
)
Related
So, this is probably simple. I need to find a way to check whether a member of a scheme has renewed their membership or let it expire, I need to generate a simple list of those whom have not renewed.... There are complicating factors however, in that I cant use Excel, and it can only be a single step to Crystal reports (though I have solved the issue in Excel using a simple Countifs and if Formula)
Now for the problem.
The membership has specified Start/End Dates in separate columns in the table. It is easy to see whether this, in a row basis has expired. The issue is that if they have renewed, this is logged as a separate table entry linked by a Individual reference to the member. There are also multiple Qualifications I also need to test against.
So, whilst I can test the expiration date, the question is how can I test against the rest of the data, based on whether the Individual Reference and Qualification name and then check whether this is "Current". Doing this would enable me to therefore test whether the Membership has therefore been renewed, or not, on an individual line.
Any advice on methods would be appreciated.
Without knowing what data you have and making assumptions out the wazoo, try something along these lines
select distinct Member_id,
case
when exists (select 1
from members m2
where m2.member_id = m1.member_id
and (m2.expiry_date is null
or m2.expiry_date > '2018-01-25'))
then 'Active'
else 'Expired'
end as mem_status
from members m1
What the exists does is look and see if that member has an active status
I am retrieving users for Active directory in Jira 7 by using LDAP. I am trying to reduce the number of users brought from LDAP to a particular group that we have created. So in order to do that i put (objectCategory=group)(cn=WebAgileDevs) in the group object filter along with the default settings. The only thing i change is the Base DN and credentials required. When i save and test it does show me that it is testing 1 group and 15 users which is what i want!(See the screenshot). BUT, when i go and sync it, it brings in 43000 users!! What am i missing???
Test Remote Directory Screenshot
The group filter is used to filter the list of groups that are imported to JIRA, and the user filter is used to filter the list of users that are imported to JIRA. The two need not necessarily correspond. Your group filter would be instructing JIRA to bring in only that one group (into the list of groups), but without further refinement, your user filter will still be pulling in all users, as you noticed. This means that you need to adjust the user filter too.
From your question, you want to import only those users who are a member of a specific group. Atlassian provides some general guidance here.
The last example on that page is particularly relevant for you:
(&(objectCategory=Person)(sAMAccountName=*)(memberOf=cn=CaptainPlanet,ou=users,dc=company,dc=com))
This tells JIRA to pull in only those user objects that are a member of the group cn=CaptainPlanet,ou=users,dc=company,dc=com. You would want to replace this with your cn=WebAgileDevs (plus whatever trailing qualifiers you need to fully qualify the group name).
Just a bit of background info:
I have dimension table which uses SCD2 to track user changes in our company (team changes, job title changes etc) See example below:
I've built an Analysis Services Cube and created all the necessary hierarchy's for the dimensions and it works well when navigating and drilling down through the fact table.
The problem I have is with the filters on the PerformancePoint dashboard. As I'm using the User Dimension table with it's multiple instances of users it's showing duplicates up in the list. I can understand why as the surrogate ID is being referenced on the Dimension. But if I choose the first instance of the A-team I will see all their sales for a particular period and if I choose the second instance I will see all their sales for a different period.
What is the best way to handle this type of behavior? Ideally I'd like to see a distinct list of teams in alphabetical order and when I choose the team name it shows all of their data over time.
I've considered using MDX query filters but I'd like to see if there's anything I haven't thought about.
I realise this isn't an easy and quick question but any help would be appreciated!
The answer was simple after having a trawl through my User Dimension table on the Cube.
Under my user dimension I added 2 duplicate attributes to my attributes list ("Team Filter" is a copy of "Team", "User Filter" a copy of "User Name") these will be used only for filtering the dashboard.
Under the attribute properties for each duplicate I then set AttributeHierarchyOptimizedState to "Not Optimized", I also set their AttributeHierarchyVisible to false as I'd shown the two duplicate attributes in the hierarchy window in the middle.
Deploy your Cube to the server and go in to PerformancePoint. Create a new MDX Filter (this image shows the finished filter)
This is the code I used, it only shows dimension members which have a fact against them (reduces the list a considerable amount) and by using allmembers at the dimension it also gives me the option to show "All" at the top of the list.
Deploy the new filters and now you can see the distinct list of users and teams, works perfectly and selects every instance (regardless of the SCD2 row)
I would like to join the user object and project permission object to see how many users have been assigned to a project, for audit purpose. I don't see a common field with common values (email address or first name/last name) between these objects. I used Excel plugin to retrieve two separate data sheet and unable to map them. Any thoughts on this on how to do this?
You're probably seeing something similar to the following when you query on ProjectPermissions:
In this situation, the default User object selected from the "Columns" picker in the query dialog, gives you the User's DisplayName, which doesn't unambiguously map to a Rally UserID.
Note, however, that you can add dot-notation sub-fields of Objects manually by typing them into the Columns field. In the following example, I've included User.Username and User.LastLoginDate as additional fields I want to show on the Permissions report:
Of course, you could also just include User.Username, and run a second query on the User object with all fields selected, and do a join in Excel.
One note of caution - if you have many users (say 1,000), and a lot of projects, (say 1,000, which is not uncommon in large Rally subscriptions), querying directly against the ProjectPermissions endpoint can rapidly result in total results that number on the order of 10^6. This will probably time out in an Excel query.
The Rally User Management: User Permissions Summary script works around this by querying Permissions in a loop on a user-by-user basis. It's slow, but it returns results without timeouts. Certainly not as convenient as Excel either - you need to install Ruby 1.9.2+ and the rally_api gem to get it working.
I have a writeback partition working pretty well in a cube. The users access it through Excel 2010. At the moment there are 3 measures in the cube. I'd like to only give users access to writeback to 2 of them while being able to read all 3. Is there a way to accomplish this? I'm very much an MDX novice if MDX is involved. Thanks in advance.
The failproof way to prevent those users from writing to your measure is by including those in a special Role with writeback access. In the tab "Cell Data", check the box "Enable read/write permissions", and in the field below "Allow reading and writing of cube content" you can set an expression to limit the write measures, such as:
(Measures.CurrentMember IS [Measures].[X] OR Measures.CurrentMember IS [Measures].[Y])
In the upper field, that enables read access, allow access to all three measures:
(
Measures.CurrentMember IS [Measures].[X] OR
Measures.CurrentMember IS [Measures].[Y] OR
Measures.CurrentMember IS [Measures].[Z]
)
They will have a weird message saying that the cell was blocked, but at least you'll prevent them from writing to your beloved measure.
Another approach would be: create a Calculated measure ([Measures].[ZZ]) based on the one you want to hide ([Measures].[Z]). SSAS won't let the user writeback on a calculated measure. Make sure you hide the original by marking it VISIBLE = 0.
#mmarie is correct...if the measures are all in the same partition, then you'll need to move the 2 for writeback into a separate measure group. You can do this by creating separate views in the relational DW or via named queries in the DSV. Since both measure groups will have the same dimensionality (because they are based on the same table) SSDT will give you a warning - just ignore it ;-)