BUGZILLA - How to edit Assigned To list? - bug-tracking

It is possible to define in bugzilla the own list with assgined to users? In out company we have a lot of customers but when the customer assigned to one product he visible on all products on "assigned to" field. Can I change my assigned to select?

Look at Security Groups - http://www.bugzilla.org/docs/4.2/en/html/groups.html
Then navigate to the group security page.
Administration -> Parameters -> Group Security
Find the setting makeproductgroups and ensure that is is On.
Next find the usevisibilitygroups setting and ensure that it is On. This setting prevents someone in group A from seeing the people in group B. This is especially important if you are letting multiple clients view and/or edit their bugs.
Finally find the strict_isolation setting and ensure it is On.
Now create your groups and assign them to products and users.

Related

Wondering how I might be able to debug this ACL issue

I'm adding security around some buttons in an app I built long ago. The way I implemented this security feature is that I created a a role in the database's ACL. I do a check in the button's hide-when formula and expose the button if the role is there. That role is assigned to a security group in the Domino Directory. That security group contains a collection of other groups. These 2ndary groups contain people's names. Those names are retrieved from a Postgres database -- I have a LotusScript agent that pulls the names from that database. The problem I'm seeing is that even tho a name is in the 2ndary group, Notes doesn't recognize it. Here's an example. This user are in these groups:
however, he should also be in all of these:
How can I debug where the problem is?
thanks
clem
I think the problem is that for one group in particular, there are 2 copies of the group document. I didn't see that b/c in the main group view it doesn't show up. But when I was in the process of assigning a child group to a parent group, I can see the duplicate listed. I suspect this is the source of the problem. Will confirm.
thanks
clem
Make sure the members of the 2ndary groups contain names in fully qualified format that matches the first entry of their FullName in the person document. EG "John Smith" should be "CN=John Smith/O=LabWare" or something like that.
You can see what groups and roles the system recognizes a user in by double clicking on the security icon on the status bar in the Notes Client (bottom 3rd from the right) after you have opened the database.

Bugzilla restrict bug status

We need a solution for one of our deployment in bugzilla.
Example of our scenario are as below :
Group : Staff,Students
project/product bugs : projectA , projectB
We need to know is there any way to :
1) Restrict the group of user from accessing the project.
Example= Students cannot access or view bugs in projectA.
2) Restrict other group of user from confirming or change the bug status
Example= Students cannot change the bug status of projectB from NEW to RESOLVED
3) Some members set of group can only file a bug but not close the file
Example= StaffA can only file a bug in ProjectA but cannot closed it whereas StaffB can file the bug and also can close the bug
From what I have search/Google, there are no documentation available which can explain this function in bugzilla.But maybe I have overlooked somehow.
Our current bugzilla is version 3.2rc1
Thanks in advance.
You didn't really say which version of Bugzilla you are using, so the URLs are for the latest release, 4.2. However, the same concepts apply to most recent versions. For instance, we use 3.6 and control whether certain users can change certain things in the same ways that I describe below.
1) Restricting users who are not in a group from seeing bugs is what Bugzilla's group security does:
http://www.bugzilla.org/docs/4.2/en/html/groups.html
One wrinkle in your case is that group security controls positive access rather than negative access. That is, it allows specifying which groups can view bugs in a product rather than groups that cannot. To keep members of students from viewing bugs in projectA, you'll need to have a group that can access projectA and devise a way to keep users in students out of that group.
Alternatively, you could put some custom code into Bugzilla::User::can_see_bug, Bugzilla::User::visible_bugs, or Bugzilla::Bug::check_is_visible to exert firmer control that users who are in group students can never see bugs in projectA
2) You can exercise a lot of granularity in allowing changes:
http://www.bugzilla.org/docs/4.2/en/html/cust-change-permissions.html
We do something like this. We have a set of users to whom we want to grant read-only access unless we have explicitly allowed read-write access. To do this, we have a group called allspecialusers to which these users belong based on email address. We have another group called approved_specialusers to which some of those users are added manually.
So, in our Bugzilla::Bug::check_can_change_field, we have code like:
if ($user->in_group('specialusers') &&
!$user->in_group('approved_specialusers')) {
$$PrivilegesRequired = 3;
return 0;
}
You can do what you want by checking if the bug is in product projectB and the user trying to make the change is in group students

