I would like to place a delete lock on an Azure resource group so that the resource group itself can't be deleted -- but there should not be restriction on deletion of any resources residing in the group. The problem is that if I place such a delete lock on the resource group , all the resources within that resource group inherit the lock and then they can't be deleted. Is there a workaround ?
So I had this exact problem, I had users using resource groups and did not want them to be able to delete the actual resource group but still be able to delete the resources inside,
I fixed this by using custom roles, I created a custom role and cloned the contributor role and added a deny assignment to the role
Microsoft.Resources/subscriptions/resourceGroups/delete
I found the reference in additional resource provider operations. This will allow the user to still attempt to delete the group, however they will get an error if they try to. You can also find much more role based access control resources there as well. I hope this helped!
Related
Recently something is changed the way Graph is handling permissions on drive items for external(outside tenant users).
Previously when we give access Write access to an external a unique link was created per user that we can do a patch call to update the roles if we want.
Now only two links are created one which is common for all externals having write role and one for read role.
I could not find a way if I want to update the role of an external from write to read or vice versa without removing all external users with write and adding them again.
Is there a work around to update permissions for external. The documentation is also pretty old its not updated since 2017.
Note: This is the Endpoint we are using/recommended to update permissions.
A Resource Group (RG) can have individual resources under it that could belong to any of the Azure regions. So then, is there any logical meaning for 'region' for Resource Group? Does it really dictate anything? Or maybe it's just more like satisfying a unified model of Azure that pretty much everything should belong to some region, even if in minority of the cases it may make no logical sense?
A resource group is like a container that holds related resources for an Azure solution and you manage them as a group. A resource group can contain resources that are located in different regions.
"Why does a resource group need a location?" The document gives a detailed explanation.
"If the resources can have different locations
than the resource group, why does the resource group location matter
at all?" The resource group stores metadata about the resources.
Therefore, when you specify a location for the resource group, you're
specifying where that metadata is stored. For compliance reasons, you
may need to ensure that your data is stored in a particular region.
If the resource group's region is temporarily unavailable, you can't
update resources in the resource group because the metadata is
unavailable. The resources in other regions will still function as
expected, but you can't update them. To minimize risk, locate your
resource group and resources in the same region.
I am using TFS 2015. I make one user as Readers in project settings but still the user is able to create and update work-items/bugs. So, I am confused what I need to do in order to allow a user to just view the work-items/quires/stories but not add/edit any item.
The Readers group setting does not restrict ability to edit or create work items. You can do that in area path security settings Set permissions and access for work tracking. So you may create new group (in example Disallow Access Group). Then open security setting for the root area.
Deny needed permissions
In your case you have to enable View work items in this node
If you have the user only in the Readers TFS group of the given team project, the user will not be able to able to add/edit work items.
This can happen if you have altered the group membership, so that Readers are member of the Team (the team created by default or a new team), which is default a member of Contributors. This way readers TFS Group get inherited from Contributors permissions.
Verify the Readers group has below as permissions (default)
and it is not something like below
The other possibility is your user has collection level permissions so the project permissions are inherited to allow by default.
In SharePoint, I want users to add items but not be able to edit or delete them after. The "add item" permission shows "edit" not checked (i.e. so they should not be able to edit) However, they can. Any suggestions?
Are you testing as a site collection admin? they ignore permissions
SharePoint works on a highest permissions policy so if a user is in 2 groups which have permissions to the list and one group can edit but the other group cannot, they will get the edit permissions from the first group.
I would suggest double checking the permissions on the list and (as djeeg mentions in his answer) make sure you are not testing as the Site Collection Administrator as they have complete/full permissions to everywhere in the site collection regardless of what permissions you set the user in People and Groups.
I am having a little difficulty understanding when a person should configure JIRA permissions using groups and when they should use project roles. I have read the online documentation, however, the difference between the two seems subtle.
A group seems simple enough. Group users into a named bucket. Assign the group to one or more permissions within a permission scheme to enable access to functionality for any users within the group. Assign the permission scheme to a project to apply the permissions to that project.
A project role seems very similar. It does all of the above except that you can also add groups to project roles. It seems that a project role also allows a project administrator to add their own users to a project instead of requiring a system administrator.
However, I am not sure how I can leverage this. Here is an example of what I want to achieve.
Have multiple projects created in JIRA.
All of our managers, developers, etc. have the same permissions across all projects.
Our clients have access only to their projects.
I think that the best way to accomplish this is to:
Create an employees group to which I add all of our employees.
Create one or more project roles to which I add the appropriate clients.
Assign permissions to the Default Permissions Scheme using the employees group.
Copy the Default Permission Scheme to a new project specific scheme, e.g., client-scheme
Assign the client-scheme to the client specific project.
However, it seems that I am not leveraging project role membership. How does this come into play?
What is the best practice for using JIRA groups and project roles? What is the different between the two?
We are advising to work with roles as it has a couple of advantages
a. You can setup the complete configuration based on roles.
For instance you might have a workflow transition 'validated' which can only be executed by someone who is a tester.
You have the choice to add a transition condition 'user is in group tester' or 'user has the role tester'.
If you are working in an organisation where users have different roles in different projects, choosing the first transition condition (user is in group tester) will not work (or you would need a new workflow for each project)
The same applies for notifications.
You can configure a notification on the 'issue resolved' event, specifying that the 'users in group tester' get notified or 'users who have the role tester'.
When using roles, adding someone to a project is very simple - just check what role the person has in the project, add them in the project configuration (view members) and you are done. He will have the right permissions, get the right notifications ...
b. Configuration
When you use roles for configuration, you don't need system administration rights to add someone to a project. The project lead will be able to add the user. No need to bother the system admin.
Looking at your description, I would have
A project role 'employee'
A project role 'customer'
A group 'employees'
configure the project role such that the group employees is a default member of the project role employee
This way you can use the same permission scheme for all projects. When adding a new project, you just need to add the client specific userid to the client role.
When a new employee start, you add him to the employees group.
The day that you have a specific, ultra secret project, where only a couple of employees need to have access, you can remove the group 'employees' from the role 'employee' and add the specific users to the role.
Hope this helps
Francis
Historically, JIRA had groups first. Then roles came along and are the recommended way to control authorization in most cases.
~Matt
Groups are global. Roles can be thought of as per-project (local) groups.
Roles are much better: else with a large number of projects you quickly end up with a proliferation of Groups and permission schemes (one per project).
You lose nothing by using role-based permission schemes, since you can add a Group to a role.
But you gain a lot of flexibility. Eg you'd currently have the Employee role be filled with your Employees group for every project, but as your company and complexity grows, you can have different Employees per project, without having to change the permission schemes