When trying to open the preview pane within a 3rd party application today I got presented with an error message: “Cannot execute the specified command.”

It is important to note that the preview pane is not part of the design of a standard frameset. In order to be able to allow users to preview documents you actually need to create another frame with the name of NotesPreview. The size of the frame can be 0 pixels as it does not need to show up initially. The NotesView frame described in previous article also requires the target frame to be set to NotesPreview. These two settings combined allow the user to open the document preview using the View -> Document Preview -> Show Preview action.

Example:

I used a piece of code (see below) to append a link to a document, sent out via an email message to another user. When the recipient opened that message and clicked the doclink a dialogue box came up “The Doclink database cannot be located.” asking the user to select the server where the linked database is located. This issue however did only happen in some circumstances.

' create notification document
 Set docMemo = New NotesDocument (db)
 With docMemo
  .form="Memo"
  .SendTo=vSendTo
  .CopyTo = vCopyTo
  .Subject = sSubject
  .ReplyTo=session.UserName
 End With
 Set rtitem = New NotesRichTextItem (docMemo,"Body")
 Call rtitem.AppendText (sMessage)
 Call rtitem.AddNewline (2)
 Call rtitem.AppendDocLink (vDocLink,"")
 Call rtitem.AppendText (" <- link to document")
 Call docMemo.Send(False)

Researching that error message at the IBM knowledge base I found a document describing exactly the same issue.

The problem only arises in various circumstances where the linked document is found on a different server then the user’s mail file and the comment$ parameter of the AppendDocLink method is an empty string. The problem is described different for version 4 and 5 of Lotus Notes. However, I discovered it happening in Lotus Notes 6.5 too.

As a workaround it is suggested to not submit an empty string as comment$, this however is only working as long as the user ‘lives’ in the same hierarchy as the id (user) creating the document link.

Lessons learned: I guess that’s another point on the Best Practices list for future development – “Never leave the comment$ parameter empty”

When developing a Lotus application the first question would be whether name fields will be required at all and if so what kinds of fields are required. If it is decided that no name fields are required I would still suggest following my other comment regarding the prevention of the use of the $Readers field.

If however the specification involves the use of name fields the following two questions should be considered:

• Does the name stored within a field require to be maintained with the change of the legal name?
  If so the name needs to be stored to a names field.
  If however, the name in the document must not change with the change of the legal name of a person, this information should rather be stored in a text field or a Names field with the ACL setting to maintain Reader and Author fields only. This case is usually required for record management purposes and to store the initial author of a document. If the name of the author would have been stored in a name field and the employee decides to resign, the name stored in the field used to display the author of a document would be blanked out once the account gets deleted.
• How are names supposed to be displayed; Hierarchical, Canonical, Abbreviate, you name it?
  Names in name fields are always stored using the full hierarchical name. This includes component labels for all parameters. If the name is only supposed to be displayed as common name, it should be stored and maintained in a hidden names field and displayed using a computed for display field or a computed text.

Author fields only apply for users with Author access assigned to them in the ACL. If less access (e.g. Reader) were defined, Author fields would not grant them Editor access to document. Once they have Editor access (and above) they are able to edit all documents they see regardless of Author fields.

Readers fields however effect the visibility of documents. Entities not listed in any Readers field of a document are not able to see documents with at least one active Readers field irrespective of their ACL rights. This restriction can only be overwritten using the Full Access Administration access that got introduced with version 6 of Lotus Notes/Domino.

The current application I am coding does make use of three frames within a frame set to have it appearing more professional then the standard R5 View Navigator. Until today I did never bother about any naming conventions of these frames. One had to be the header, the left one the navigation and the right one the mainframe.

But: if you don’t want your application falling back to the ugly view navigator on the left hand side when somebody is opening a view link or tries to open a view from the View -> Goto Menu it is important to have at least one frame named “NotesView”. This frame is obviously internally used to define the main frame of the application and with it the target of each undefined view or document link.

The information I found at IBM related to this issue is related to version R5 of Lotus Notes. I am not 100 percent sure whether this still applies for version 7 but I successfully tested it in version 6.5 today.

That works:

That does not:

This article describes some of the settings to be considered from the Administration (Part I) as well as best practices from the Development (Part II) perspective when working with name fields in Lotus Notes/Lotus Domino applications.

A Lotus documents can have three different kinds of name fields. These are Readers, Author and Name fields whereas a Readers and an Author field are kind of an extension of a Name field with some more specific characteristics that had partially been discussed earlier.

As the description suggests, Name fields are used to store names in Lotus documents. Names can be of any kind; users, servers, groups, … and are mainly used to define the access to individual documents.

The renaming process of an entity should solely be initiated using the Domino Administrator Client. This ensures that the request to rename an entity is submitted to the Administration Request database (admin4.nsf) and subsequently processed by the AdminP task on the server(s).

The AdminP process ensures, that all possible references to the name in question are maintained at all places like the Domino Directory, the Access Control Lists (ACL) or the documents within databases. The configuration of the Administration Server in the Advanced ACL settings of a Database defines if Names are going to be maintained in this database and what server of the Domino Domain is responsible to do these updates.

If the Administration server were set to None, not even the ACL of the database would be touched. Care should be taken by configuring the Administration server. A replica of the database must exist on the server defined as the Administration server. If Name fields have to be maintained as well a full replica of the database must exist on the server defined, since documents that are not available in the database cannot be maintained. If a database is moving from server A to server B the Administration server setting has to be altered to reflect the new server name.

The two other options beneath ‘Do not modify Name fields’ for the Administration server actions are ‘Modify all Readers and Author fields’ and ‘Modify all Name fields’. As explained above, configuring an Administration server for a database but leaving the Action set to ‘Do not modify Name fields’ ensures that all entities within the ACL of the database are maintained but no documents will be touched at all.

Choosing the option ‘Modify all Readers and Author fields’ ensures that all Readers and Author fields in all documents of this database are maintained whereas the ‘Modify all Name fields’ guarantees that all Name fields will be maintained which includes Readers and Author fields.

Some patience should be exercised with the name change process itself since it consists of various subsequent tasks the AdminP process has to undertake. After submitting a request to change the name of a person the user has to connect to the server at least once. Depending on the ID security settings that can be found under File -> Security -> User Security, Your Identity -> Your Names -> Name Changes (see below) the user will or will not be asked for approval before the change of the name continues.

Considering that the user has accepted the change request the name stored in the user’s ID file will be altered and a request to change the name in the Domino Directory will be submitted to the Administration Requests database. This request will be actioned by the Administration process within one hour. Following this a number of subsequent tasks are added to the Administration Requests:

• The request to maintain the name in all ACL, to be completed within one hour.

• The request to rename the person in the Free Time Database, in Calendar entries and the mail file process, to be completed immediately as well as the renaming in unread lists.

• The rename of the person in person documents, to be completed within one day and the request to rename the person in Reader/Author fields to be completed within one week.

The time frames given can be considered as a deadline for the Administration Process. Server with fewer loads will be able to process the requests more frequently.

It is important to keep in Mind that the centre part of the whole renaming process is the Administration Request database (admin4.nsf), which must reside and replicate to any server in the domain. The database maintains all information in regards to the name change and discloses the current status as shown in the example request beneath.