Lifecycle permissions in Documentum "You must be the owner (or superuser)"

I work on a content management system run off of EMC's Documentum. We had a new requirement that users be able to move our modules into different folders.

But every time we tried to move a module, we encountered the following error:


[DM_SYSOBJECT_E_NO_RELATE_ACCESS]error: "No relate access sysobject named 'product_lifecycle'."

I thought... "Why does it care about a lifecycle, I am not modifying the lifecycle, I am just moving the document." But it turns out that the permissions on a lifecycle do not control the permission on the lifecycle itself, they control the permission on the document that it is attached to. So in order to move a document, you must have the write and relate permissions on not only the document's permission set, but also the applied lifecycle.

We did not know this when creating the lifecycle. The lifecycles permissions were much to restrictive. And you cannot edit an installed lifecycle's properties through Webtop. What a pain...

But wait! Have no fear, you do not you do not need to uninstall it and redeploy it with the Documentum Application builder. You can just do the following steps:

1. API>uninstall,c,46002af8801037ae
2. Now it is uninstalled so update the permissions on the lifecycle easily using the properties->permission screen.
   
3. API>install,c,46002af8801037ae

(Where 46002af8801037ae is the Object ID of the lifecycle).

You now have the correct permissions on your lifecycle and as long as you have the correct permissions on your documents ACL you will be right as rain.

Do NOT Use Javascript to Output Content

Javascript is ever increasing in popularity as a tool for web developers. But it can be dangerous.

Reasons for popularity:

• Availability of great javascript libraries.
• Increasing popularity and new uses for AJAX.
• Increasing user acceptance.
• Increasing browser support.
• HTML5 and lack of support for Flash on iPhone/iPad

Overall, javascript is fantastic. It can provide users with a richer, cleaner, and more responsive experience, while saving resources on the web server.

But because it has become so easy to use javascript, developers are using it for something that it should not be used for: outputting content.

So you might be thinking...

"Why does it matter how we output our web content? It looks the same to the user as long as they have javascript turned on, and this is 2010 who doesn't enable javascript in their browser?!?!"

Well, the most important user in the world Mr. Gle does not use javascript. First name Goo by the way.

So your website looks beautiful, you have your wonderfull content on your 6 dozen pages that you worked so hard on. All of them have great headings and title tags and you followed all the other advice you found about SEO. But guess what, thats not what Mr. Gle sees. He sees 72 pages of spam. This is because for all Mr. Gle knows (Google if you haven't gotten it yet) you have created 72 identical pages and repurposed their titles to try and hit more direct keywords. An SEO spam tactic that is similar, but worse than what Jason Calacanis and his guys at Mahalo got in trouble for.

I know its tempting to use an AJAX call to output some database content onto a silver plate for your users. But you must not do so. All content on web pages should be static html that is generated on the server side.

Don't feel bad if you made this mistake because we did the same thing for our startup project Nofouls.com. Our area feed messages are all output by javascript, so Google does not give a &!#@ about them. Therefor all of our city pages (we have about 100) look almost exactly the same to Google. (Sorry Google we are not trying to be evil!)

Sure the content looks decent. But its output by javascript so it really hurts our image in Google's eyes.

In conclusion, just remember that just because javascript may be an easy and clean way to output your content, it is never the right choice.