In my Bugzilla 3.4.4 (maybe others too) it seems that newly created user without any rights assigned can search thru all bugs. Is it possible to block it so that users can only see them when they are assigned to the right groups?
Yes , this is possible.
Administration/Products/choose the product you want to hide/press "Edit Group Access Controls"
If you set the options of the product group to Mandatory/Mandatory without marking any of the check-boxes ,
any user that is not part of that group , will not see the bugs related to it at all.
This will work in case of new users , due to the fact that new users don't get that permission automatically (by default).
TIP: instead of manually creating group for each product , you can set Administration/Parameters/Group Security/makeproductgroups to ON
NOTE: this is true for Bugzilla 4.2.1
Related
I've got a table which was set up wrong ( as an application table, but a maintanence view was created ) but it should be an customizing table, so that we are able to transport the entries of the table.
So far I changed the type and maintainablity of the table, now it is type C ( Customizing ) and changes can be made without restrictions. I've also changed in the technical settings the type to APPL2, so it is a customizing-table. After those changes I've deleted the original table maintanence generator view and generated a new one.
My problem is, that when I save my new / changed entries in sm30, I won't get asked for a transport request and the option to put them into the transport request in sm30 ( via the menue ) is not available. It is outgreyed.
How can I change my table / what do I need to do, that I am able to transport my customizing entries?
In the Table-Maintenance-Generator there is an option called "Standard recording routine" which needs to be selected.
of course credits go to #JózsefSzikszai who gave the answer in the comments :)
Just follow these steps:
More->Utilities->Table Maintenance Generator.
Under Dialog Data Transport Details select "Standard recording routine"
I'm looking for a way to migrate data from LDAP-hosted groups to Google Groups.
With GCDS only the users are migrated, but I would like to migrate the data, do you know any way?
Thanks team
I've migrate groups between different directories using custom-written scripts. This requires some type of mapping between IDs. That is I know the fully qualified DN of each member within the LDAP-hosted group, I can match that up to a record in the new directory -- e.g. cn=lisa,ou=users,o=example has uid lisaj, and there's a corresponding account with the logon id lisaj in the new directory. I've had to do migrations where there was no direct correlation available within the two directories, and successfully linked the two systems using a text file with cross-reference info. A line in the file might say "lisaj 019485-B9184A-9284C-1949" to map my user id in the old system to a record identifier in the new one.
Basic process:
Connect to source LDAP
Find all in-scope groups For each in-scope group, get member list
Find the corresponding group in the new directory (if none exists,
create it)
For each member, find corresponding account in new
directory
Add member to group in new directory
(https://developers.google.com/admin-sdk/directory/v1/reference/members/insert
for Google Groups,
https://github.com/alfasin/Google-Admin-Directory-API has some Python
examples)
As a one-off process, it's pretty simple. If you need the two directories to remain in sync for some time, the script becomes a little more complicated. Assuming the old directory is "authoritative" (the one with the 'right' data -- and you can only make changes in one of the directories, otherwise it's impossible to tell which members actually should be in the group), you need to check the new directory group for any members that aren't a member of the old directory group and remove them as well as add any old directory group members that aren't in the new directory group yet. I generally add a "last modified" constraint to the filter used to locate groups in the old directory -- e.g. find all group objects where the lastModified timestamp is in the past 24 hrs -- to avoid continually reprocessing data for groups that haven't changed.
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])
)
)
I have a BO4.1 environment that has been build by my predecessor (who is unreachable).
There are 2 universes.
Both are based on the same sourcetable.
Both contain the same clientdata (name, adress SSN).
I have two usergroups: TESTUSERS (standard-user) and POWERUSERS (admin)
When making a report through Webi usersin the group TESTUSERS can see the SSN in Universe A but cannot see the SSN in Universe B. TESTUSERS should not be able to see the SSN in Universe A.
POWERUSERS are allowed to see that data.
For the love of StackOverflow I cannot find out how to the SSN is hidden in universe B (how it should be). How do I hide/show dimensions based on the group the login belongs to?
To be clear: the SSN should not be selectable for group TESTUSERS when creating/modifying a report. This question is not about how to hide the SSN in reports
For unx universes, objects can be hidden from certain user groups via Business Security Profiles. In IDT, go to Window -> Security Editor, and log in to the session that the universe is in. In the "Universes / Profiles" dialog, navigate to the universe that currently has the restriction applied. Underneath that universe should be at least one security profile. From here, you can edit it or view/change the groups it applies to. To add the same restriction to the other universe, select that other universe and then click the "Insert Business Security Profile" icon above the universe list.
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).