In Sitecore 8.1 why do my users need to click edit on an item before they can approve/reject it?

I'm using the sample workflow in 8.1 (rev. 160519) and users need to click the edit button before they can approve/reject changes. We don't have this issue in any other versions of Sitecore and the user is still able to approve from the workbox without having edited it first. Is there a setting somewhere that needs to be changed so that my users can just approve an item without first having to lock it?

  • Hi,

    In workflows, while Clicking on Edit locks your item ,so that nobody else works on the same item that you are working.Hence No ambiguity.

    Similarly, After editing the Item you need to unlock it so that somebody else can work upon the same item.





  • In reply to Yamini Muttevi:

    I'm aware of that, but the items are not in the edit/draft state, they are in the awaiting approval state so should not need to be locked for someone to approve it.
  • Michael Pontin

    Is there a setting somewhere that needs to be changed so that my users can just approve an item without first having to lock it? 

    You may need to give the Role, containing your Workflow Approvers, the permissions "Workflow State Write" & "Workflow Command Execute" on the affected Workflow Step Item under

    /sitecore/system/Workflows/[Your Workflow]/[Affected Workflow Step]

  • In reply to Oliver Raduner:

    Good idea, but sadly not the issue. The workflow steps have those correct permissions for the "Sitecore Client Authoring" role, which is assigned to the user. (I even checked that none of their other roles were conflicting somehow and they're not).
    Also a the user can click Approve/Reject but they have to click edit first it's unlikely to be an issue with them not having permission, as they have permission to do it at one point.
  • In reply to Michael Pontin:

    My guess is, that Sitecore requires the Workflow Approver to Checkout the Item into Edit-Mode before manipulating (= approve/reject) it, just as if it would be a regular Content Author. Can the Workflow Approver edit the fields on the Item WITHOUT locking the item into Edit-Mode? Was the item probably not checked-in by the Content Author beforehand or when passed through the Workflow steps?

    You may check if one of the following Sitecore.config settings would be useful to change/adjust to resolve the current behaviour - but keep in mind that it impacts all Content Authors working in the System.

    • RequireLockBeforeEditing = false
    • AutomaticUnlockOnSaved = true

    Source: Sitecore Content Author’s Cookbook, Chapter 4.1.4 „Locking in the Content Editor“

  • So the answer to my question is that Sitecore decided to change how the workflow panel renders small buttons and added in a flag to decide whether it should be disabled/greyed out. This flag is only ever true if you are an administrator or if the item is locked. So i'm just going to have to overwrite the WorkflowPanel.cs class so that it works the same as the older versions of Sitecore again
  • In reply to Michael Pontin:

    Good to know, thanks for elaborating the solution to your issue
  • In reply to Michael Pontin:

    This seems like a really poor decision from Sitecore. Locking an item makes sense when you are changing it, but when approving an item it just adds an extra step for no reason. It's not like someone else can make a change to the item between when you start clicking the approve button and when you finish doing so; it's a single step.

  • In reply to Michael Pontin:

    hm... I'm trying to duplicate your solution and I'm missing a step.

    1.) I used .net reflector to get the WorkflowPanel.cs file
    2.) I added it to my project and removed the flag4 variable and all references to it from Render()
    3.) Where do I tell Sitecore to use my version not the one from Sitecore.Client.dll ?
  • In reply to Brian Heward:


    If I am not mistaken, you will need to do a patch:instead in your config file where you will specify the Sitecore workflow namespace woth your namespace.

  • In reply to Hishaam Namooya:

    patch:instead replaces content in a .config file doesn't it? WorkflowPanel isn't referenced in any config file so I don't think this works?
  • My guess is that this might be an issue with the Workflow configuration or state not reflecting properly. If the item has been edited by a Content Author and submitted for approval it should always show the Approve / Reject Button. If you see an Edit button this means your content item is not pushed into a workflow yet and as soon as you hit Edit - a new workflow is initiated thereby showing you a CheckIn / Approve / Reject buttons.

    Also ideally permissions should be set at user roles level to make sure Content Authors can only Edit and Submit - so once you hit Edit button you should see only a Submit Button which will send your content item in Awaiting Approval Workflow state.

    Let me know if this helps.
  • In reply to Paritosh Tripathi:

    No sitecore 8.1 update 3 changed this. It doesn't matter if it's in a workflow you still need to lock it before you can change it's state now, (this is something all of my content editors are complaining about and want reverted.)

    I looked into the code in WorkflowPanel.cs as Michael pointed to and I see the problem. I'm just unsure what the final step is to undo the change Sitecore put in is.
  • In reply to Brian Heward:

    Sorry wasn't getting emails to tell me that anyone was still replying to this thread, the location for the item you need to change to reference your code is /sitecore/content/Applications/Content Editor/Ribbons/Chunks/Workflow/WorkflowPanel in the core database.
  • In reply to Michael Pontin:

    Perfect that fixed it.