We have always used profile documents to control settings…like the location of other databases. We have prevented users from updating the profile documents using an Authors type field. This allowed us to have them access values from the profile document, but not update it.
We recently upgraded to Release 8.5.1 and now the GetProfileDocument method of the NotesDatabase class no longer will work to access the values. We get the Notes error message “You re not authorized to perform that operation ()”.
The code that causes the error is:
Set profileDoc = db.GetProfileDocument( “frmSystemSettings” )
The profile doc’s only security field is the Author type field… there are no Readers type fields. The user’s access to the database can be virtually anything… Author, Editor… even manager. We use a ACL role called [Admin] and even when I deselect this role, with manager access, I cannot access the doc. This is a REAL problem… as we use this everywhere! Is there a new setting on the server that can fix this? This is clearly NOT the way this feature is supposed to work!!!
Subject: Figured out a work around… but IBM needs to fix this thing they “broke”
The short answer on how to fix this is a workaround… which we shouldn’t have to do but will work. Basically, I just have to add a Readers type field to the form with a value of *.
In my previous post, I mentioned that there were no “Readers” type of fields on my profile doc form… which was accurate. What I didn’t realize, until I examined the profile doc, was that Notes was “auto-magically” creating it’s own data item “$Readers” and adding the value from my Authors type field on the form. I find this INFURIATING that Notes is doing this! If I want a readers type data item in my document, I’ll damn well add my own field on the form! I’m assuming my Notes client is doing this… it occurs when the profile doc is saved…and not the server…but am unsure. I created an agent to delete the $Readers data item… and the problem went away. However, as I expected, the next time I edited the profile doc and re-saved it… the $Readers item was re-created.
PLEASE FIX THIS IBM! I don’t know how many applications… potentially hundreds… will now be broken the next time someone updates a profile document! Why should we needlessly have to go back into all of our applications to add a readers field when it isn’t necessary… because you chose to “auto-create” a field that ISN’T wanted/needed and breaks our existing applications! GRRRR!!!
Subject: Not authorized to perform that operation ( GetProfileDocument)
Strange! I encountered the same error message (within a NotesTracker v5.2 subroutine for tracking document deletions), and it had absolutely nothing to do with Readers fields or Authors fields.
To eliminate the error message, I added a few lines of LotusScript to check that the user’s access level to the current database was greater than 2 (Reader level) before executing the GetProfileDocument statement.
Subject: Open a PMR. Security-related stuff is always high-priority.