Thursday, February 23, 2006

Is it Thursday again already? Show-n-tell

Just a quick little tip today. We have a lot of forms that contain dialog lists whose choices can be set in a profile document by an "administrative user." Occasionally they want to allow regular users to be able to add values to those fields, but for various reasons we don't want to give regular users unrestricted access to the profile document. Here's how we do it:

1. The dialog list field should be set to allow values not in list.
2. Create a hidden field on the form that uses the same @GetProfileField formula as the dialog list.
3. On querysave, test value of dialog against values in hidden field with this code:


FIELD fileType:=fileType;
FIELD fileTypeOld:=fileTypeOld;

@If(@IsNotMember(fileType; fileTypeOld); @SetProfileField("choicesForm"; "fileTypeChoices"; fileTypeOld : fileType); @Return("") )


Show-n-tell+thursday

5 comments:

Esther said...

Thanks... since you've already taken care of that, I'm looking for a new project :o)

Anonymous said...

Isn't profile document caching a problem?

If two people both have the database open and add values one of their values would be lost.

You could probably get around this by accessing the profile document using @GetDocField/@SetDocField instead, and store the UNID in a field on the profile.

Esther said...

Michael, we use document locking to prevent multiple people from changing the profile at the same time. But we haven't run into any problems yet; even "regular" users have limited access so there are only a handful who are allowed to make any changes. Obviously if there were multiple replicas with wide-range access it might be a bigger issue. In that case, instead of storing field values on the profile, we'd probably just use an Allow Values Not In List, and have a lookup view that contains all documents with values in the dialog field. Then the formula for the dialog choices would be an @Unique(@DBColumn) lookup to that view.

Anonymous said...

Esther, I wasn't thinking about locking or replicas.

If you access a profile document then it is cached on your PC until you close the database. You won't see any changes that other people make while you have the database open.

Try this to duplicate the problem:

Open the form on two PC's. Now each PC has the profile document cached.

Now add a new value to the list on the 1st PC. I added "123".

Add a different new value on the 2nd PC. I added "456".

Now close the database on both PC's and reopen it. "456" has been added to the profile document, but "123" has not.

I had this problem when I first started using Notes and tried to use a profile document for storing a sequential reference number. I ended up just using a normal document instead.

Anonymous said...

For an alternative solution to Profile documents and @Environment function see my article about DigestSearch:
http://www-128.ibm.com/developerworks/lotus/library/digestsearch/
It solves problems with cached values, specially for multi-users, but is somewhat more difficult to implement.