Blog posts by Alex Wang2019-08-19T16:49:30.0000000Zhttps://world.optimizely.com/blogs/alex-wang/Optimizely WorldIssue with Dijit TimeTextBox in the UK<p>Recently a few customers in the UK reported a strange issue. They use David Knipe's <a href="https://www.david-tec.com/2016/12/creating-a-time-picker-property-for-episerver-using-a-dojo-dijit/">solution</a> to create a time picker with Dijit TimeTextBox, and find that the text box shows different time with 1 hour off between IE and chrome. For instance, if an editor in the UK see 8:00AM in IE, he would see 9:00AM in chrome. But It doesn't happen in other locations. If you open the same page in Sweden, you see 9:00AM for both browsers. And in Vietnam you see 3:00PM for both.</p>
<p>If we check the database, we would find the saved value is <strong>1970-01-01T08:00:00.000Z</strong>. You might wonder where the date comes from since it's just a time picker. It's because when selecting the time, the widget will create a Date object, set selected time as local time, and set date to <strong>1970-01-01</strong>. It also shows that it works on GMT in IE while on GMT+1 in chrome. It seems that chrome does not work correctly in the UK. However, according to the <a href="https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation">history of British Summer Time</a>, from 27/10/1968 to 31/10/1971, Britain had an experiment which made the country remain on GMT+1 throughout the year. For this reason, actually chrome is correct while IE is wrong.</p>
<p>Since the TimeTextBox is not a widget of Episerver, we don't solve the issue in CMS UI. A quick fix could be creating a custom widget that inherits from TimeTextBox, and override two methods to set the year other than 1970. Then use it as the custom editor instead of "dijit/form/TimeTextBox". The custom widget will work on GMT in the UK for both browsers.</p>
<pre class="language-javascript"><code>define([
"dojo/_base/declare",
"dijit/form/TimeTextBox"
], function (declare, TimeTextBox) {
return declare([TimeTextBox], {
parse: function () {
// summary:
// Sets to current year instead of 1970 to fix the inconsistency of British Time
var value = this.inherited(arguments);
if (value instanceof Date) {
value.setFullYear(new Date().getFullYear());
}
return value;
},
_setValueAttr: function (value, priorityChange, formattedValue) {
// summary:
// Sets the date on this textbox. Note: value can be a JavaScript Date literal or a string to be parsed.
// The value is a string when loading from server. In this case do not modify the year.
if (value instanceof Date && !this._isInvalidDate(value)) {
value.setFullYear(new Date().getFullYear());
}
this.inherited(arguments);
}
});
});
</code></pre>
<p><span>It is noteworthy </span>that the TimeTextBox works with javascript Date object based on the browser time; it is timezone sensitive, and therefore, it shows a different time in different locations. However, it sets a fixed date; dojo, by default, uses 1970-01-01. As a result, it is not DST(Daylight saving time) sensitive, which means it does not change no matter whether the local time observes DST or not. This may lead to confusion. Think about this scenario: an editor in Sweden is editing the page in summer. Which timezone would be expected? Though the local timezone is CEST(GMT+2), the actual time shown in the widget is CET(GMT+1). This is because the offset is not based on the current date, but on the fixed date(1970-01-01 or whatever else).</p>
<p>That's why a timezone insensitive widget might be useful. You could also inherit from TimeTextBox. The idea is to display UTC time in the widget. In this case, editors always see the same UTC time regardless of the location. See the example on <a href="https://github.com/episerver/alloy-mvc-template/commit/b60780699ddaf872a25c1614ca483d9b7af097b9">github</a>.</p>2019-08-19T16:49:30.0000000ZBlog postComments when sending for review<p><span>In the latest release of CMS UI (version 11.20.0), administrators can require editors to add a comment when sending for review.</span></p>
<p><span>To enable it, select the checkbox when setting up an approval sequence.</span></p>
<p><span><img src="/link/13ce50e8c9ca44d9b0b10ed2d9eae97d.aspx" alt="image6fu7.png" /></span></p>2019-05-27T13:04:26.0000000ZBlog postFour-eyes content approval<p>The four-eyes principle means that a certain activity, i.e. a decision, transaction, etc., cannot be approved by the person making the change. This controlling mechanism is used to facilitate delegation of authority and increase transparency.</p>
<p><span>In previous Episerver versions, an editor who is also set as a reviewer can approve own changes. The four-eyes principle ensures that editors cannot approve their own changes. </span><span>This feature was released in CMS UI 11.8.</span></p>
<h2>Enabling four-eyes content approval</h2>
<p><span>In the approval sequence settings, simply select t</span>he checkbox labeled "Prevent users from approving their own changes" to enable the four-eyes principle.</p>
<p><img src="/link/11097f21292f438aa825e423f196e70f.aspx" alt="Image 4eyes.png" /></p>2018-09-10T10:56:24.0000000ZBlog post