Mail Merge Specification: Business Requirements (General)

WORK IN PROGRESS

THIS PAGE IS WORK IN PROGRESS!

Mail Merge Documents

NOTE: Please refer to the Terminology for the exact definition of words and phrases!

Overall

Users must be able to create and format an unlimited number of documents that will serve as Mail Merge Documents (the documents that contain Placeholders for items out of the Mail Merge Data Set).

Creation

The process of creating Mail Merge Documents should be easy, as 'non-technical' as possible, and preferably include a way of easily previewing the resulting document in a format that is quite close to what will be produced once a Mail Merge Run has been performed based on that document. (The best possible outcome would be if results could be shown with actual data instead of Placeholders, but this is not a requirement). A WYSIWYG (What You See Is What You Get) preview would be perfect, but coming close to it will be good enough as well.
The process of the creation of Mail Merge Documents will depend very much on the choice of technology.

Storage

Depending on the choice of technology for the creation of the Mail Merge functionality, documents that will serve as Mail Merge Documents could be stored either external of OpenPetra (somewhere in the file system) or in the OpenPetra database (or perhaps both?).
The storage format of Mail Merge Documents will depend very much on the choice of technology. Mail Merge Documents must be stored in a way that supports various scripts (e.g. using Unicode) - see Support for Various Scripts).

Security

Mail Merge Documents must have the concept of an 'Owner' that is responsible for that Mail Merge Document.

• If the Owner is set, other users will be able to read, but not be able to alter the Mail Merge Document.
• If no Owner is set, every user will be able to read and alter the Mail Merge Document.

(Analogous to setting the Owner in Petra 2.x on a ‘Form Letter Body’).

Depending on how the Mail Merge Documents will end up being created, maintained and stored, the 'Owner' would either be

• a certain OpenPetra User if the Mail Merge Documents would be stored in the OpenPetra database, or
• a network user in an office if the Mail Merge Documents would be stored on a network drive.

In the former case the setting of the Owner would happen inside OpenPetra, in the latter case file system permissions would need to be set by the OpenPetra users using means that the operating system supplies.

Support for Mail Merge Documents in Multiple Languages ???

It would be nice if a user could write a single Mail Merge Document in several languages and if there would be a way to parameterise a Mail Merge Run to pick one of the available languages that the particular Mail Merge Document exists in.
The 'picking' of the language could either be done manually by the user per Mail Merge Run, or be based on Partner Mail Merge Data (e.g. based on the country that the Partner lives in, or perhaps other factors [such as the language that the Partner speaks]).

TODO: We need to find out whether this should indeed be a requirement.

Support for Various Scripts

Mail Merge Documents must support various scripts (e.g. Latin, Greek, Thai, Cyrillic, etc). Editing of Mail Merge Documents must therefore also be possible in those scripts.

TODO: We will need to find out whether Mail Merge Documents must also support right-to-left languages (e.g. Hebrew).

FURTHER BUSINESS REQUIREMENTS (GENERAL) ARE TO BE INSERTED HERE

TODO

Preliminary Summary

Initially we will be open to whatever choices there are with the various technologies that will be looked at, but once we have settled on one technology that should be looked in detail, the process of the creation and the format of Mail Merge Documents plus the storage of these documents will need to be settled on rather quickly as they are a basic starting point for implementing the Mail Merge functionality in OpenPetra.

Mail Merge Output

Printing

TODO: We still need to determine whether there will be a need for having an option that would make the 'first page different' . That option would control the printer output in a way that will cause the first page of every Merged Document to be printed on a different paper tray of the printer than any of the following pages of the same Merged Document. That option might be useful if a multi-page document is to be printed and only the first page should be printed on paper that has items already pre-printed on it (e.g. a 'letterhead' or logo, or a footer line) and all following pages should be printed on plain printer paper (which will need to be placed in the other printer tray).

TODO

Creation of PDF Files

TODO

Sending as E-Mail

Merged Documents will be HTML-Formatted E-Mail Bodies

TODO

Merged Documents will be attached to E-Mail as PDF

TODO

FURTHER BUSINESS REQUIREMENTS (GENERAL) ARE TO BE INSERTED HERE

TODO