13

The minimal out of the box sitecore role that gives you such capabilities(considering no overrides were done) is sitecore\Sitecore Client Designing If you need to assign a role to your own custom role you can give read access over the buttons chunk beneath /sitecore/content/Applications/WebEdit/Ribbons/Chunks/Layout Modes And the the actual tab sections ...


9

Modifying raw security values Open the Content Editor Locate the item that represents the template field On the View tab in the Ribbon, make sure the following checkboxes are checked: Standard fields Raw values Go to the Security section Insert the following text into the Security field: ar|sitecore\Everyone|pe|-field:write| Save the item. This will ...


8

I believe the item you're looking for is here: /sitecore/system/Settings/Security/Policies/Page Editor/Navigation bar/Can Edit in the core database. By default, the Sitecore Limited Page Editor or Sitecore Minimal Page Editor roles seem to deny read privileges to that button.


7

Go to Core DB and navigate to '/sitecore/content/Applications/WebEdit/Default Rendering Buttons/Options' & apply corresponding security on this item. It would look like :


7

Yes it is possible to disable the drag option. From my investigation, there are 2 ways you can disable it. Solution 1: Comment Out Javascript You can disable the drag and drop feature by commenting out the method initialize in the javascript. Navigate to the \Website\sitecore\shell\Applications\Content Manager\Content Editor.js. Open the Js file and ...


5

The the role to see the actions, you have to assign the permissions at the action level. Without that, the role will be denied the permissions to see the action.


5

You can do this by changing the security on the application in the core database. The Role Manager located here: /sitecore/content/Applications/Security/Role Manager. The default security on it has /sitecore/content/Applications/Security/Role Manager with read permission: You could add a new role that only has read permissions for this application and not ...


4

What you are trying to do here is actually better accomplished through Workflow. Using Workflow Remove the target users from the Sitecore Client Publishing role(s). Add a Workflow Action to the final Workflow step that automatically publishes the Item version that was just finalized. An example of this setup is provided in the Workflow included in a new ...


4

Further to what Chris already said; it helps if you expand the security view. Click "Columns" in your Security Editor, and bring in the additional columns you need to look out for.


3

Role based permissions and what items they affect are not contained on thr role itself. All security is actually an attribute/field on the item itself, and only maps to a role. The only data that a role has is to map which users are members of a specific role. You will need to package up the Content Items, in addition to the role (if the role isn't ...


3

As it turns out, there is actually a Sitecore setting that controls whether or not Sitecore should check security on each node when rendering the tree. If set to false, all nodes are shown and the error message that I described in my post is displayed if/when a user tries to open an item they do not have read access to. <!-- CONTENT EDITOR CHECK ...


3

If you want to restrict access to all renderings selected in the Allowed Controls field of a particular placeholder settings item, you can just restrict read access to the placeholder settings item. If you are trying to be more selective, you may want to add your own processor for the GetPlaceholderRenderings pipeline. You could use the rules engine to ...


2

One possible solution is to create a rule that runs either on: item:open if user shouldn't be able to read the item if denied editing access item:lock if user shouldn't be able to lock and edit if denied editing access item:saving allow user to make changes but not save if denied editing access etc. The rule's condition and action logic would read similar ...


2

As pointed out by @michaelwest in the comments, this turned out to be a custom access right added to our solution. I need to dig into how we are using it but I think it is what @sandbeck is describing above - hiding an item from the user but allowing the application to still use it. Thanks for the comments!


2

The solution I used was the publishing Roles (as in the description) in addition to a workaround for the bug in Sitecore mentioned above. You can find the full solution here Update: In short, the workaround to overcome the bug in Sitecore was to override Sitecore's 'PublishForm' and uncheck the publish with sub-items checkbox by default. So every time the ...


2

Received some help from Sitecore support and turns out there is a "loggedin" pipeline that gets called when logging in normally via /sitecore/login. Starting this pipeline after the LoginVirtualUser() call, successfully authorises the client to access the Media Library Search bar: private ActionResult VirtualLoginToSitecoreShell() { // set user ...


2

You would need to set Publishing.CheckSecurity to be true to prevent users from publishing content that they don't have access to (Items will be published only if the user have write access, and will be deleted if the user have delete access) <!-- PUBLISHING SECURITY Check security rights when publishing? When CheckSecurity=true, Read ...


2

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 ...


2

Mind the error message in yellow "You cannot edit this item because you do not have write access to it". You also have to have Write permission allowed for items below "Blogs" item in order to use workflow states. It is not enough to have Workflow State Write or Workflow Command Execute permissions for your approver role.


1

Can you please check in Access viewer that no other role is overwriting the permissions you have assigned (specially workflow related permissions).


1

It looks like the setup of roles was correct, however the way permission was given was incorrect. I will detail the correct way here as I don't think it's very clear from google searches currently. First of all, sitecore\Sitecore Client Users is the minimum necessary for a new user to be able to login, the new custom role should implement this or any role ...


1

Best approach would be to disable or hide publishing targets completely based on role permissions. Administrators would still have access to all publishing targets but content editors would be restricted which is exactly what you had in requirements . You should always aim to hide or disable functionality which users should use or click to avoid confusion. ...


1

For anyone who finds this in future: My problem was the 'Author' role being applied to my user. For whatever reason, this conflicts with WFFM. Removing the role has no noticeable effects on my users and seems to have resolved the issue.


1

So I found that this was connected to a new config file that came with my upgrade to this version. /App_Config/Include/Sitecore.DefaultLanguage.config. I thought this was related to the AD since it worked in the past. I already had changes done to the sitecore.config for ContentLanguage Language ClientLanguage This was overwritten by the Sitecore....


Only top voted, non community-wiki answers of a minimum length are eligible