HTML Signatures from Notes 6.5 to 8.5

HCL Domino Domino Forum
1

On Notes 6.5, we have designed an automation central database to help users store all the data required to generate their signature and then generate it using HTML file and install it on a user’s calendar profile by detaching the file in the user’s workspace and automatically configuring their mail file.

We are very concerned that, with version 8.5 - which we will switch to within the next few months, we can no longer manage the user’s signatures centrally or that it would even be possible to continue using our application.

We are in the process of managing over 30,000 employee’s signatures. Signatures are important, because they represent a corporation’s image, so we want to control how our user build and use their signature, and in addition, several branches may have to use multiple signatures for each user, depending on language.

How will all this translate into Notes 8.5? Wll we simply loose our massive investment in our siganture solutuion? You can imagine how concerned we are with this issue, considering the massive target audiance. Thank you.

Nicolas Abesdris

2

Subject: Signatures: observations & solution for migration

We finaly managed to test the HTML signatures import feature in order to see if we will be able to switch from Notes 6.5/7 to Notes 8.5 without loosing our central signature database.

It turns out the import pocess is very smooth and quite flexible. This is what we found:

x Mail file conversion from v7 to v8.5 does not change any of the calendar profile content related to the signature parameters. These 5 fields are still present, untouched after the mail file conversion:

EnableSignature = 1

SignatureOption = 2 (for HTML)

Signature_1 = “”

Signature_2 = path to signature HTML file

Signature = path to signature HTML file

x The HTML signature is not imported into the richText item at the mail-file conversion. Instead, the signature seem to be imported only when the user creates his first email message

x Upon importation, a popup asks the user to confirm his signature settings (e.g., to confirm that the import worked correctly). The user cannot cancel this popup, but can change the signature before clicking OK

x After the user imported his HTML signature (either manually, or because he created a first email), the 5 legacy fields containing the old HTML signature parameters in the calendar profile remains untouched. The only difference is that a new field, named “Signature_Rich” was created and is now also present in the user’s calendar profile.

x There is no flag that records if the user already imported his HTML signature. The trigger seems to be the presence or absence of the Signature_Rich field. Whenthe field is present, Notes 8.5 uses its content to display the signature on a new email. When it is absent, and your calendar profile settings are set to HTML signature as per the old Notes settings, it automatically trigers the import function and a confirmation popup is prompted to the user to accept the import.

x Once imported after his first email the original HTML is no longer needed by the user when creating new emails, although it has not been deleted from the drive

x In order to continue using HTML file, as a backward compatibility issue, we can therefore simply programatically erease the calendar profile Signature_Rich rich text item in order to trigger a new import - for instance when a new HTML file has been detached in the user’s working directory.

x Should we wish to code the signature directly, we can programtically code a new rich text field into the calendar profile, replacing the old one.

In conclusion, it seems the new signature mechanism seems very flexible and should enable us to continue using the custom made development we have done in notes 6.5 to support a central HTML signature database.

So far, the only issue that was not resolved involves an import error on the french version of Notes 8.5 when the user creates a new email and the automated import is triggered. (Importing manually still works flawlessly). The english version seems to work correctly without this bug. An SPR was opened for this specific problem.

I hope the above set of observations and solutions will help other peple with the same interrogations regarding the new 8.5 ways of managing the signatures.

Nicolas Abesdris

3

Subject: Signatures in 8.5

Hi,

we had similar problems. In a central Database we manage our Signatures in HTML and in der person document we can choose them.

In the past we copied the html code to the field in the profiledoc in the users mailfile.

Now we create a local signature.html file in the users datadirectory when the user opens his mailfile and his location is not offline, and in the preferences we point to this file.

Works fine, but you need 8.5 as server, client and mailfile as well!

hope it helps

regards

frank

4

Subject: RE: signatures in 8.5

Hello Frank,

You said: “Now we create a local signature.html file in the users datadirectory when the user opens his mailfile and his location is not offline, and in the preferences we point to this file.”

This is exactly what we do right now on version 6.5.4: The html code is generated on demand from the user data stored centrally, and the resulting code is written in an HTML file. The file is then attached into a new email and sent to the user. The embedded form in the email contains the code to adopt the signature: when the user clicks it, it detaches the HTML file on the user workstation and it configures the user’s calendar profile to point to this file.

You said: “Works fine, but you need 8.5 as server, client and mailfile as well!”

So - should I conclude this will continue working properly on version 8.5?

We are open to the idea of adjusting our code for version 8.5, especially if tehre is a faster, better way to handle signatures without the use of HTML files. However, we absolutely need these features:

x The ability to store user’s data (such as their job function or phone number) in an internal and central database,

x The ability to generate the user’s signature using an automated script, based on various critera and administrative parameters

x The ability to update it when the data in the database changed

x Adding a logo to the signature

x Keep the compatibilty with external email such as web mail and outlook (when email is sent outside the Notes network)

x The ability to provide the user with a choice of multiple signatures, with a mechanism to switch signature depending on email

The HTML file enabled us to respond to pretty much all of these criteras.

Frank, did you manage to implement something similar on version 8.5 ?

Thank you all for your input & time on this matter.

Nicolas Abesdris

5

Subject: Passing on to development to look for ideas

RB:1/22/09

6

Subject: Dev Investigating <>

7

Subject: Some suggestions

following suggestions might help in meeting your requirements:

User manually imports signature with RT Lite control import option after your internal signature tool runs.

Provide an automated process end users by piggybacking off the code we have in the template for migration. This is the code that fires when you you attempt insert a signature the first time after upgrading. See CoreEmailClass script library in mail template. This code could update the signature when news ones are distributed.

8

Subject: CoreEmailClass documentation?

Hello Murray,

This is very interesting. Could you provide me with a detail of the CoreEmailClass script documentation, or alternatively, a link to that documentation, so I can evaluate whether this can be used to program a user’s rich text signature right into their own calendar profile?

Thank you

Nicolas Abesdris