Letter Layout - Need to allow edit by limited user

[RickGrundy]

I have a number of layouts that represent letters we send to customers. These include thank you letters, cover letters, etc. These letters are preformatted and include merge fields for the customer contact information. The default behavior is to have a button that opens the letter layout in preview mode, then takes the user to the print dialog to print it. They have no control over the contents of the letter.

However, sometimes the body of the letters need to be modified before sending. This might include a sales person adding a personal touch to the letter, etc. The problem is that normal users permissions don't allow them to edit layouts. So, this prevents them from modifying the contents of the letter.

How can I allow users to modify the letter, but not be allowed to modify other layouts. Can permissions be set to allow editing of one layout but not others? How else could I allow these letters to be modified?

One idea was to make the body of the message a DB field that could do a lookup of another field that was the default body text. Then users could modify the body without affecting the default body text.

Does anyone have any suggestions? Have you encountered a similar situation in your solutions?

Thank you in advance for your advice.

[kenneth2k1]

Hi:

Yep. I have encountered this. We created a direct mail marketing database with about 60 different letters. Here's how I did it:

You will need three fields. Make a field for each letter body. These fields are your default bodies. These fields must be global. Make another identical field that the user can edit. What I do is keep all the original body fields on a layout. If the user messes someting up, I have a script that sets the user field to the value of the default field.

Put that field on a layout as a merge field.

You can do other stuff like make a calc field that equals the user edit fields and uses nested subsitute functions to sub out the <<merge field>> data so that it acutally shows the value of that field.

Hope that made sense

[CobaltSky]

Hi Rick, Hi Ken,

FWIW, for the sake of 'compactness', if you're following Ken's suggestion, you might want to store all the default letters in successive repetitions of a single repeating text field. They can then be retrieved selectively by script when necessary using the GetRepetition( ) function.

Alternatively, you could create a separate file in which the layouts for the letters are placed and give the users edit access to the layouts in that file, then set up scripted routines that automatically transfer (import) selected groups of records to the letters file for previewing/printing, then delete them afterwards. If the print runs are not typically very large then this can be made to work efficiently.

[kenneth2k1]

Hey mate:

Although I have never been a fan of giving any user access to layout mode in any file, I was exporting found records that needed to print letters to another file. One good thing about that was it offered an easy way to re-peat the job if there was some print failure (which can happen sometimes if you run a job for like 3500 letters). But with the various things that I had to include to the daily process script, it became too much to handle (im a simpleton).

But see that's why it's always cool to have other people that can look at it from another angle. I worked on that sucker for about 1.5 years and never even thought of using reps to this date. It also would've saved development time! thanks Ray

[RickGrundy]

Thanks everyone for your suggesstions.

I had thought of using fields to contain default bodies and it was good to hear others agree with that idea. My main concern is not allowing users to edit layouts no matter what. Instead, I think a layout similar to what we use here to post comments might be good. Direct the users to a layout in browse mode that has the different sections of the letter represented as fields that perform a lookup on a global default. They can then edit the different sections then preview it before printing.

This allows users to edit the letter however they want, and they can revert to the default if they make a mistake. There is also no chance of a single user messing up a layout for everyone else by moving text or deleting a section, etc.

One major sticking point for me is the use of merge fields inside of another field. Say a user wants to substitute the company name in a letter. Typing <<CompanyName>> in a normal field won't work right? How can I allow users to use merge fields when they edit the letter?

Thanks again for your ideas.

[CobaltSky]

Hi Rick,

If you have users type 'tags' within the text they input, it is a relatively simple matter for a script to replace those tags with the fields to which they correspond prior to sending the resulting text to print. For example:

Set Field ["LetterText", "Substitute(LetterText, "<<CompanyName>>", CompanyName)"]

- will deal with the CompanyName field, substituting the contents of the field for the tag within a 'LetterText' field on the current record. You will, of course, have to repeat this for each field the users may have included as a tag within the text they have entered.

If you are using v5.5 or later and are confident with parsing, there is a method by which the tag references can be sourced and inserted dynamically using the GetField( ) function. But that is for when you're getting adventurous. P'raps try the above for starters and see if it gives you what you want.

[RickGrundy]

Thanks.

Your scripting suggesstion should fit my needs exactly. In most cases, users will only need to use a few merge fields in the letters such as <<CompanyName>>, <<Contact>>, <<Address>>, etc. A script that handles these tags should be very straightforward.

For future reference, can you point me in the direction of information regarding parsing and the GetField() function? I can see this being useful as users' needs grow.

Thanks again.

[CobaltSky]

RickGrundy said:For future reference, can you point me in the direction of information regarding parsing and the GetField() function? I can see this being useful as users' needs grow.

Yes.

See demo file online at:

http://www.nightwing.com.au/FileMaker/demos6.html#d9

- under the heading 'Dynamic Merge Tags Within Field Text' near the bottom of the page.

[Oldfogey]

I've just been through a bit of a nightmare, now resolved, with this issue. Customer sending out about six differtent stock letters with maybe perhaps possibly the odd change.

Actually that's an exaggeration but the customer neded to be able to change the basic letter text.

Solution was in Kiosk Mode so no layout issue.

Button plus script plus gigantic layout. User can 'Edit Letter Text', giving access to the text of all the letters.

The basic letter text is in a set of globals to cater for regular word/phrase changes such as 'your store'/'the garage'/etc. The latter are part of a large calculation field which is the final letter.

Any changes to the basic global letter text is permanent but it is a simple matter to add two fields and make it changeable temporarily.

g_BasicPara

PrintPara

MyLetterPara

PrintLetter = case(MyLetterPara = g_BasicPara, g_BasicPara, MyLetterPara

I hate tags because they cause no end of trouble with labels.