Wednesday, March 14, 2007

SnTT - Resetting the Prohibit Design Refresh flag on folders in mail databases

Okay, that last SNTT thing was a little weak so I decided to pull the trigger on one I've had saved for a while. :-)

This is a follow-up to a question someone asked during GURUpalooza at Lotusphere 2007. The scenario described is that after upgrading to a new version of Domino and applying a new mail database template, some users lost folders. This isn't an uncommon problem, and I posted a snippet of code in response to a similar question on the developerWorks Lotus forum. Gregg Eldred picked that up and blogged about it, but it is still coming up so I thought I would do a more formal write up, and clean up the code.

The reason the above happens is simple: if there is no template specified for the database and users create folders, the Prohibit design refresh from replacing or modifying option is not set. If there is a template defined, it is. What's odd is that when you create a mail database for someone the standard process sets the template name. Sometimes this gets wiped out, and I honestly don't understand why. I just know that in my own environment, with extremely technophobic users, it has happened a number of times.

What this means is that when the database is updated from its template, any folders a user created while the template was blank will be deleted. The documents are left in the database, though, and will show up in All Documents. You just have no way of knowing what folder they should be in and it's a royal mess.

Below is a snippet of code that will take care of this for you. Here's a brief rundown of what it is doing:
  • Open the Domino Directory
  • Loop through all the Person documents to get the mail files
  • Compare all the folders in each person's mail database with the template you specify
  • If the folder exists in the template, it clears the Prohibit design refresh flag. This allows a design refresh to update anything that is in the template. If the folder is not in the template but it is in the user's mail file, set the Prohibit design refresh flag, which will prevent the design refresh from deleting the user's folders.
In the thread on Gregg's blog someone suggested pointing this at any database that allows users to create folders. That's not a bad idea, but you would have to have some known list of folders that are not user-created. Or there might be a flag on a folder that tells you who created it, and you could compare it to the database signer. That's something I haven't even researched, so I don't know what is possible. Anyway, here is the code I use. Just drop in your server name and template and away you go.

Sub Initialize
'*** January 21, 2005 - Charles Robinson
'*** Set the Prohibit Design Refresh flag on all non-template views and folders
'*** to prevent a design refresh from overwriting user-created folders
'***
On Error Goto ErrTrap
Dim nLog As NotesLog
Set nLog = New NotesLog("Set Prohibit Design Refresh for Mail")
Call nLog.OpenAgentLog

Dim nSession As NotesSession
Dim nDBNAB As NotesDatabase
Dim nDBMail As NotesDatabase
Dim nDBNTF As NotesDatabase
Dim nVW As NotesView
Dim nDoc As NotesDocument
Dim nDCPeople As NotesDocumentCollection

Set nSession = New NotesSession
Set nDBNTF = nSession.GetDatabase("server/org", "template.ntf", False)
Set nDBNAB = nSession.GetDatabase("server/org", "names.nsf", False)

Set nDCPeople = nDBNAB.Search({Form = "Person"}, Nothing, 0)
Set nDoc = nDCPeople.GetFirstDocument
Do Until nDoc Is Nothing
Set nDBMail = nSession.GetDatabase("server/org", nDoc.MailFile(0), False)
If Not nDBMail Is Nothing Then
Forall vw In nDBMail.Views
'See if the view in the mail file exists in the template
Set nVW = nDBNTF.GetView(vw.Name)
'If not set the prohibitdesignrefresh flag
vw.IsProhibitDesignRefresh = (nVW Is Nothing)
End Forall
End If

GetNextDoc:
Set nDoc = nDCPeople.GetNextDocument(nDoc)
Loop

Set nVW = Nothing
Set nDBNAB = Nothing
Set nDBNTF = Nothing
Set nDBMail = Nothing
Set nDCPeople = Nothing
Set nSession = Nothing

Exit Sub

ErrTrap:
Call nLog.LogError(Err, "Unable to modify database " & nDoc.MailFile(0))
'This is necessary to prevent logging an error for every folder and overflowing the agent log
Resume GetNextDoc
End Sub


This LotusScript was converted to HTML using the ls2html routine,
provided by Julian Robichaux at nsftools.com.

5 comments:

  1. Charles,

    Did you ever get your Standard client to run? I am having similar problem. What did you do?

    Bob

    ReplyDelete
  2. No, I didn't, and I haven't had a chance to try testing it again. For those who don't know what we're talking about, please check this thread.

    ReplyDelete
  3. If there is no template specified for the database and users create folders, the Prohibit design refresh from replacing or modifying option is not set.

    Charles,
    Are you absolutely sure about this? It was my understanding, that this behaviour (I wouldn't want to call it a bug, as it follows a certain logic) was actually fixed back in Notes 5! We ran into this problem, when a couple of customers updated from 4.6 to 6.5 directly, but never faced it in other scenarios.

    ReplyDelete
  4. I didn't start using Notes until R5 and this was a tremendous problem for me until I started using this script to ensure the Prohibit Design Refresh flag was set.

    I just did a test using Notes 7 and with no mail template set a new folder did have the Prohibit Design Refresh flag set.

    So, taking those two firsthand experiences into consideration, I know it was a problem in R5 but it has been fixed somewhere along the line.

    However, this is still coming up and people are asking the question on the developerWorks Lotus forums (and at Lotusphere), so I still think it's good information to have in case it does crop up.

    Thanks for challenging me to go do some testing, it looks like I need to try a few Notes 6 versions and see what happens with those. :-)

    ReplyDelete
  5. Huh, I hope nobody grounded a new business idea on my statment ... ;-)

    I just did a quick check on a 5.0.12 server using a 5.0.13 client and the results were (still) just as you described it.

    I'm 100% sure of 6.5 behaving the same as 7.0 and I assume 6.0 did as well. But as I have no 6.0 installation at hand, I'll keep my mouth shut for now.

    Still, I definitely agree, that this is a usefull script in many cases, as mail files created in ancient Notes releases (and especially the folders created back then) are not an uncommon thing. One thing worth to note for those just stepping by and copying the code is, that it will run on Notes 6 and above, only (although I never got it, why companies would stick to Notes 5 or even 4.6 for so long, when 6 was soooo much of an improvement).

    ReplyDelete