Skip workflow steps for administrators and developers

By
Sitecore workflows are great for publishers and editors.
However, as administrator or developer, we usually have to make changes to published items without triggering a new workflow. These changes are usually technical changes/bug fixes that needs to go live as soon as possible and does not really need to go through all the workflow steps.

Create a Publish Command to skip workflow steps

To achieve this I created a new workflow command. Publish. This command basically skips the submit and approve steps and goes directly to auto publish.

The steps:
  • Create an new Command Publish under the Draft state
  • Set next state to the Approved State
  • Set this command to suppress comments


Update the Auto Publish action to include related items

Per default the parameter for Auto publish is set to : deep=1&smart=1
I recommend setting it to: deep=1&smart=1&related=1 so related items like images are published with the same action.

Setting restrictions(security) to roles so we can control who has access to the publish command 

This command is intended to be used by administrators and developers.
The publisher role and editor role should not have access to this command, by removing read access for those roles the action will not be available.



Similar restrictions should be set for the editor role, they should not have access to the approve and reject commands.



This way the publishers would have access to approve and reject.
Editors would only have access to Submit. While admins and developers would have access to all of the above including the publish command.

Comments

Post a Comment

Popular posts from this blog

Step by step guide to add Glass Mapper to Helix solution

By
Image
How to add Glass Mapper to Sitecore Helix solution There are probably different ways to set this up in a Helix solution. I have done this setup in 4 of our projects, and it has become the "template" for our new Helix solutions. We create one foundation project, which has all the glass nuget packages installed, we also choose to add a glass base in the foundation layer. All new features will have access to this glass base interface through a project reference.  I have had a lot of discussions with my co workers on where to add common fields that would be used in several feature projects. If it should be in the Glass Mapper foundation project or in a new foundation project. On "small" projects we choose to add it in the Glass Mapper foundation project, on larger projects we created a separate foundation project to add these fields and their interfaces with Glass Mapper mapping. 1. Create the Visual studio project From the Package Manager Console run
Read more

Using interfaces with Glass Mapper

By
Image
In one of my previous blog post I wrote an example on how to add Glass Mapper to Helix . I will in this blog post provide some code examples on how to map different fields with Glass Mapper. I will also provide some examples on how you could benefit more from Glass Mapper by using interfaces instead of models. Why use interfaces instead of models Interfaces can be inherited multiple times, this works well with inherited templates in Sitecore. We create the common fields in the Helix Foundation layer, and use the mappings in multiple feature projects. The mapping is created in separate interfaces. The model(interface) that should use the fields only needs to inherit from these interfaces. For example a simple component with Title and Rich Text would only need to inherit from the GlassBase, Title and Rich Text interface IMyComponent   :   IGlassBase ,   ITitle ,   IRichText Inside Sitecore the MyComponent would need the Title and RichText field The view then has access
Read more

Adding dynamic image source for multi-site solutions with $site$ token and setting dynamic datasource location for components

By
Image
Months after finishing a project I have had clients saying: We need to make a copy of the site you created and put some other content on it Most clients need to put this new site into the same solution because of restrictions in their Sitecore license. To convert old projects there was usually a lot of content restructuring and code changes needed. I have done this exercise multiple times. I try to have this in mind when creating new solutions so we don`t end up with too much effort when adding support for multi sites at a later stage. Even with great structure and code we still face some problems. In a multi-site solution you want to reuse components, but the sites should not always share the data locations and image folders. Most sites have different editors, they should not see the components and images from the other sites, we then need to place content in different folders and set the appropriate security on those. I recently got a request to duplicate an existing site,
Read more