In earlier versions of Sitecore XM/XP (think v8.0 and earlier) when an item entered Workflow, it was possible to immediately carry out a review action on an item (i.e. approve or reject the change).

There was a change in versions later than 8.0 that before being able to carry out any review action, you first had to Lock & Edit the item. Only after locking does Sitecore enable the workflow commands. The intention seems reasonable: prevent someone else from altering the item during the short approval window by ensuring that the reviewer technically “owns” the item lock.

Whilst the intention may have been good, for many teams, especially smaller marketing teams, this extra step introduces unnecessary friction. In our case, the team relied heavily on the Workflow Gutter Icon for a quick approve/reject shortcut. With the newer lock requirement, the gutter action is now disabled (greyed out), and of course, you can’t Lock & Edit an item from the gutter itself.

Why It Happens

Digging through the code, there was some additional checks added in the code that require the current user to hold the lock before the workflow command becomes available:

1        public override void Render(HtmlTextWriter output, Ribbon ribbon, Item button, CommandContext context)
2        {
3
 ...
4
 bool flag1 = this.IsCommandEnabled("item:checkout", obj);
5
 bool flag2 = WorkflowPanel.CanShowCommands(obj, commands);
6
 bool flag3 = this.IsCommandEnabled("item:checkin", obj);
7
 bool flag4 = Context.User.IsAdministrator || obj.Locking.HasLock() || !Sitecore.Configuration.Settings.RequireLockBeforeEditing;  /* THIS IS WHAT CAUSES THE LOCK TO BE REQUIRED */
8
 this.RenderText(output, WorkflowPanel.GetText(context.Items));
9
 if (!(workflow != null | flag1 | flag2 | flag3))
10
     return;
11
 ...
12
 if (flag2)
13
 {
14
     foreach (WorkflowCommand command in commands)
15
         this.RenderSmallButton(output, ribbon, string.Empty, command.DisplayName, command.Icon, command.DisplayName, new WorkflowCommandBuilder(obj, workflow, command).ToString(), this.Enabled & flag4, false);
16
 }
17
 ribbon.EndSmallButtons(output);
18
 Context.ClientPage.ClientResponse.EnableOutput();
19        }

The Fix: Override the Lock Check

Thankfully, the behaviour is easy to customize. With a small override, we can bypass the lock requirement while still keeping the rest of Sitecore’s permission model intact. We can simply set flag4 value to the same as flag2, which does all the necessary checks of a user permissions and whether they would be able to view and execute this workflow action:

1bool flag1 = this.IsCommandEnabled("item:checkout", obj);
2bool flag2 = WorkflowPanel.CanShowCommands(obj, commands);
3bool flag3 = this.IsCommandEnabled("item:checkin", obj);
4//bool flag4 = Context.User.IsAdministrator || obj.Locking.HasLock() || !Sitecore.Configuration.Settings.RequireLockBeforeEditing;
5/* Override: Use same logic/permission to enable the command as allowing showing to user */
6bool flag4 = flag2;

Enabling Workflow Actions from the Gutter

We also want the same behaviour applied to the Workflow gutter icon so the quick-approve shortcut works as it did in the earlier versions:

1foreach (WorkflowCommand command in workflowCommandArray)
2{
3    string click = new WorkflowCommandBuilder(obj, workflow, command).ToString();
4    //contextMenu.Add("C" + command.CommandID, command.DisplayName, command.Icon, string.Empty, click, false, string.Empty, MenuItemType.Normal).Disabled = !WorkflowUIHelper.IsWorkflowUiCommandsEnabled(obj);
5    contextMenu.Add("C" + command.CommandID, command.DisplayName, command.Icon, string.Empty, click, false, string.Empty, MenuItemType.Normal).Disabled = !IsWorkflowUiCommandsEnabled(obj);
6}

We also need to introduce a helper, which is very similar to the original Sitecore helper, but checks if user could Lock the item:

1/* Custom access check for workflow */
2public static bool IsWorkflowUiCommandsEnabled(Item item)
3{
4    return Context.User.IsAdministrator || item.Access.CanWriteLanguage() && (item.Locking.CanLock() || item.Locking.HasLock());
5}

Result

With these updates, any user with the appropriate workflow permissions (in our case, assigned through role-based access at each workflow state) can approve or reject an item without having to first Lock & Edit it.

If a reviewer actually wants to edit the item content, they must still explicitly lock it, so normal editing rules still apply. This simply restores the smoother review experience that many teams were used to.

You can find the code in this Github repository, including a Sitecore package if you want to easily enable this yourself.

https://github.com/konabos/Konabos.Commands.Workflow

Hope this was helpful.