does sharepoint have itemwise permissions , just like it has list wise permissions

( Regarding Moss 2007 )
i have created a sharepoint list in which one column is called user assigned - this is a lookup column of type - people and group.
i select the users from active directory to enter this field of the list.
So different items in this list have different users assigned
I have create permissions for this list to be read and write to the users in active directory .
so that when a particular user logs in to the sharepoint website with his credentials. he has read and write access to the list.
Now is there any way available in sharepoint by which the user do not see the whole list when they login to the website . He only sees the items of the list which the user assigned field is him only.
If the permissions are indeed setup right, you only have to go to List Settings, Advanced Settings, Item-Level Permissions and on "Read access: Specify which items users can read" you define their own.
If the users are not the creators of the items, you need to go to List Settings, Views (at the far bottom), modify the All Items View (or w/e you have as default), go to the filter section and add a filter like: "Show items only when the following is true", "Show the items when column" Assigned To is equal to [me]
I've been implementing such solutions for some while. It is possible, but
it takes much work to be done
if used in long term and/or the amount of data is large, this will hit performance
If none of these is a problem for you, then you can:
create code which performs BreakRoleInheritance() on the item, then adds ViewListitems permission for the user in "user assigned" column. You can find example code, for instance, here: http://social.msdn.microsoft.com/Forums/en/sharepointecm/thread/581e456c-db3c-44f1-b958-a824d95a2536 (or search in Google for "SPPrincipal" and "SPRoleAssignment" for more info)
make this code be called whenever the item is added or updated (you have to wait for the "-ed" events, because in the synchronous version of these events you can't change the permissions yet, for instance in "ItemAdding" there is no item created yet). You can achieve this by adding an event handler to the list.

How to create a different user category in SharePoint and a view designated only for them?

How do I create a different users category? (more restrictive - with view only properties)?
How do I create a View - only for this category of users?
I need to group some users into a view only category and then assign only ONE view to this group, so they can not see everything that is in my list.
SharePoint, so far, does not give the option to restrict access at cell level so I need to go around this and create a view for this group, with the condition that all that they can see is this View (and they should not be able to add columns to this view).
Thanks.
Considering that you want to restrict the List View to only specific set of users. You have the following options
Doing it in the SharePoint UI but not suitable if you have lots of item and you want to do it for a SharePoint Group.
Open Source - CodePlex Good one I have tried it - It has got what exactly you want Column level restriction
Third Party in case if you feel to spend $ - Seriously I didn't try this tool.
Another Option to do it in SharePoint UI - Quick solution but - Wont prevent user from creating their Own Views.

Override SPList.WriteSecurity behaviour?

As MSDN states, then WriteSecurity has 1 of 3 states possible:
1 — All users can modify all items.
2 — Users can modify only items that
they create.
4 — Users cannot modify any list
item.
But if I want behavour nr. 2 plus users can modify items that are assigned to them? Well if I grant a user full permissions (put in owners group) for list, then those can edit any item (not good). So why wouldn't it work by setting item level permission "full control" just for AssignedTo user (good)? I did, but that didn't help - access denied.
I want exactly the functionality as stated in question "Automatically set list item permission, after new item is created", quoting:
Every users (Supervisor and team members) can see any tasks.
Supervisors can edit any tasks
Team members can only edit their own tasks (tasks that were assigned to them, or created by them)
but although answer has been accepted, the solution does not provide a way for users to edit items assigned to them or items created by user.
Help is appreciated, thank You!
Your only way to do this is using Item-Based Permissions. E.g. have a Workflow or Event Handler change the permission on each file/object based on your requirements.
The solution you quote from the other task is simply setting 2 for SPList.WriteSecurity which still doesn't give users the possibility to edit something they have not created, but were assigned to - in this case you will need to give these users permission, e.g. by listening on the "Assigned To" field with an Event Handler (OnItemUpdated) and give the respective person the needed permission.
Furthermore the solution talks about just setting higher permissions for the users who should always be able to edit items (managers), which is a solution, but you do not have the granularity you usually want in situations like these.

Resources