I have configured bugzilla 5 which have admin and normal users. In bug forms, in status field, I want to show some chosen statuses to normal user. so that can be restricted from doing actions they are not authorized like.
For example - normal user can resolve a bug but can not close it.
How do I achieve this ?
This isn't really possible in Bugzilla. The workflow editor does not allow you to specify a role.
There are some limited roles - canconfirm, editbugs but they apply to all bugs in the product.
You could create a Bugzilla extension that added this functionality. https://bugzilla.readthedocs.io/en/5.0/integrating/extensions.html
Related
We're running Jira 7.7.0 and Confluence 6.0.4
Our team is split into 2nd level support and 3rd level (us).
PROBLEM:
We would like to let 2nd level to do as much admin support as possible with as few permissions as needed.
1. The software offers for Core two admin groups, but both offer too many admin rights (Jira Administrators / Jira System Administrators)
2. Confluence has 2 groups Admins and users
DETAIL:
None of the global permissions of either permit, that we allow a group to
- Add Spaces
- Add projects
- Add users
- Add groups
but keep them otherwise out of all the rest
DESIRED
A way to have a super user be able to not just manage >existing<, but also add the entities mentioned above.
OPTIONS?
A) A plugin that enhances users to be "a bit" Administrator, BUT with ADDING feature (this does not seem to exists)
B) A plugin that hides the menu items, but would technically still enable the users to execute the tasks if a URL was known
QUESTION
- Does anyone have a hint on what plugin could manage this? Either permission or menu hiding?
- Is there a way to trick configuration to achieve this (I assume not)
Many thanks!
Carsten
There is an addon called Delegated Project Creator for Jira that address your request. To get it, search for it in the marketplace under "administration".
On the other hand you can tweak the UI of both apps to control access to options using Jquery. The addon Script Runner for JIRA has some options for this.
I am facing problems with interface customizations in the latest OBIEE release.
Is it possible to "hide" the Mobile, VA and BiPublisher options - marked red in the appendix.
(Privileges in Administration and roles in EM are configured - users can not access Mobile, BiPub however the buttons are still visible - OBI 11 did not display them afterwards...)
I am looking for a "clean" design.
Any help is much appreciated
Unfortunately up to and including 12.2.1.2 (the current version) the "Visual Analyzer" menu point will keep being rendered even if they permission has been removed from the application role(s) of the user.
Mobile and BIP disappear completely on the other hand.
So the question to be asked is: how did you configure your application roles and policies? Did you reuse vanilla ones? Then it may just be the case that some rights still persist due to ootb inheritance between roles and hence some rights stay even though you think you removed them.
Here's my situation ;
On a SharePoint 2010 site, I have a workflow which gives a status "In Progress" or "Completed" to the items.
I'd like to prevent a group of people (for example : site-limited-users) from seeing all the items that have "In Progress" status.
Thank you in advance for your help !
Best regards,
Amine.
You may have several options besides messing with item-level permissions.
Using Draft-Level Security
Curiously, your requirements sound almost identical to a built-in feature in SharePoint.
If you navigate to List Settings -> Versioning Settings, you'll see that if you enable major and minor versioning, you get the option to enable Draft Item Security. Draft Item Security allows you to hide minor versions of items from users who don't have sufficient access.
By default, anyone with read access can view draft versions, but you can change it so only people with edit access can view them, or so that only people with more elevated permission level of approve can view them.
You'd just need to make sure that your workflow publishes a major version of the item when it completes.
You might want to explore the content approval option as well; out of the box approval workflows can tap into that feature to control item draft state.
Using Views to Conceal In-Progress Items
Depending on how stringent your security requirements are, you may be able to use views to prevent users from seeing the in-progress items. This would certainly be easier to manage than breaking and resetting permission inheritance at the item-level.
To prevent users from seeing in-progress items:
Edit all the public views of the list so that they filter out any in-progress items.
Ensure that the restricted group of users does not have access to create any new public or personal views on the list in question.
To allow other users to see the in-progress items, add a list view web part to a page and edit the view in that web part so that it does not exclude the in-progress items. Use page-level security or web part audience targeting to prevent the restricted group of users from being able to view the page or web part.
This achieves security by obscurity, removing any direct links by which the users could find their way to the in-progress list items.
It does not provide true security. The restricted users could, for example, directly manipulate the URL to try to find their way to in-progress items, such as by opening up the display form of a completed item and swapping out different values for the ID parameter in the URL query string.
I have two roles in bugzilla .
1 . Admin
2. Developers.
Now my requirement is, showing some chosen workflow status to the developers not all. This way I will allow developers to change some statuses(IN PROGRESS / RESOLVED) but not allow to CLOSE or ASSIGN the bug.
How should I configure it in Bugzilla ?
I am also an Admin of Bugzilla. You can set the Group access of developers like this.
In this way, they just can change the bug's status to Resolve and then you can close them after rechecking.
I have a case where if a SharePoint site owner decides to break permissions inheritance and directly manage site membership, I'd also like to correspondingly modify view permissions on items in a specific list in the top-level site.
How can I best catch those changes so I know when to apply the appropriate changes to the list items?
I'd like to have some C# code be notified when a site's permissions are changed so I can programmatically modify the appropriate list item permissions.
The best way to do this (unfortunately) is to periodically query all of the sites and check to see if inheritance is disabled. I had a similar problem and used powershell scripting to create a report on site security. If you haven't used Powershell before, don't be intimidated. The syntax is VERY similar to C#.
You can use SharePoint auditing to monitor permission changes. It will track changes down to item level. The downside is that you have to turn this feature on and it will hurt performance somewhat.
As for notification, I don't think auditing tells you about changes. I'm pretty sure you would need to poll the audit log.
There's heaps of information about auditing in this article on MSDN.
Another approach which I think might do a very good job of this is to use the SharePoint ChangeLog. Bascially, this is used by SharePoint during indexing, with the log telling the gatherer exactly what has changed, and what should be indexed during an incremental crawl.
When you have a permission change, then this should be picked up during an incremental crawl. The ChangeLog has specific parameters that can be passed to identify changes to permissions. Take a look here at the SPChangeQuery Class:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spchangequery.aspx
Specifically you can look for ChangeTypes:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spchangetype.aspx
Including:
AssignmentAdd
AssignmentDelete
MemberAdd
MemberDelete
...and more