Opening a Lotus Notes Profile Document in Read Only mode

I needed to display for “regular” users information that was maintained database wide (preferable via a profile form). Although the usual “@Command( [EditProfileDocument] ; formname; uniqueKey )” worked fine for the db admin people to edit/maintain the information, there was no corresponding “OpenProfileDocument” or such. I wasn’t having much luck forcing a editmode profile document back into readmode for non admin people (using my IsInROle routine ), and I was about to go to a normal form and view when I figured out this way to open a Profile Document in non edit (read only) mode (in this case stuck in a button):

1
2
3
4
5
6
7
      Dim  workspace As New NotesUIWorkspace
      Dim session As New NotesSession
      Dim db As NotesDatabase
      Dim doc As NotesDocument
      Set db = session.CurrentDatabase
      Set doc = db.GetProfileDocument("ProfileDocName" )    
      Call workspace.EditDocument( False, doc, True )

The work is all is those last two line : the GetProfile get the document object for the profile “ProfileDocName”, and the EditDocument opens it on the ui workspace in Read Mode, with the profile Doc object, and opens inRead only mode -so you don’t have to worry about them switching to edit mode.

(technorati.com tags :, )

8 Replies to “Opening a Lotus Notes Profile Document in Read Only mode”

  1. Ian, nice tip. I actually prefer the “real” document approach and then save values back to a profile document (or several) on the querysave. Reasons include a concern about losing the settings in the event of corruption and the ability to have multiple profiles with only one “active” one that actually saves value to a profile.

  2. @Kevin: this might be true for the most applications. But using profile docs can be way faster then real docs, since profile docs are beeing cached by the domino server, and are accesed ways faster. This is also the downside: you cannot get uncached data, so you should’t save highly volatile data into profiledocs.

  3. good points worth explicitly stating :

    Profile documents are for information which only rarely gets edited but does get read frequently (due to caching of data).

    A “real” document approach would make more sense for larger sets of data (more than a handful of documents or more a very large number of fields), perhaps using caching on the dblookup & dbcolumns if performance is a concern and data is infrequently edited.

  4. I think I was misunderstood. The “real” documents I mention are not being queried directly. I am still looking up profile document values like everyone else for all the same caching reasons, etc.

    What IS different in my approach is that the *editing* of those documents does not happen using the typical @Command([EditProfile]) approach, but rather by creating the profiles and transfering the “real” document field values to them on the querysave of the real document. That way, you essentially have a backup of your profile documents in case they get corrupted. The querysave would have code like this:

    Forall item In doc.Items
    Call ProfileDoc.ReplaceItemValue(item.name, doc.GetItemValue(item.name))
    End Forall

    You could also selectively save different blocks of fields on the real document to different backend profile documents, for example by saying all fields whose name begins “Agent*” would go to the “Agent Settings” profile, while those beginning with “Pref*” would go to “DB Preferences” profile.

    The relevance of my approach to this post is that since users only interface with these profile documents through their “real” counterparts, keeping them in read mode is a non-issue.

  5. I use the same profile document across several databases. I only allow changes to be made in one database. I use a dialogbox to display the profile document and just set the [ReadOnly] property to TRUE in all the other databases where I want to be able to look at it but not change anything.

  6. Folks;

    Some great dialog here.. I use an approach similar to Kevins..
    In other words I store the profile/config info in a Notes document. In this document I actually assign a Version Number.
    In my profile document (frame) I select a version number for the config I reference.. then the info is pulled in there and saved in the profile record.

    The nice thing about this is that it makes the profile doc information portable across versions… so you easily move your config changes from test to production by copying over the config version doc and the select the the new version in the profile!.

    and of course you can recover immediately in case of corruption!

    Regards;

    Vito

Leave a Reply to Patrick Kwinten Cancel reply