1
votes

In several mail-in and regular databases we have documents that appear to be "uneditable" - i.e. edit them and the edits appear not to save. In fact what is happening is that both the original and the edited doc are being saved because something has switched on "versioning". Needless to say this confuses users quite a lot.

It appears you can only tell versioning is enabled by looking inside the document properties for a field called $VersionOpt.

The form designs have versioning set to None, so something must be setting $VersionOpt.. but what might do that? Is there anything in a regular 8.5.3 mail client that sets document versioning? Any other ideas how this can happen?

(This link explains the background to Notes versioning - http://gg-lnotes.blogspot.co.uk/2010/04/ways-to-do-version-controllingtracking.html)

2
Is this a custom app built by someone in your organation? Or is it built from one of the standard templates provided by IBM Lotus - e.g., the Doclib template. If I recall correctly, that template implements versioning through scripting rather than through the form properties, though it's been quite some time since I looked at it,Richard Schwartz
The app is built (by me) from scratch, without using standard templates. Its a help-desk app with one major form called Support Ticket and is mail-enabled...Dave45
Is the behavior the same for both manually created and mailed-in docs? Does it exhibit the same behavior if you take a local non-replica copy and create/edit docs locally?Richard Schwartz
it is difficult to say - its quite rare, possibly one in a thousand docs or less, with no common factors that I can identify. It is easy to say the user must have done something strange when they created the email for mailing, but what can they possibly do? I am aware of a similar situation with "$SaveOptions" in Notes R7 (?) which arose when docs were saved as draft before mailing in. But I think that bug was fixed, and draft docs aren't versioned - are they?Dave45

2 Answers

1
votes

Based on the comments, my best guess is that you have one or more users drafting their messages in a Notes application built with a template that supports versioning (possibly the Document Library, but it could be something custom) and using a programmed action that calls @MailSend to submit them to the mail-in database. That's going to take the note intact, add the required fields (e.g., SendTo, etc.) for mailing, and drop it into mail.box, complete with all items that the application template's code had created.

(The only other possibility I can conceive of is that you have some add-on software on one of your servers that is hooking the router and adding the $VersionOpt item based on something it sees in certain messages, but that seems very far-fetched. I've never heard of a mail add-in that would do that.)

In any case, the solution to the problem would be to add an agent to the mail-in databases, triggered by the "Before new mail arrives" event, to remove the item. I.e., FIELD $VersionOpt = @DeleteField;

0
votes

If a user creates a Notes 'memo' message using 'stationery', the new note can be created with a version control field. If this Notes 'memo' is then mailed in to the mail-in db, it will recieve the message with the version control field '$VersionOpt'. See this answer in an old forum post:

http://www-10.lotus.com/ldd/nd6forum.nsf/ShowMyTopicsAllFlatweb/92a576fbe203b781852573af00630b78?OpenDocument

There are also old technotes referring to this issue.

The solution is to delete the field using a background agent or otherwsie arrange to delete the field.