Add a "future release" icon to contribution mode

Ken posed a good question on the intradoc forums. He wrote:

Our editors have requested that we add a "Future Release" indicator to the Site Studio contribution mode screen, similar to the workflow icon that can appear... Does anyone know what the syntax for accessing the metadata of the content is?

I thought it was a great idea, so I looked into it.

Comparing Dates and Time Zones

Date and time calculations are a bit tricky in UCM. Unlike regular numbers, dates and times cannot be calculated or compared to one another directly.

Comparing numbers is easy, consider this example:

<$if 6 gt 5$>
This code is always true!
<$endif$>

Dates and times cannot be compared this way unless they are converted to numbers, using toInteger(). Unfortunately there is no way to turn that number back into a date, so it's not too useful. A better way to manipulate timestamps without converting them is to simply "parse" them, using the parseDate() function.

<$myBirthday = "5/3/77"$>
<$if parseDate(myBirthday) gt parseDate("18/09/1970")$>
I was born after Hendrix died, on <$myBirthday$>!
<$endif$>

Parsing a date depends on the format of the timestamp. There are many different formats for timestamps so you'll need to figure out which ones are used by your UCM installation. The system locale decides how to format and recognise timestamps. For example, the UK locale uses dates in d/M/yy format, whereas the US locale is M/d/y. The system locale and timezone are chosen when UCM is first installed. Users can choose to use their own locale and change the way dates and languages are displayed just for them. UCM will recalculate timestamps and present the correct timezone for the user's locale whenever they look at a date, but continue to store dates according to the system locale. Any dates that are entered need to follow the (user) locale's recognised date formats, which may or may not include seconds, military hours and so on. The system locale can be changed on reboot using the SystemProperties utility; the user local is easily switched from the Content Server "My Profile" page.

Apart from simple date/time comparisions, UCM can also do a great job at converting a given timestamp to the current timezone, adding daylight saving as required for us. You will need to tell it what timezone you are converting from by manually adding the timezone and then explaining the format of the timestamp. Use zz to indicate a timezone code. For example, let's convert the new year's countdown in New York to my local time (Sydney) and see when they'll join in on our party.

<$parseDateWithPattern("1/1/11 America/New_York",
"d/M/y zz")$>

Unfortunately there doesn't seem to be a built-in way of converting the local timestamp to a specified timezone. I get around this by calculating the difference between a date in local time and the same date specified as another timezone, then adding that difference to my local time. For example, when we're doing the new year's countdown in Australia, how far behind will the UK be?

<$newYearUK = parseDate("1/1/2011")
+ toInteger(parseDate("1/1/2011"))
- toInteger(parseDateWithPattern("1/1/2011 Europe/London",
"d/M/yy zz"))$>

One of the quirks I've observed with handling date objects is that errors are not reported in the server output log. Your code simply keeps going like nothing happened! This makes problems difficult to trace and you'll get unexpected results. It's a good idea to print out your timestamps as you manipulate them so you can see where any problems are.

**** UPDATE ****
Alec Kloss sent me an email with the following tip:
"...you should be able to go to any Content Server generated page and append

&UserTimeZone=America/Chicago

to the end of the URL and... that will change the timezone of all displayed times accordingly."
Nice one!

Metadata Muddling

Ever since we installed our Stellent (now Oracle) CMS I have been anxious about our metadata structure. What is the best way to organise and catalogue our stuff?

The Stellent guys were very pleased with themselves about the fact that we could design any structure we wanted - but frankly we had no idea what to do, we needed some pointers, if not some "best practice" at least some common practice. In the end I believe I composed a decent metadata structure but there are holes in its functionality and, more importantly, in the way people use it.

Here's a rundown on my successes and failures:

1. Don't bother with Security Groups and Content Types. These metadata items actually appear in document URLs and changing them invalidates your links. Accounts do too but they are more useful in controlling access. Note that workflows are restricted to a single Security Group which means multiple Security Groups = duplicated workflows.

2. Don't use abstract definitions for Profiles. We use a number of profiles but our users are confused by them. For example, a user wants to put a PDF on our website. Is this "Web Content" or "Documentation" or a "Publication"? Who cares? Unfortunately I was unable to figure out a better approach and we're stuck with it.

3. Don't rely on "Release Date." Using it for news items and other time-sensitive archives is a bad idea. CheckOutAndOpen replaces the date and release dates can't be changed at all except by checking in a new revision. Make sure you have a "Creation Date" or equivalent metadata.

4. Keep a record of the Original Author. Anyone could edit the item and you won't know who really is responsible for it. Make sure you have a "Creator" or equivalent metadata.

Remember that there are only two ways to change metadata on multiple items - using Archiver or propagating folders - neither of which is simple. Make sure you get it right from the start!