Blog posts by Khurram Hanif

Content Approvals Require comments for Decline and Approve

Mon, 10 Apr 2017 14:47:13 GMT

This is the last feature in Content Approvals before we remove the Beta tag and make it public.

This feature allows administrators to configure an Approval Definition with require comments on Approve and/or Decline.

Once this is configured then a reviewer must enter a comment while approving/declining.

The entered comment is captured and will be used in Approval Notifications. The Approval Notification email is also changed a little bit in order to present clearly about what has happened and the comment.

The logged in user will get the same notification instantly with approve/decline comment.

If the item is the part of the project, the captured comment can be seen in item's activity feed in Project overview.

All the comments captured during approve/captured will also be part of the Change log.

There is only one constraint with this release that if the item is not part of the project, then there is no other view/screen where editor can see the comments except the User and Email Notification.

Content Approvals on Blocks and Media [Beta]

Tue, 14 Mar 2017 09:32:59 GMT

This feature is being released as a Beta feature in CMS 10.7.0 and is still under development.

You can read more about how you enable Beta features in Fredrik Tjärnberg’s blog post.

Content Approvals has so far been limited to Pages only. This feature brings the Content Approvals on Assets gadgets (Media, Blocks etc.)
After this release the approvals will be available on any IVersionable. Almost every Asset gadget (Episerver provided or third-party) will be effected by this release.

The main flow of the Approvals on Media and Blocks will be same as on Pages, but there are some differences in terms of where and how editors can configure approval definitions.

The primary difference is that an Item (an image or a block) inside a ContentFolder will inherit the approval definition from the Folder. That means the editors or admins can't configure an approval definition on individual items.

Approval definitions can't be configured under Local Asset Folder (For this page/block etc.) and its descendants. All those items will inhert the definition from the owner content.

There are some more rules regarding the Moving of folders/items and you can read those in the User guide documentation.

EPiServer 7.6 Protected Site Add-Ons location.

Fri, 14 Mar 2014 15:13:14 GMT

Before EPiServer 7.6, the public Site Add-Ons have been placed at /modules/ under the site root and protected Add-Ons placed at ~/protectedModulesPath/Modules or appDataPath\Modules location. But with the release of 7.6, We’ve started streamlining the disk location for Site Add-Ons which means all the Site Add-Ons will be placed under the same root location (/modules/) regardless of the type of the Add-On.

We are making this decision because of a couple of reasons;
the first reason is that CMS, Shell and Add-On Store UI have been converted to NuGet packages so when Installing these packages from NuGet we need a place to put all the resources (aspx files, javascript resources, images etc.) to some path which we can find later (to upgrade these packages) without any surprises.
The second reason is that we want to recommend a standard location inside a deployed EPiServer site where all the third-party Add-On developers can happily put their resources and upgrade them later through NuGet or EPiServer Add-On store and it makes it simpler to reason about the location of every Add-On installed through Add-On store or NuGet specially when you’ve installed a lot of them.

If you’ve already installed/upgraded to EPiServer 7.6 you’ll notice that the installation process has created a new folder /modules/_protected inside the site root. This is the new home for EPiServer protected Site Add-Ons. From now on, all the EPiServer developed protected modules will be placed under modules/_protected.

If you are upgrading from an older installation to release 7.6, the process will clean the folders CMS, Shell and CMS.Sources from old protected modules location (relevant dll files will also be deleted from /modulesbin/). And two new folders (CMS and Shell) will be created under /modules/_protected/ location.

In the same way if you upgrade to EPiServer Add-On Store UI 3.1 (via Nuget), the installation will delete EPiServer.Packaging and EPiServer.Packaging.UI folders from current modules path and EPiServer.Packaging.UI folder will be created under /modules/_protected location.

EPiServer Add-On Store UI 3.1 package also introduces a new command let within the Visual Studio Package Manager Console. This command let will help you in moving all the current protected Add-Ons to new location.
In order to run this command let, first you need to upgrade to new Add-On Store UI package through NuGet (Install-Package EPiServer.Packaging.UI). Once the process of installation completes, You can run Move-EPiServerProtectedModules in Package Manager Console (Tools --> Package Manager –> Package Manager Console) and it’ll move all the current protected modules to new location, it’ll also write the information in web.config and will delete the old folders.