Domino Designer Enhancement in Notes/Domino 7 Adds Control Risk

When I am giving presentations on risk and control self-assessments, I often talk about risk arising in the most unexpected places. As Bruce Elgort pointed out the other day on his blog, an intended enhancement IBM made to the Domino Designer 7 Integrated Development Environment (IDE) has the potential to open application development environments to risk than the benefit it provides as is. The enhancement is the ability to edit design element names and/or aliases in view, without having to physically open the document (see image above). In the thread on Bruce's blog, Andre Guirard of IBM asked me to expand on comments I posted to that thread, so here goes. In this post, I will briefly discuss the origins of in-view editing in IBM Lotus Notes and Domino, the pluses and minuses I have experienced, when I might find it useful in the Designer IDE, the vulnerabilities/risks this feature potentially introduces, and a recommendation for IBM to retain this beneficial enhancement without weakening the application development controls environment.

The Origins of In-View Editing in IBM Lotus/Notes Domino

When IBM release Lotus Notes & Domino 6 (ND6), a new tool was given to developers to enhance the user experience: in-view editing. This feature could only be activated if the application developers specifically added code to the design of the view. When activated, it allowed authorized users to make changes to documents at the view level, without opening the document. One significant deficiency with this tool is the fact that you cannot not mimic a combobox type field at the view level, and you will find many postings in the Lotus developerWorks discussion forum lamenting this fact. Another undesirable behavior of this feature was unpredictability of when the view entry would go into edit mode, depending on when you clicked it. It was for these reasons, as well as the lack of a real requirement for it, that lead me to only try it once in an application.

The Domino Designer Frustration Point

As a developer, one of the frustrations of Domino Designer has been the need to open a design element if you wanted to rename it. Ideally, once an element has been named in accordance with a predefined naming convention as defined by your organization, there should be little or no need to change it. Even so, there are times you may want/need to do it.  For example, you may want to copy a design element to save yourself some work. This is where a frustration point enters the picture. Let's say all of your design elements have an alias assigned to them. Domino Designer is inconsistent on how it handles copying. Sometimes it copies it with the alias, other times it does not. This table gives a quick summary of major design elements and how they behave when copied:

Design Element	Alias Copies	Alias Does Not Copy
Framesets	X
Pages		X
Forms		X
Views	X
Agents	X
Outlines		X
Subforms		X
Style Sheets		X

When you copy design elements that do copy the alias, you may want to change it immediately so that it does no cause conflicts when code is looking up a design element by alias. While ideally this should not cause a problem in your production environment because we all know we do not make live changes in production, sometimes things happen. The copy may have been made for backup purposes while we make changes to an active design element. What we have hated is having to open the design element to rename it. Would it  not  it be nice to edit a name form the design view?

Domino Designer 7 Answers The Wishes...

Even though IBM Lotus Notes/Domino 7 is trumpeted as server enhancements, this does not mean that IBM did not give a few goodies in the Domino Designer client. One is the focus of this post: the ability to edit design element names without having to open the document. Many cheers have been heard around the developer community about this.

...But Opens Up Potential Vulnerabilities and Risks

As Bruce points out in his post, clicking on a design element will often do what in-view editing does in ND6: opens the column for editing when it is not intended. This can lead to an unintended change in an element name or alias (they edit separately), which can cause applications to break. If this is a mission critical application or one that has compliance issues associated with it, this can open up a can of worms. While providing a tool to help developers, the fact that a change can occur by accident and not as the result of a proactive step introduces a control weakness. Earlier in this post I said that "we all know we do not make live changes in production". This assumes that your enterprise has separate development, test and production environments and that the enterprise controls prohibit developers from accessing the production environment. But there are many, many organizations, particularly smaller ones where this is not true. So stuff can, does and will happen with this new feature. Unlike in-view editing for users, it cannot be turned off.

What is Right With This New Feature

The control elements that work well with this new feature are two-fold. One is that if a design element is locked, the names cannot be changed in-view. The other is that an audit trail is maintained as the date, time and signature of the change are retained. There is a limit here though, and that is that it only shows the last change, there is no built-in design audit trail to show when that change was made and who made it.

Changes IBM Needs To Make

The first change is to add consistency so that the design element alias *NEVER* copies with the element. I have never understood why it was not consistent and I cannot think of a reason why I would ever want an alias copied (while they are at it, they could bring consistency to the design property boxes as to how aliases are added). Update: As Joe Litton points out in histrackback below, you may indeed want the same elias on two design elements where one is intended for the client and one for the web. I replied to him that I was not even thinking in those terms when I wrote, so I will include that in the conversation now. The second change is to re-do how the behavior is initiated. Instead of having it initiate by clicking, in just the right place, on the design element, make it enter an edit mode through a specific "right-click" mouse action. This way it becomes clear that it is an intended change, as opposed to an unintended change. I would not merely add a pop-up warning when the element as clicked because that would drive me, as well as other developers, crazy. The bottom line is that IBM should not have introduced a feature that potentially weakens an enterprise's application development controls environment without putting some safety valves in place.

Thank You To Andre Guirard

I want to thank Andre Guirard for joining in the discussion on Bruce's blog and for his willingness to listen. Too many times, vendors might get defensive when criticisms are raised, and he did not. That is the mark of a true professional that is open to listening.