One option is to hook into Sitecore's user:updated event (and optionally user:updated:remote). This event is raised when a user has been updated, the remote event handler is raised when a user was updated on a remote Sitecore instance.
EDIT: As pointed out in the comments by @SzymonKuzniak, you can also hook into the roles:usersAdded[:remote] event to ...
Yes, "admin" is not a role and cannot be assigned to a role. You shouldn't do that either. If you need that many admin users, there might be something fishy with your security requirements.
You might want to check the overview of the Sitecore roles (https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/security_and_administration/...
If you need to get a base roles for role, you can use the GetRolesForRole(Role role, bool includeIndirectMembership) method of RolesInRolesManager.
For example, if you need to get a base roles for each role of user, you can use something like below:
foreach (var role in Sitecore.Context.User.Roles)
var basedRoldes = RolesInRolesManager....
Deny access right cannot be overwritten by any allow rule.
What you need to do is to:
remove that Deny read access for Editor role
make your Approver role a member of Editor role
disable inheritance of access rights for that item for your Editor role
and for your Approver role you need to assign Read and Write back
More information can be found in https:/...
So you want item A1B1C1 to only be accessible by RoleA1B1C1? First thing would be this, I'm assuming that RoleA1B1C1 is inheriting RoleA1B1, and then RoleA1B1 is inheriting RoleA1. Otherwise, depending on your other security, RoleA1B1C1 might not be able to see the ancestor items.
So there's a few assumptions going into this, but if I understand your ...
I was able to find the processor(Sitecore.Pipelines.HttpRequest.ExecuteRequest in Sitecore.Kernel) which adds these query strings and they are not configurable. To fix the issue I created a new class(CustomExecureRequest) and copied the processor and removed the query strings from HandleSiteAccessDenied, HandleItemNotFound and other methods.
I then created ...
Delegated Administration with SPE
Let's say for example that you wanted to provide a Context Menu option for users to unlock items based on the following criteria.
Show when User is in the sitecore\Delegated Admin role
Enable when the item is locked
In between cooking eggs at home I was able to whip this up.
So here is how I built it.
Create a new SPE ...
Assuming you're only interested in shell behaviour, there's a long and a short answer.
Short answer: no. The command that executes this functionality (Sitecore.Shell.Framework.Commands.CheckIn) only allows the unlock action to happen if the user is an administrator or if the user owns the lock. This is regardless of permissions you set on the button item.
As @Gatogordo mentions, you likely shouldn't be using Administrator. This should be a checkbox you use on your 'emergency' account which you use to access things that nobody should access.
Inheriting default roles
It is very common to have a group of Sitecore System Administrators who need to be able to do things like set security on users, have access to ...
You can't directly set permissions to restrict user to only be able to add certain roles. But you can use Sitecore local managed domain to sort of workaround this issue.
Basically, you would have
One or more Locally managed Domain
Within each local domain, the user with local administrator role can only assign it's own domain level roles to a user.
Since you mention the use of TDS, you can manage the synchronization of all Roles and security on item using features available in TDS. This has the advantage that both Roles and the security becomes part of your solution and can be deployed both locally and across all environments in a consistent manner.
It is possible to serialize any ...
What Joost say is 100% correct, I recommend to use specific domain to specific website.
Is really easy to copy your dictionary domain from /system node to other place.
In version 6.6 as far I remember in site definition was introduce a new attribute dictionaryDomain.
I recommend to add the dictionary item not under System node and to be specific to the ...
You shouldn't place dictionary content items under system. Instead make a dictionary item that inherits from dictionary under your content node and apply appropriate access to this item.
If you still want to I'd recommend making a 'Dictionary editor' role and give it read/write/create/delete permissions on system/dictionary.
To do this first click '...
From the vanilla instance it should be easy to package up the Roles you are missing and then just install that package on your client instance. I have had to do that before. Packaging roles is nice and simple.
You cannot disable this via user access. The only way to hide the target tab is to override the sitecore publish restriction UI. I have written an article on how to achieve this. The url is here.
In brief, you will need to override the Sitecore UI Set Publishing. The path to this xml file is found at Website\sitecore\shell\Applications\Content Manager\...
There two special access permissions for languages.
Language Read and Language Write.
To see them in the Security Editor/Access Viewer click Columns and then tick them in the list. Then you can set security permissions per language items (below /sitecore/system/languages/).
To answer your question, its always good practice to add the same permissions to all lower environment but the point here is find out why the permission no longer exists.
I think it depends on where you apply the permissions, in another words, if your deployment overrides the permissions on certain items which seems like the case.
You should always bring ...
Have you given the user any other roles at all or just the new roles?
In order to give the user basic access to Sitecore you will usually need to give them the Sitecore Client Authoring & Sitecore Client Users roles too.
There is more info on OOTB roles and what they do here:
You can choose any folder. Just not one that is being used for anything else.
The reason being; the Unicorn default datastore expects YML files of Items. Roles and Users are not items - the two stores are not compatible.
As the Url Redirect module is a 3rd party Sitecore module, by default it doesn't have any access rights applied to it (I just installed and checked to be sure).
You will need to pick your role, or create a specific role, and then assign security rights to the Url Rewrite folders that you want editors to be able to read/edit.
I would create 2 roles, <...
The sitecore\Sitecore Client Securing role grants access to features and applications used to assign access rights.
Gives the user access rights to security features in the Content Editor and other relevant applications.
This role is intended for users who need to maintain users and access rights.
You need to assign the sitecore\Sitecore Client Account ...
Access rights are stored directly on the items.
You cannot move access rights assigned for a role or user to another environment using content packages without including those items inside content package.
Access rights for items is just one field there:
If you check raw values of that field, it's just a string value, e.g.:
When working with SPE you can use the rules fields (Show/Enable) to manage the state of the buttons. I use these at work all the time and work reliably.
As you can see in the following figure, the Elevated Unlock feature included with SPE makes use of the rules fields.
The documentation in the SPE book outlines in which scenarios the Show Rule and Enable ...
This is expected behavior as permissions are part of items. There are stored in Security section in Security field:
Switch to 'Raw values' in View Toolbar to see it like above.
It is always best practice to have same roles and permissions on all environments so all features are also testable.
If you are not planning to add roles on all environments then ...
The issue does appear to have something to do with the fact that this field was using a depreciated type. The Type "link" appears to only allow editing by Admins. When I changed the type to "General Link", authors were able to edit.
I don't know what sort of side effects I may expect, but so far in my testing, everything has worked fine with the only side ...
You actually answered the first part of your question in your comment on this post, while responding to my incorrect suggestion that the user should be a member of the sitecore domain to access Sitecore. I have updated my answer with the correct information and my recommendations for your needs, below.
Adding Access to the Sitecore Client
The Sitecore ...
No, there is not. Sitecore's security (of which Workflow is an integral part) is Role-based, not individual based. The ability to "see" and "act" on an Item in the workbox is determined by the following:
Does the User have "Write" rights to the Item in question?
Does the User have "Workflow Write" rights to the Item's current Workflow State?
if either of ...